Define SemanticActivationReceipt and execution evidence binding

[mdheller]

Context

SocioProphet/sociosphere now contains docs/integrations/hellgraph-semantic-governance-control-loop-v0.md.

AgentPlane owns governed execution, replay lineage, and receipt sealing for the first semantic-governance control loop.

Required v0 runtime behavior

AgentPlane must be able to:

1. Consume a semantic activation bundle.
2. Run validator/executor bundles against the activated asset.
3. Preserve graph snapshot and policy bundle references.
4. Emit run artifacts and replay material.
5. Seal a SemanticActivationReceipt.
6. Fail closed when required evidence is missing.

Required receipt fields

• receipt_id
• asset_id
• ingestion_run_id
• graph_snapshot_id
• policy_bundle_id
• quality_snapshot_id
• executor_id
• run_artifact_refs
• replay_artifact_ref
• receipt_hash

Acceptance criteria

• Schema or contract exists for SemanticActivationReceipt.
• Positive fixture seals a receipt for an asset with five mandatory semantic edges.
• Negative fixtures reject missing graph snapshot, missing policy bundle, missing replay artifact, and missing required edge evidence.
• Receipt lineage is stable across reassessment/replay.
• SocioSphere can consume the receipt outcome in admission checks.

Non-goals

• Do not author semantic vocabulary; Ontogenesis owns vocabulary.
• Do not persist graph state; HellGraph owns graph persistence.

[Keesan12]

This looks like the right seam.

The extra thing I would bind early is the activation input itself, not only the resulting artifact refs. Otherwise replay can prove what ran, but not that the executor admitted the same semantic bundle the policy expected.

A small v0 receipt shape that tends to age well is:

• activation_bundle_hash
• validator_bundle_id or hash
• executor_id plus executor_version
• graph_snapshot_id
• policy_bundle_id
• replay_artifact_ref
• run_artifact_refs
• fail_closed_reason when evidence is missing

That gives SocioSphere one stable admission object instead of having to reconstruct state from several adjacent records.

[Keesan12]

Binding the activation input is half the story; I'd also keep executor version and fail-closed reason right next to it. Otherwise two identical bundles can still look equivalent even when the runtime made materially different admission decisions.

[mdheller]

Thanks — this was genuinely helpful. We took your comments as design review rather than just issue-thread feedback, and they materially improved the foundation tranche. What changed: - In guardrail-fabric, we locked the TrustOps outcome → runtime action mapping behind a deterministic monotonic table, with a cross-adapter invariant test so the same receipt chain cannot mean different things under different providers/adapters. - In agentplane, we tightened SemanticActivationReceipt so it binds not only the activation bundle hash, graph/policy/executor/replay refs, but also the runtime admission context: policy_decision_ref, admission_decision, and admission_reason_code. - In agent-registry, we split receipt posture from authority mutation and added the missing “who was authorized to make this happen” fields: decision_actor_ref, decision_actor_kind, decision_authority_ref, authorization_policy_ref, and authorization_evidence_refs. Those PRs are now merged. We did not import MartinLoop or make it a dependency, but your framing was the right transferable seam: receipt as evidence, authority change as governed decision, and runtime action mapping as deterministic infrastructure rather than adapter-local interpretation. The MartinLoop examples were transferable at the boundary-pattern level. The main reason we kept the implementation native is that our surface has to govern more than coding loops: agents, TrustOps receipts, semantic activations, graph snapshots, RAG/model/tool authority, and cross-repo evidence chains. But the review made the implementation sharper. Appreciate the push. It helped us close real ambiguity instead of just adding more schema.

…

On Fri, May 22, 2026 at 00:44 Keesan ***@***.***> wrote: *Keesan12* left a comment (SocioProphet/agentplane#156) <#156 (comment)> Binding the activation input is half the story; I'd also keep executor version and fail-closed reason right next to it. Otherwise two identical bundles can still look equivalent even when the runtime made materially different admission decisions. — Reply to this email directly, view it on GitHub <#156 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFBO4IDTQEHZFMPJCIZPHTL437LLFAVCNFSM6AAAAACY2TDXL2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DKMJVGAZTOOBVGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Keesan12]

That is a strong cleanup.

Locking the TrustOps outcome -> runtime action mapping behind an invariant test is exactly the kind of move that keeps receipts from turning into adapter-local folklore later.

The one extra proof I would keep nearby is a public fixture where the same activation bundle is admitted under one executor/policy context and fail-closed under another. That gives future contributors one concrete boundary case instead of asking them to infer the contract only from schema names.

If you publish a sample receipt/evidence chain for that case, I would be glad to pressure-test whether the operator ambiguity is really gone.

[mdheller]

Good call. We added the public paired fixture and validator for exactly this boundary. Merged in SocioProphet/agentplane#208: - semantic-activation-receipt.divergence-admitted.valid.json - semantic-activation-receipt.divergence-fail-closed.valid.json - semantic-activation-context-divergence.chain.json - validate_semantic_activation_context_divergence.py - semantic-activation-context-divergence-v0.md The invariant now tested is: same activation_bundle_hash != same admission result The paired receipts share the activation bundle hash, but diverge across validator bundle, executor version, graph snapshot, policy bundle, policy decision, and replay artifact. One is admitted; the other fails closed with an explicit fail_closed_reason. That gives future contributors the concrete boundary case you asked for instead of requiring them to infer it from schema names. If you’re willing to pressure-test it, the specific thing to attack is whether the chain fixture fully eliminates operator ambiguity between “same semantic bundle” and “same admissible runtime context.”

…

On Fri, May 22, 2026 at 19:56 Keesan ***@***.***> wrote: *Keesan12* left a comment (SocioProphet/agentplane#156) <#156 (comment)> That is a strong cleanup. Locking the TrustOps outcome -> runtime action mapping behind an invariant test is exactly the kind of move that keeps receipts from turning into adapter-local folklore later. The one extra proof I would keep nearby is a public fixture where the same activation bundle is admitted under one executor/policy context and fail-closed under another. That gives future contributors one concrete boundary case instead of asking them to infer the contract only from schema names. If you publish a sample receipt/evidence chain for that case, I would be glad to pressure-test whether the operator ambiguity is really gone. — Reply to this email directly, view it on GitHub <#156 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFBO4IGFVW32K5UK34424PD44DSKPAVCNFSM6AAAAACY2TDXL2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DKMRTGQYTOMRQGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mdheller]

Good call. We added the public paired fixture and validator for exactly this boundary.

Merged in #208:

• semantic-activation-receipt.divergence-admitted.valid.json
• semantic-activation-receipt.divergence-fail-closed.valid.json
• semantic-activation-context-divergence.chain.json
• validate_semantic_activation_context_divergence.py
• semantic-activation-context-divergence-v0.md

The invariant now tested is:

same activation_bundle_hash != same admission result

The paired receipts share the activation bundle hash, but diverge across validator bundle, executor version, graph snapshot, policy bundle, policy decision, and replay artifact. One is admitted; the other fails closed with an explicit fail_closed_reason.

That gives future contributors the concrete boundary case you asked for instead of requiring them to infer it from schema names. If you are willing to pressure-test it, the specific review target is whether the chain fixture fully eliminates operator ambiguity between “same semantic bundle” and “same admissible runtime context.”