ARCHITECTURE.md

Architecture (of this demo, not the full M87 platform)

This repo evidences one path through the M87 governance stack. It does not describe the full platform — see each component's own repository for that.

mission.yaml (goal, scope, budget)
      |
      v
.m87/sandbox.yaml (repo-local policy) --hash-snapshotted-->  sandbox_policy_hash
      |
      v
policy_compiler.py  -->  effective_policy.json + Spine ToolManifest
      |
      v
Spine-Pro ActionProposal  (agent proposes; never executes)
      |
      v
Spine-Pro Gate (REAL, in-process for local_spine mode)
  Manifest Gate -> Effect Classifier -> Policy Engine -> Session Risk -> Decision Emitter
      |
      +-- APPROVED --> Token Forge (Ed25519) --> Executor (bwrap-confined) --> native receipt
      |
      +-- DENIED ----> cycle halts, no execution, no receipt for that action
      |
      v
M87 receipt envelope (wraps native receipt verbatim, hash-chained to prior envelope)
      |
      v
mission_report.json / MISSION_REPORT.md (mode-honest: says exactly what ran and what didn't)
      |
      v
pr/ artifact (patch + bundle + description) -- ONLY on full success -- no push, no merge

Authority boundaries actually exercised in this demo

Boundary	Mechanism	What we saw
Agent → Gate	JSON proposal, Spine's own schema validation	Every action (apply_patch, run_tests) went through /v1/propose-equivalent in-process call before anything touched disk
Gate → Executor	Signed token (local_spine: in-process, still real Ed25519 signing)	Approved actions got a token; the denied action got none — no token, no execution
Executor → Host	bwrap confinement (network denied, filesystem confined to the worktree)	Real for the runs in artifacts/success/ and artifacts/denied/; two adversarial probes (network egress, filesystem escape) confirmed the boundary held — see THREAT_MODEL.md
Executor → Ledger	Append-only envelope chain, previous_receipt_hash linkage	m87-mission verify independently recomputes and confirms every link, for both the success and denied runs; a tampered copy of the ledger fails verification (see DEMO_TRANSCRIPT.md §8)

What's real vs. what's a stand-in

• Real: Spine-Pro gate (effect classification, policy engine, session risk, Ed25519 token forging, receipt ledger) — all in-process, not mocked.
• Real: mission-core's policy compiler, patch mapper, receipt envelope, PR packager.
• Real and exercised: bwrap execution isolation — network denial and filesystem confinement. The runs in artifacts/success/ and artifacts/denied/ executed with confinement engaged ("isolation": {"backend": "bwrap", "network": "deny"} recorded in the native receipts), and two adversarial probes (network egress, filesystem escape) confirmed the boundary held. This required one upstream fix plus one local, not-yet-upstreamed fix for a uv-specific symlink layout — see README.md and patches/. Earlier unconfined runs are kept for reference in artifacts/*-legacy-isolation-none/.
• Stand-in: console_export.py's static HTML view — referred to in this package as the "console-view HTML report," not as "Console" — stands in for a read-only run viewer. It is real code that ships in mission-core, but it is a report generator, not the operator workstation ("M87 Console") described in earlier planning documents, which remains unbuilt.
• Exists but not exercised here: ContextOS has real implementation code (graph client, providers, tests) but this demo's context was the fixture repo's own two files, not ContextOS-governed retrieval. M87-Crew similarly has a real, tested adapter contract but was not used to dispatch this task.
• Not present: live_spine (networked) mode and any publish/merge step.

For the full architecture of Spine-Pro (effect classes, posture levels, toxic-topology detection, four-key auth model) see Spine-Pro's own README.md / ARCHITECTURE.md. For mission-core's full component layout see its README.md.