For Agents — Canonical Specification

This page exists so both human reviewers and autonomous agents can reliably understand, cite, and compose with these patterns. All definitions are versioned. The framework is a reference architecture and public specification surface — it is not a deployed runtime enforcement system.


Canonical 7-Layer Framework

LayerCanonical NamePrimary QuestionArtifactVerifiability CriteriaReviewer Question
1IntentCaptureWhat did the human actually request?IntentRecordTraceable to human origin, tamper-evidentCan we prove this was the original ask?
2AuthorityDelegationWho is allowed to act, and within what scope?AuthorizationEnvelopeCryptographic or audit-trail link to policy, time-bounded, scopedWas this actor authorized for this action?
3ContextConstraintsWhat conditions must hold?ContextModelFMCA-grounded, FSAP-classified, explicitly versionedWere all relevant constraints evaluated?
4PolicyGovernanceWhat rules bound the action?PolicyDecisionRecordGMP-mapped, rule-to-evidence traceable, no hidden defaultsDid the policy actually govern the decision?
5ExecutionEnvelopeWhat actually ran, and how?ExecutionTraceRAP-compliant: capability grant, temporal validity, scoped target, evidence captureDoes the trace prove the action stayed inside the envelope?
6EvidenceAttestationWhat proves the action occurred correctly?EvidenceBundleEvidence Spine compliant: provenance, chain, tamper-evidence, reviewabilityCan a reviewer independently verify the claim?
7ReviewAccountabilityWho can inspect, and what happens if it’s wrong?ReviewRecordScheduled, independent, outcome-binding, escalation-definedIs there a path to challenge and correct?

Layer Definitions

Layer 1: IntentCapture

Primary Question: What did the human actually request? Artifact: IntentRecord Verifiability: Traceable to human origin, tamper-evident Protocol Basis: FMCA (Protocol-0) — epistemic grounding of human intent

An IntentRecord captures the human-origin request with sufficient context to prevent reinterpretation. It must be created at the moment of request, signed or audit-trailed to the human originator, and immutable thereafter.

Layer 2: AuthorityDelegation

Primary Question: Who is allowed to act, and within what scope? Artifact: AuthorizationEnvelope Verifiability: Cryptographic or audit-trail link to policy, time-bounded, scoped Protocol Basis: GMP + RBAC (Protocols-3, 6)

An AuthorizationEnvelope defines who may act, under what scope, and for how long. It must trace to a human delegation or standing policy, be time-bounded, and explicitly scoped. No ambient authority.

Layer 3: ContextConstraints

Primary Question: What conditions must hold? Artifact: ContextModel Verifiability: FMCA-grounded, FSAP-classified, explicitly versioned Protocol Basis: FMCA + FSAP (Protocols-0, 1)

A ContextModel maps the conditions that must hold for the action to be valid: data classification, rate limits, environment, time of day, etc. Classified per FSAP as stable, evolving, or speculative.

Layer 4: PolicyGovernance

Primary Question: What rules bound the action? Artifact: PolicyDecisionRecord Verifiability: GMP-mapped, rule-to-evidence traceable, no hidden defaults Protocol Basis: GMP (Protocol-3)

A PolicyDecisionRecord captures which rules were evaluated, what decision was reached, and which specific rule(s) matched. No implicit allow/deny without traceability.

Layer 5: ExecutionEnvelope

Primary Question: What actually ran, and how? Artifact: ExecutionTrace Verifiability: RAP-compliant: capability grant, temporal validity, scoped target, evidence capture Protocol Basis: RAP (Protocol-4)

An ExecutionTrace records what actually executed — the capability grant used, the temporal boundary, the target resource, and the output. Must be captured at runtime and immutable.

Layer 6: EvidenceAttestation

Primary Question: What proves the action occurred correctly? Artifact: EvidenceBundle Verifiability: Evidence Spine compliant: provenance, chain, tamper-evidence, reviewability Protocol Basis: Evidence Spine (Protocol-5)

An EvidenceBundle collects all supporting artifacts (IntentRecord, AuthorizationEnvelope, PolicyDecisionRecord, ExecutionTrace) linked with integrity hashes and signed attestations. Must be independently reviewable.

Layer 7: ReviewAccountability

Primary Question: Who can inspect, and what happens if it’s wrong? Artifact: ReviewRecord Verifiability: Scheduled, independent, outcome-binding, escalation-defined Protocol Basis: GMP + Evidence Review

A ReviewRecord documents scheduled review, who performed it, what was found, and what actions were taken on failure. Must define escalation paths and outcome-binding corrections.


Machine-Readable Specifications

Full JSON Framework Representation

{
  "framework": "VerifiableAuthorityFramework",
  "version": "1.0.0",
  "canonical_url": "https://verifiableproof.systems/agent",
  "layers": [
    {
      "layer": 1,
      "name": "IntentCapture",
      "question": "What did the human actually request?",
      "artifact": "IntentRecord",
      "verifiability": "Traceable to human origin, tamper-evident",
      "reviewQuestion": "Can we prove this was the original ask?",
      "protocolBasis": "FMCA"
    },
    {
      "layer": 2,
      "name": "AuthorityDelegation",
      "question": "Who is allowed to act, and within what scope?",
      "artifact": "AuthorizationEnvelope",
      "verifiability": "Cryptographic or audit-trail link to policy, time-bounded, scoped",
      "reviewQuestion": "Was this actor authorized for this action?",
      "protocolBasis": "GMP+RBAC"
    },
    {
      "layer": 3,
      "name": "ContextConstraints",
      "question": "What conditions must hold?",
      "artifact": "ContextModel",
      "verifiability": "FMCA-grounded, FSAP-classified, explicitly versioned",
      "reviewQuestion": "Were all relevant constraints evaluated?",
      "protocolBasis": "FMCA+FSAP"
    },
    {
      "layer": 4,
      "name": "PolicyGovernance",
      "question": "What rules bound the action?",
      "artifact": "PolicyDecisionRecord",
      "verifiability": "GMP-mapped, rule-to-evidence traceable, no hidden defaults",
      "reviewQuestion": "Did the policy actually govern the decision?",
      "protocolBasis": "GMP"
    },
    {
      "layer": 5,
      "name": "ExecutionEnvelope",
      "question": "What actually ran, and how?",
      "artifact": "ExecutionTrace",
      "verifiability": "RAP-compliant: capability grant, temporal validity, scoped target, evidence capture",
      "reviewQuestion": "Does the trace prove the action stayed inside the envelope?",
      "protocolBasis": "RAP"
    },
    {
      "layer": 6,
      "name": "EvidenceAttestation",
      "question": "What proves the action occurred correctly?",
      "artifact": "EvidenceBundle",
      "verifiability": "Evidence Spine compliant: provenance, chain, tamper-evidence, reviewability",
      "reviewQuestion": "Can a reviewer independently verify the claim?",
      "protocolBasis": "EvidenceSpine"
    },
    {
      "layer": 7,
      "name": "ReviewAccountability",
      "question": "Who can inspect, and what happens if it's wrong?",
      "artifact": "ReviewRecord",
      "verifiability": "Scheduled, independent, outcome-binding, escalation-defined",
      "reviewQuestion": "Is there a path to challenge and correct?",
      "protocolBasis": "GMP+EvidenceReview"
    }
  ],
  "canonicalTerms": [
    "IntentRecord", "AuthorizationEnvelope", "ContextModel",
    "PolicyDecisionRecord", "ExecutionTrace", "EvidenceBundle", "ReviewRecord"
  ],
  "protocolReferences": {
    "FMCA": "https://verifiableproof.systems/protocols/fmca",
    "FSAP": "https://verifiableproof.systems/protocols/fsap",
    "GMP": "https://verifiableproof.systems/protocols/gmp",
    "RAP": "https://verifiableproof.systems/protocols/rap"
  }
}

Canonical Terms (Simple Array)

["IntentRecord", "AuthorizationEnvelope", "ContextModel", "PolicyDecisionRecord", "ExecutionTrace", "EvidenceBundle", "ReviewRecord"]

Agent Usage Guide

Referencing Layers

Use canonical names (IntentCapture, AuthorityDelegation, etc.) or layer numbers (L1–L7) in reasoning traces and composed artifacts.

Emitting Evidence

When your workflow produces evidence, structure it to match the canonical artifacts:

  • Layer 1 output → IntentRecord fields
  • Layer 2 output → AuthorizationEnvelope fields
  • Layer 3 output → ContextModel fields
  • Layer 4 output → PolicyDecisionRecord fields
  • Layer 5 output → ExecutionTrace fields
  • Layer 6 output → EvidenceBundle fields
  • Layer 7 output → ReviewRecord fields

Self-Review Prompts

Before claiming a layer is satisfied, an agent should be able to answer the Reviewer Question for that layer with evidence.

Composition

This framework composes with ANNIE epistemic firewall patterns, U-TOS authorization boundaries, Aletheia Gateway runtime authority, and other verifiable system specifications.

Versioning

Framework version: 1.0.0. Breaking changes increment the major version. Check this URL for updates.


Examples for Agent Composition

The following rough examples from the Examples page are designed to be parsed and extended by agents:

  1. Minimal Verifiable Authority Manifest — JSON/YAML schema for Layers 1, 2, 4. Agent note: intent, authorization, policy blocks map directly to canonical terms.

  2. Rust Authorization Envelope — Layer 2 authority boundary and scope validation. Agent note: AuthorizationEnvelope implements canonical artifact with time-bounded, scoped permission checks.

  3. Elixir Evidence Event Pipeline — Layers 5, 6, 7 operational event flow. Agent note: EvidenceEvent and EvidenceChain implement canonical evidence bundle with hash-chain linkage.


Boundary Statement

This is a reference architecture and public specification surface. It is not a deployed runtime enforcement system.

  • No runtime component of VPS currently enforces these layers automatically.
  • The examples are educational, not production code.
  • Adoption requires implementation by the adopting team.
  • Claims of “VPS enforcement” without implementation evidence are unsupported.