(root) STACK_ARCHITECTURE_GAP_REVIEW.md
Status: planning audit Date: 2026-05-25 (resolution note appended 2026-06-11) Scope: ProjectAmp2 stack architecture, roadmap solidity, protocol extraction pressure, Supabase sha…

[&] Stack Architecture Gap Review

Status: planning audit Date: 2026-05-25 (resolution note appended 2026-06-11) Scope: ProjectAmp2 stack architecture, roadmap solidity, protocol extraction pressure, Supabase shared substrate, observability, authority, provenance, federation, and proof gates.

Resolution note — 2026-06-11. A stack-reconciliation pass discharged most of §3 Phase 0: item 1 (reconcile the docs) is done for STACK_COMPLETION.md + STACK_PLANNING.md (ampersand-supabase/ARCHITECTURE.md still outstanding); item 2 (replace ambiguous ✅ with the spec/in_tree/live_local/live_deployed/external vocabulary) is done across STACK_COMPLETION.md and the vocabulary is now canonical in its §8; item 3 (canonical dark-factory smoke script) is done — scripts/dark_factory_smoke.sh + scripts/dark_factory_evidence.mjs emit an honest evidence bundle (live_local kernel core; distributed loop recorded in_tree/external). Item 4 (a PRISM-format Evidence Bundle from the smoke run) remains a follow-up. Finding 2's status table (§2) is the source of the adopted vocabulary. The extraction gate (Finding 1) was also extended to an 8th "wired arrows (in + out)" gate in STACK_PLANNING.md §1.1.

0. Executive summary

The stack is strong in three places:

  1. Protocol coherence[&], PULSE, PRISM, Graphonomous, Delegatic, and OS-011 form a coherent substrate rather than isolated demos.

  2. Spec coverage — most products have canonical specs, capability declarations, and plausible data-model homes.

  3. Integration intent — the dark-factory loop is the correct north-star proof: perceive → act → trace → learn → crystallize → install → replay → benchmark.

The main risk is not lack of vision. The main risk is that the roadmap currently treats too many ideas as candidate protocols before the stack has enough live integration pressure to justify them.

The most important changes recommended here:

  • Freeze new top-level OS protocol slots until the dark-factory proof has a single reproducible local/deployed path.

  • Keep SCOPE as the only near-term new protocol, but narrow v0.1 and make subscription, selector stability, and lease/fencing semantics explicit.

  • Demote PACT to amp.principals + Delegatic principal-binding implementation first; later extract a UCAN/GNAP/OCapN profile if the artifact escapes the database.

  • Demote TALLY to an event-ledger experiment aligned with REA/hREA; balances should be derived views, not the canonical state.

  • Promote telemetry/observability, PEP/provenance, RLS/security hardening, and external benchmark evidence ahead of most new protocol work.

  • Reconcile status drift across STACK_COMPLETION.md, STACK_PLANNING.md, and ampersand-supabase/ARCHITECTURE.md; several contradictions are now architecturally material.

1. Sources reviewed

Local stack documents and specs:

  • STACK_COMPLETION.md

  • STACK_PLANNING.md

  • STACK_TOPOLOGY_AS_AUTHORITY.html

  • STACK_PERIODIC_TABLE_OF_AGENT_INVARIANTS.html

  • ampersand-supabase/ARCHITECTURE.md

  • ampersand-supabase/config.toml

  • ampersand-supabase/migrations/*.sql

  • ampersand-supabase/functions/**

  • AmpersandBoxDesign/SPEC.md

  • PULSE/schemas/pulse-loop-manifest.v0.1.json

  • PULSE/docs/THREE_PROTOCOL_STACK.md

  • graphonomous/docs/spec/README.md

  • opensentience.org/docs/spec/README.md

External prior art checked or used as load-bearing references:

  • CloudEvents — common event envelope, CNCF graduated project.

  • OpenTelemetry GenAI semantic conventions — GenAI, MCP, agent spans, model/tool events.

  • OpenLineage object modelRunEvent, JobEvent, DatasetEvent, facets, job/run/dataset lineage.

  • W3C Web Annotation Data Model — bodies, targets, selectors, specific resources, states, motivations.

  • UCAN — DID-based, signed, delegable, attenuated capabilities with invocation, delegation, revocation.

  • W3C DID Core — DID documents, verification relationships, capability invocation/delegation, revocation/privacy guidance.

  • W3C Verifiable Credentials Data Model 2.0 — claims, credentials, presentations, evidence, status, schemas, terms of use, selective disclosure and privacy cautions.

  • REA / hREA / Holochain design family — economic events over balance-first ledgers, agent-centric source chains, local validation.

  • ActivityPub / ATProto design patterns — actors, objects, activities, collections, repos, relays/appviews.

  • Yjs / Automerge / CRDT practice — convergence laws for collaborative mutation.

  • etcd / Chubby / Kubernetes Lease pattern — leases, fencing tokens, stale-authority prevention.

  • ROS `tf2` frame-transform pattern — timestamped frames, transform chains, coordinate-system validity.

2. Top architectural findings

Finding 1 — The roadmap needs a protocol-extraction gate

Current planning has several high-quality ideas, but too many are framed as possible protocols at the reservation stage. The 7-property test in STACK_PLANNING.md is good, but it should be enforced harder.

Recommended gate before assigning or preserving a top-level OS slot:

GateRequired proof
Two consumersAt least two internal products or one external implementation need the same artifact.
Portable artifactThe thing survives outside the current database/service.
Falsifiable processorThere is a deterministic validate/verify/derive function.
Prior-art deltaA one-page comparison to incumbents names the exact remaining gap.
≤25KB referenceMinimal verifier/processor can plausibly fit the size target.
Conformance fixturesValid, invalid, replay, revocation, version-skew, and redaction fixtures exist.
Live proof pathAt least one end-to-end stack proof consumes it.

Roadmap impact:

  • SCOPE likely passes if narrowed.

  • PEP probably passes as a meta-envelope/profile host if kept small.

  • PACT does not yet pass as a protocol; it is currently an implementation track.

  • TALLY does not yet pass as a protocol; it is currently an economic experiment.

  • FGAP should wait until Graphonomous has real multi-instance pressure and a CRDT operation log design.

Finding 2 — Status drift is now an architecture risk

There are contradictory claims about live completion and schema state. This is not merely documentation hygiene; roadmap order depends on which claims are true.

Examples:

  • STACK_COMPLETION.md contains both a 7/7 dark-factory-live claim and an older 2/7-live, 5/7-in-tree claim. The latter may be stale, but both appearing in the same document makes the document non-authoritative for planning.

  • ampersand-supabase/ARCHITECTURE.md describes kag.* as BendScript live infrastructure, while STACK_COMPLETION.md says kag.* is orphaned after the BendScript protocol pivot.

  • ampersand-supabase/ARCHITECTURE.md lists 35 migrations and 11 schemas, while the repo now appears to include additional rune.* and spec.* migration work.

  • ampersand-supabase/config.toml exposes rune but does not clearly expose spec; architecture text does not fully reconcile rune or spec with the main schema map.

  • PULSE/docs/THREE_PROTOCOL_STACK.md says five canonical tokens, while PULSE v0.1.1 includes six with SurpriseSignal.

Recommended fix:

Create a single canonical status vocabulary and truth table:

StatusMeaning
specDesign exists, no implementation.
in_treeCode and unit tests exist.
live_localExercised against real local services/binaries.
live_deployedExercised against deployed services from another process/machine.
externalExercised by a third-party consumer or benchmark.

No roadmap item should use plain ✅ without one of those labels.

Finding 3 — The shared Supabase layer is good, but entitlement, drift, and secret boundaries are under-specified

The shared Supabase architecture is a strong operator story. The workspace-centric amp.* core is the right shape. But several design gaps should be closed before treating Supabase as production substrate.

Observed gaps:

  1. Entitlements are not enforced in product RLS. Product policies generally check only amp.is_workspace_member(workspace_id). They do not consistently check amp.product_entitlements. This means membership may imply access to every exposed product schema once table permissions and APIs are reachable.

  2. `amp.product_entitlements` product enum appears stale. It includes kag, webhost, fleet, geo, temporal, orchestrate, govern, agentelic, but not clearly rune or spec.

  3. PostgREST schema exposure appears stale. Config exposure and migration reality should be reconciled for rune, spec, and orphaned kag.

  4. Migration numbering collision risk. Multiple similarly-numbered Rune migrations such as 092_*, 093_*, and 094_* reduce readability and increase future merge risk.

  5. Potential plaintext signing material. webhost.deployments.telemetry_auth_ref appears to carry a signing_key consumed by the telemetry function. The architecture checklist says secrets should use Vault; deployment-scoped telemetry signing keys should not live as plaintext JSON in an operational table that might be exposed indirectly.

  6. Telemetry endpoint has no obvious replay/idempotency guard. It verifies HMAC over raw body, but should also require timestamp window, nonce, event ID dedupe, and canonical event IDs.

  7. Billing webhook lacks durable event ingest semantics. It verifies an HMAC but should persist provider event IDs for idempotency/replay and should have clear handling for initial subscription creation.

  8. RLS test coverage is not visible as a stack-level release gate. The policies look coherent, but there should be automated tests proving unauthorized workspace/user access fails per table.

Recommended Supabase changes:

  • Add amp.has_product_entitlement(workspace_id, product) and use it in every product schema RLS policy or at every product entrypoint.

  • Update amp.product_entitlements to include rune and spec, or explicitly mark those schemas non-entitled/internal.

  • Update config.toml and ARCHITECTURE.md to match current active/reserved/orphaned schemas.

  • Add a forward-only migration hygiene note or reserve a new range for post-pivot Rune/Spec migrations.

  • Move telemetry signing keys into Vault or a server-only table not exposed by PostgREST; store only a key ID/ref in webhost.deployments.

  • Add event_id, signed_at, nonce, and idempotency_key to telemetry/billing ingest records.

  • Add a Supabase RLS conformance suite that attempts cross-workspace read/write for every exposed table.

Finding 4 — Authority is split across Supabase Auth, Delegatic, HMAC blocks, and future PACT

Current authority layers:

  • Supabase auth.users gives user identity.

  • amp.workspace_members gives workspace role membership.

  • Delegatic has an authorization kernel and future org-tree policy model.

  • OS-007 references identity/adversarial robustness.

  • WebHost edge functions use JWTs or HMACs.

  • Proposed PACT wants principal/attestation/chain-of-trust.

The missing architectural object is:

principal + capability grant + scope + lease

Do not make this a new identity protocol yet. Use mature prior art:

  • DID for portable identifiers, when needed.

  • VC for attestations and claims, when needed.

  • UCAN for delegated, attenuated capability grants.

  • GNAP for dynamic grant negotiation, if humans/clients negotiate authority.

  • OCapN/object-capability thinking for runtime authority: pass narrow references, not ambient roles.

Recommended PACT reframing:

PACT should not be OS-017 yet. Treat it as an implementation track:

  • amp.principals

  • amp.principal_bindings

  • amp.capability_grants

  • amp.grant_revocations

  • Delegatic authorization_blocks.principal_id

  • Delegatic authorization_blocks.capability_grant_ref

  • PULSE/telemetry fields: principal_id, grant_id, scope_id, lease_id

Extraction test:

PACT becomes a protocol only when the binding/grant artifact is useful outside Supabase and Delegatic.

Finding 5 — SCOPE is promising, but v0.1 needs leases, selectors, and subscriptions more than more region kinds

SCOPE is the best near-term new protocol because it collapses multiple real portfolio needs. But the current draft concerns in STACK_PLANNING.md are right: it is too broad and is missing a few things that matter more than breadth.

What v0.1 must include:

  • Subscription contract. Poll-only coordination is not enough for a coordination protocol.

  • W3C Web Annotation-style selectors for document/file/DOM evidence. Use multiple selectors where anchors can drift.

  • Snapshot/ref semantics for graph regions. expand_hops over a mutating graph breaks deterministic conflict derivation.

  • Lease/fencing semantics for exclusive claims. Stale clients must not commit after expiry or supersession.

  • Frame/transform model for cross-substrate regions. Borrow the tf2 pattern: frame IDs, parent frames, timestamped transforms, validity windows.

  • Minimal strength levels: advisory, soft, exclusive. Defer mandatory until the fencing-token story exists.

What to defer:

  • Robotics-flavored avoid/hazard unless there is a current consumer.

  • Broad cross-frame conflict algebra beyond a minimal same_target mapping.

  • Binary/high-frequency presence wire profile.

  • Mandatory policy-enforced locks.

Recommended SCOPE pitch:

Typed regional awareness for agents.

Secondary pitches:

  • Yjs awareness, but typed and substrate-aware.

  • tf2 generalized beyond physical coordinate frames.

  • etcd leases, but region-aware and agent-native.

Finding 6 — PULSE is currently both too closed and not observable enough

PULSE is the correct temporal layer, but the v0.1 schema has a closed token enum. STACK_PLANNING.md already identifies this as a blocker for SCOPE extension tokens.

Additional gap: PULSE should become OpenTelemetry-compatible early, not later.

Recommended PULSE v0.1.2/v0.2 changes:

  • Add vendor token namespace pattern, for example canonical enum OR ^[a-z0-9]+\.v[0-9]+\.[A-Z][a-zA-Z0-9]+$.

  • Add explicit event schema registry rules.

  • Add compatibility policy: additive vs breaking fields, deprecation, token versioning.

  • Add OpenTelemetry trace-context fields: trace_id, span_id, parent_span_id, trace_flags.

  • Add standard dimensions: workspace_id, principal_id, capability_id, loop_id, phase_id, scenario_id, artifact_ref.

  • Add backpressure semantics for cross-loop delivery, not just delivery and max_inflight declarations.

  • Add lease/fencing fields for act phases where authority can stale between route and act.

Finding 7 — Provenance is too hash-chain-local; PEP should be the next unifier after SCOPE, not many separate provenance protocols

AmpersandBoxDesign/SPEC.md provenance is currently a minimal hash-linked chain with:

  • source

  • provider

  • operation

  • timestamp

  • input_hash

  • output_hash

  • parent_hash

  • mcp_trace_id

That is useful, but it does not yet answer four separate questions:

  1. What produced this artifact? Lineage.

  2. What execution path produced it? Trace.

  3. Who was allowed to produce it? Authority.

  4. Which source span/evidence supports it? Evidence anchoring.

PEP should be a profile host over mature prior art:

ConcernPrior art to reuse
Event envelopeCloudEvents
Runtime correlationOpenTelemetry trace context
Dataset/artifact lineageOpenLineage job/run/dataset/facet model
Evidence anchorsW3C Web Annotation selectors/states/motivations
Verifiable assertionsW3C VC/DID or equivalent proof envelope
Capability authorityUCAN/PACT grant ref

Recommended PEP base fields:

  • pep_version

  • event_id

  • event_type

  • trace_id

  • span_id

  • parent_event_ids

  • producer_principal_id

  • grant_ref

  • scope_ref

  • artifact_ref

  • subject_ref

  • body / claim

  • evidence_refs

  • lineage_facets

  • signatures / proofs

  • redaction_profile

  • retention_policy

Do not create separate protocols for grounding, handoff, replay provenance, synthetic data provenance, and oracle-query provenance until PEP profiles fail to cover them.

Finding 8 — PRISM needs portable evidence bundles before more leaderboard surface

Status (2026-05-25): Addressed in v0.1 by Workbench (workbench/). A SkillBundle is the user-facing artifact; the same JSON, re-framed via EvidenceBundle (workbench/docs/spec/EVIDENCE_BUNDLE.v0.schema.json), is what PRISM consumes. Schema covers the recommended bundle contents below; 5 canonical fixtures exercise the 6 proof gates. Leaderboard push remains gated on v0.2 (browser body + full ProofResult) and a third-party verifier walking through a published bundle.

PRISM is a strong diagnostic layer, but external credibility requires portable artifacts that third parties can inspect without running your whole stack.

Recommended artifact: PRISM Evidence Bundle.

Bundle contents:

  • scenario manifest

  • system manifest

  • [&] capability declaration snapshot

  • PULSE manifest snapshot

  • transcript

  • tool calls

  • emitted CloudEvents/PULSE tokens

  • OpenTelemetry trace export

  • Graphonomous memory refs used or created

  • judge outputs and meta-judge outputs

  • score derivation

  • PEP evidence refs

  • TALLY cost/resource events if present

  • redaction profile

  • reproducibility metadata

  • content hash/signature

This should be earlier than a public leaderboard push. A leaderboard without inspectable evidence invites skepticism.

Finding 9 — Graphonomous federation needs CRDT discipline and privacy boundaries before FGAP

Graphonomous is the stack’s center of gravity. Future federation is a major strategic lever, but it should not start as database sync.

Separate these concepts:

ProblemMechanism
Concurrent graph mutationCRDT/op-log convergence
Epistemic contradictionbelief revision / σ conflict / deliberation
Access controlPACT grants + SCOPE regions
EvidencePEP + Web Annotation selectors
Privacydisclosure classes + retention/forget policies
Federation transportFGAP activity/repo/subscription layer

Recommended pre-FGAP work:

  • Add graph operation IDs and causal parents.

  • Define replica/workspace IDs.

  • Define add/update/delete/supersede/revoke operation semantics.

  • Use OR-set/2P-set/multi-value-register patterns where appropriate.

  • Never resolve epistemic contradiction by last-write-wins.

  • Add visibility/data-classification fields before any graph export.

  • Define private episodic vs shareable semantic memory boundaries.

FGAP should look more like federated signed graph activities than Postgres sync:

  • CreateNode

  • UpdateNode

  • DeleteNode

  • CreateEdge

  • DeleteEdge

  • Annotate

  • Attest

  • Merge

  • Supersede

  • Revoke

  • Forget

  • Compact

Each operation should carry:

  • actor

  • repo

  • scope

  • grant_ref

  • pep_ref

  • causal parents

  • logical clock

  • signature

  • visibility

  • retention policy

  • schema version

Finding 10 — TALLY should be REA/hREA-aligned and event-sourced, not balance-first

The seven-currency thesis in STACK_TOPOLOGY_AS_AUTHORITY.html is interesting, but ν+θ do not yet require a new protocol.

The safest roadmap:

  1. Implement ν+θ as a webhost.billing or amp event-ledger experiment.

  2. Treat balances as derived views.

  3. Align the event model with REA/hREA concepts: agents, resources, events, commitments, claims, agreements, fulfillment, settlement.

  4. Measure whether ν adds decision signal beyond θ.

  5. Extract TALLY only if multiple products need the same portable ledger semantics.

TALLY v0.1, if it emerges, should define:

  • economic event schema

  • resource/unit registry

  • commitment/fulfillment semantics

  • balance derivation rules

  • idempotency and exactly-once posting rules

  • audit/evidence links

  • PACT grant requirements for ledger mutation

  • privacy/redaction classes

Do not define all seven currencies as an implementation commitment. Keep the seven as a registry/thesis, not a protocol surface.

Finding 11 — Privacy, retention, and selective disclosure are not yet first-class across the stack

Graph memory, PRISM transcripts, PULSE events, Supabase telemetry, and future federation can all carry sensitive data. The architecture has GDPR erase and RLS ideas, but not a uniform disclosure/retention model.

Recommended cross-stack fields:

  • visibility: private / workspace / federation / public

  • data_class: public / internal / confidential / regulated / personal

  • derivation_class: raw / derived / aggregate / anonymized

  • retention_policy

  • forget_policy

  • revocation_status

  • allowed_audiences

  • redaction_profile

  • selective_disclosure_profile

Conformance tests needed:

  • Private episodic memory cannot federate.

  • Derived semantic memory retains private-source taint until transformed.

  • Revoked grants cannot authorize future action.

  • GDPR erase removes or tombstones personal data while preserving minimal non-personal audit proof.

  • PRISM evidence bundles can be redacted and still verify structural claims.

Finding 12 — External validation should move earlier

The stack’s weakest layer is external validation. Internally coherent protocols are not enough.

Move one of these earlier:

  • PRISM adapter for a memory competitor such as Mem0, Zep, or Letta.

  • OpenTelemetry export that can be viewed in a standard backend.

  • A third-party MCP server benchmarked through PRISM.

  • A third-party body/browser or body/os provider passing OS-011 conformance.

  • A small external Graphonomous user case study.

Best first move: PRISM competitor adapter for a memory system. It makes Graphonomous claims legible to outsiders.

3. Revised roadmap

Phase 0 — Reconcile truth and prove the vertical path

Priority: immediate.

  1. Reconcile STACK_COMPLETION.md, STACK_PLANNING.md, and ampersand-supabase/ARCHITECTURE.md.

  2. Replace ambiguous ✅ markers with spec, in_tree, live_local, live_deployed, external.

  3. Add a canonical dark-factory smoke test script.

  4. Produce one PRISM Evidence Bundle from the smoke test.

Exit criterion:

  • A clean machine can run one command and produce a trace, replay, benchmark result, and evidence bundle.

Phase 1 — Harden substrate already in use

Priority: before new protocol slots.

  1. Supabase RLS/entitlement conformance suite.

  2. PULSE v0.1.2 vendor token namespace.

  3. Edge-function auth and replay/idempotency audit.

  4. Telemetry schema alignment with OpenTelemetry/CloudEvents.

  5. Credential transfer and affordance projection.

  6. WebHost telemetry/billing idempotency and Vault-backed signing keys.

Exit criterion:

  • Every cross-product action has workspace, principal/user, trace, product entitlement, and audit visibility.

Phase 2 — SCOPE v0.1 only

Priority: one near-term new protocol.

SCOPE v0.1 should include:

  • three region kinds: grid, document_span, graph_subgraph

  • six/seven claim types: presence, edit, reserve, territory, coverage, memory, handoff

  • three strengths: advisory, soft, exclusive

  • subscription contract

  • W3C Web Annotation selector mapping

  • graph snapshot semantics

  • lease/fencing token semantics for exclusive claims

  • minimal frame/transform model

Exit criterion:

  • RuneFort, BendScript, and Graphonomous each consume SCOPE in a real integration test.

Phase 3 — PEP as the provenance/evidence envelope

Priority: after SCOPE and telemetry.

PEP should unify:

  • grounding/citation

  • capability handoff provenance

  • replay provenance

  • PRISM judge evidence

  • synthetic data provenance later

  • PACT/TALLY profile references later

Exit criterion:

  • PRISM Evidence Bundle and Graphonomous evidence paths both use PEP refs.

Phase 4 — Principal/capability implementation track, not PACT protocol

Priority: parallel with Delegatic hardening.

Implement:

  • amp.principals

  • amp.principal_bindings

  • amp.capability_grants

  • grant revocation

  • Delegatic principal-bound authorization blocks

  • UCAN-compatible proof envelope experiments

Exit criterion:

  • destructive OS-011 action and FleetPrompt install both require a principal-bound, scoped, revocable grant.

Only then decide whether PACT deserves a protocol slot.

Phase 5 — ν+θ economic experiment, not TALLY protocol

Priority: after WebHost telemetry/billing hardening.

Implement:

  • event-sourced θ billing ledger

  • optional ν mutual-credit ledger

  • resource/unit registry

  • REA-style event/commitment/fulfillment model

  • PRISM/TALLY cost events if useful

Exit criterion:

  • Evidence that ν changes routing, settlement, or resilience decisions in a way θ alone cannot.

Only then decide whether TALLY deserves a protocol slot.

Phase 6 — External validation

Priority: should start earlier than most research protocols.

Implement at least one:

  • PRISM competitor memory adapter

  • OTel export to a standard backend

  • external MCP benchmark

  • external OS-011 provider

Exit criterion:

  • One claim about the stack can be verified by an external tool or competitor comparison.

Phase 7 — FGAP / federation

Priority: later.

Prerequisites:

  • graph operation log

  • CRDT convergence rules

  • PACT/SCOPE/PEP integration

  • privacy/disclosure classes

  • deletion/forget semantics

  • external Graphonomous deployment pressure

Exit criterion:

  • Two Graphonomous instances can exchange a scoped, signed, privacy-safe graph update and converge without flattening epistemic contradictions.

4. Protocol disposition table

CandidateCurrent recommendationWhy
SCOPEKeep as OS-012; narrow v0.1Best real collapse; multiple consumers; needs subscription/selector/lease hardening.
PULSE v0.1.2PromoteBlocks extension tokens and observability alignment.
OS-013 TelemetryPromote as implementation/profile workNeeded to prove the stack works; align with OTel/CloudEvents.
OS-014 Affordance ProjectionPromoteSmall, immediate, compositional.
OS-012 Credentials TransferPromotePractical dark-factory blocker.
PEPKeep as likely Tier B meta-protocolStrong unifier, but should profile mature prior art.
PACTDemote to implementation trackIdentity/capability space is saturated; use UCAN/DID/VC/GNAP/OCapN patterns first.
TALLYDemote to experimentSeven-currency thesis is not yet a protocol requirement; align with REA/hREA first.
FGAPDeferNeeds CRDT, privacy, authority, and federation pressure first.
AAHDeferInteresting external play; less urgent than proving current stack.
Shape ProtocolDeferValuable, but Graphonomous/SCOPE/PEP need to settle first.
Confidence Algebra advancedDefer but keepUseful after telemetry and PRISM evidence exports.
Failmode taxonomyDeferExternal play, not stack-critical.
Agent Contracts schemaDeferWatch space; may become PEP/PACT profile.

5. Proof gates before more roadmap expansion

Before adding new protocols, require these proofs:

Gate A — RLS and entitlement proof

  • For every exposed table, unauthorized user cannot read/write cross-workspace rows.

  • Product entitlement absence blocks product access.

  • Service-role only mutations are not reachable through client JWTs.

Gate B — Trace/provenance proof

  • One action has trace_id, span context, PULSE event, PEP envelope, Graphonomous memory update, and PRISM evidence reference.

Gate C — Authority proof

  • One destructive action requires Delegatic policy + principal binding + scoped grant + replay-time reauthorization.

Gate D — Replay/idempotency proof

  • Telemetry, billing, trace storage, and replay all reject duplicate/replayed events.

Gate E — Redaction/privacy proof

  • A PRISM evidence bundle can be redacted and still verify non-sensitive structural claims.

Gate F — External comparison proof

  • PRISM evaluates at least one non-ProjectAmp2 system or exports evidence to at least one standard external tool.

6. Concrete near-term task list

Week 1

  1. Create canonical stack status table with spec / in_tree / live_local / live_deployed / external.

  2. Update Supabase architecture for kag, rune, spec, migration count, and config schema exposure.

  3. Add rune and spec to amp.product_entitlements or mark them intentionally non-entitled.

  4. Add amp.has_product_entitlement helper and decide whether product RLS or API edges enforce it.

  5. Patch PULSE docs to say six canonical tokens or explicitly separate v0.1.0 vs v0.1.1.

  6. Draft PULSE v0.1.2 vendor namespace change.

Week 2

  1. Add RLS conformance tests for amp, webhost, fleet, rune, spec, and one future-product schema.

  2. Add telemetry event IDs, nonce/timestamp replay checks, and idempotency keys.

  3. Move telemetry signing key material out of webhost.deployments.telemetry_auth_ref plaintext JSON.

  4. Define minimal OTel mapping for Graphonomous/PULSE/PRISM/WebHost.

  5. Define PRISM Evidence Bundle v0 draft.

Weeks 3–4

  1. Narrow SCOPE v0.1 and finalize subscription contract.

  2. Add W3C Web Annotation selector mapping for document_span.

  3. Add graph snapshot requirement for graph_subgraph.

  4. Add lease/fencing tokens for exclusive claims.

  5. Build RuneFort + BendScript + Graphonomous SCOPE integration fixture.

Month 2

  1. Implement amp.principals and Delegatic principal-bound authorization blocks.

  2. Implement WebHost θ event ledger and optional ν experiment.

  3. Create PEP minimal envelope draft and use it in PRISM Evidence Bundle.

  4. Add external PRISM adapter for one memory system or one non-ProjectAmp2 MCP server.

7. Architectural invariant to optimize for

The stack should optimize for this invariant:

Every consequential agent action is authorized by a principal-bound grant, bounded by a scope, emitted as an observable event, wrapped in provenance, stored with evidence, replayable under policy, and benchmarkable by PRISM.

This invariant is more important than naming more protocols. If the next roadmap phase makes it true for one complete vertical path, the stack becomes much more credible than if it adds three more elegant specs.

8. Bottom line

The roadmap is directionally solid, but it should become more conservative about protocol creation and more aggressive about proof artifacts.

The right next move is not “invent more protocols.” It is:

  1. reconcile truth,

  2. harden the existing shared substrate,

  3. prove one vertical loop,

  4. export evidence in standard shapes,

  5. then extract only the protocols that repeated integration pressure forces into existence.

Open in the interactive atlas

on this page
content id · CIDv1
bagaaierarviabzwgcd46q2hplw365jpwxn2nv4ne4jr2e7m5lt2mduuvtczq