1.1 Problem

Agentic artificial-intelligence systems are increasingly used to produce analyses that inform regulated decisions. Examples include readiness assessments for drug-development submissions, model-risk reviews in finance, decision support in clinical care, and reporting under environmental-compliance regimes. Such systems characteristically combine three classes of operation:

1. Ingestion of external data (clinical trial records, market data, sensor logs).
2. Deterministic computation over that data (database queries, statistical primitives, deterministic transformations).
3. Non-deterministic reasoning, typically realized by large language model inference, which interprets, summarizes, or draws conclusions from the results of the previous two classes.

A substantial body of prior work addresses the first two classes. PROV-W3C provides a general data model for provenance. The in-toto and SLSA frameworks provide verifiable attestation for software supply chains, with Sigstore providing a deployed signing and transparency-log infrastructure. These frameworks were designed before agentic reasoning was a routine component of regulated workflows and they assume the operations they record are deterministic builds. None admits non-deterministic reasoning as a first-class operation; none provides a verification algorithm of the precision a regulator requires to act independently of the producer over a graph that includes such operations.

PoI builds on this lineage rather than replacing it. PoI's signature, content-addressing, and timestamping primitives are intended to be instantiated via the existing ecosystems (see profiles in §7). PoI's contribution is the typed-step taxonomy that admits non-deterministic reasoning, the typed edge relations that distinguish input from context from attestation, and the single mechanical verification algorithm parameterized by step type.

The motivating consequence is that analyses produced by agentic systems in regulated contexts currently rely on producer-controlled audit logs, narrative descriptions, or post-hoc reconstructions. None of these is mechanically verifiable. A regulator presented with such an analysis has no protocol-level basis on which to confirm even the structural integrity of the analysis — that the recorded outputs are bound to the recorded inputs through the recorded operations, without tampering, under identifiable attestation. PoI provides that structural basis. It does not, and no provenance protocol can, certify that the recorded analytical conclusions are correct; see §1.4.

1.2 Position

PoI is a verification protocol, not an analytical platform or workflow tool. Platforms that produce analyses — whether for clinical, financial, or other regulated contexts — may emit PoI proofs of those outputs to support independent verification. The protocol's design does not depend on, nor does it specify, the workflow that produced an analysis; it specifies the evidence structure against which that analysis can be mechanically verified.

PoI's central position is that a single primitive — a content-addressed, signed, typed derivation step — is sufficient to express the evidence required for regulated agentic analyses, and that the properties such evidence must possess emerge as theorems over composed steps rather than being designed in as separate features.

A PoI proof is a directed acyclic graph of such steps. Verification is a single algorithm parameterized by step type. Conformance levels are defined as constraints on which step types must appear and which roles must sign which steps.

This position commits the protocol to a small, fixed taxonomy: four step types (observe, compute, reason, attest) and three edge relations (derived-from, conditioned-on, about). Domain-specific specialization — clinical prespecification, financial model tiering, sector-specific roles — is achieved through the profile mechanism (§7.0) without modifying the base taxonomy. The taxonomy is justified in §2.

1.3 Non-goals

PoI explicitly does not provide:

• Validation of input data. PoI binds an analysis to its claimed inputs through content hashing and attestor signature. It does not certify that the inputs are accurate, complete, current, or fit for purpose. Input validation is the responsibility of the attestor and any external authorities to which the attestor delegates (e.g., source-data integrity standards, vendor-qualification regimes).
• Validation of model outputs. PoI records that a model produced a specific output under recorded conditions. It does not certify that the output is correct, calibrated, or safe.
• Endorsement of analytical conclusions. PoI's verification algorithm establishes that recorded outputs are bound to recorded inputs through recorded operations and attestations, with the binding tamper-evident. For deterministic operations, replay can additionally confirm that the recorded output is the one the recorded function produces on the recorded inputs. For non-deterministic operations, the protocol records the operation's conditions and output but does not establish that the output follows from the inputs in any logical, statistical, or regulatory sense. Whether any recorded conclusion is correct, defensible, or appropriate remains a matter for human review and regulatory judgment, outside the scope of the protocol.
• A consensus mechanism. PoI proofs are produced by a single producer or a coordinated set of producers under a shared trust model. Distributed agreement among independent parties on the contents of a proof is out of scope.
• A retention or archival policy. PoI specifies how evidence is structured and verified. It does not specify how long evidence is kept, by whom, or under what conditions it may be deleted.
• A trust root for identity. PoI requires that every step be signed by an identifiable attestor, but does not specify how identities are issued, verified, or revoked. Identity is a profile concern (§7).

These non-goals are constitutive of the protocol's scope. A reader who expects PoI to provide any of the above is reading the wrong document. The companion scope statement in §1.4 makes the verification-versus-credibility distinction explicit.

1.4 Scope: Verification, Not Credibility

PoI establishes that an analysis was produced as recorded. It is silent on whether the recorded analysis was the right analysis. This distinction is consequential and is stated here as part of the protocol's primary scope, not as a footnote.

A proof that satisfies all conformance checks of §5 establishes:

• That the recorded inputs are bound to the recorded operations through identified attestations
• That the binding is tamper-evident
• That deterministic operations are replayable under their declared regime
• That non-deterministic operations are recorded with stated conditions and explicit re-execution semantics
• That predicates over the typed-step structure (e.g., "every reason step on the path to a regulated conclusion has at least one qualified-reviewer attestation") hold mechanically

A proof does not establish:

• That the recorded inputs are accurate, complete, or fit for purpose
• That the recorded methods are appropriate to the question being asked
• That the recorded conclusions are correct, calibrated, or defensible
• That a reviewer applying domain judgment would reach the same conclusion
• That the analysis is sufficient to support any specific regulatory action

The protocol therefore answers a process-fidelity question and is silent on the analytical-correctness question. Both questions matter for regulated decisions, but they are addressed by different mechanisms: PoI by mechanical verification, analytical correctness by qualified human review under domain-specific standards. PoI is structured so that an attest step from a qualified reviewer (§2.2.4) records the latter and binds it to the former. The attest step records the review; it does not perform it.

Reproducibility of an analysis under PoI is not equivalent to credibility of that analysis. A reproducibly wrong analysis remains wrong. The protocol's value to a regulator is that it makes the analysis legible and mechanically inspectable, so that human judgment can focus on the questions that require it.

1.5 Conventions

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 (RFC 2119, RFC 8174) when, and only when, they appear in capitals.

Hash function references denote SHA-256 unless otherwise specified by a profile (§7). Where post-quantum cryptographic agility is required, profiles MAY substitute an alternative; canonical encoding rules accommodate this without changes to the protocol.

Canonical encoding follows RFC 8785 (JSON Canonicalization Scheme) unless a profile specifies an alternative. Signature scheme is profile-defined; this document does not mandate a specific scheme.

The term "attestor" denotes the identified party signing a step. The term "verifier" denotes any party — including but not limited to the producer of the proof — running the verification algorithm of §3 against a proof. The term "producer" denotes the system or organization assembling a proof from steps it generates.

2.1 Step structure

Every step is a record with the following fields. Field order is fixed by the canonical encoding rule of §2.5; the order in this table is the canonical order.

The ordering of signature before timestamp is deliberate. The attestor signs the unsigned step content; a timestamp authority then countersigns the now-signed step. This binding order — sign, then timestamp the signed thing — establishes that the signed evidence existed at the time the timestamp authority attests, not merely that the unsigned content existed.

For canonicalization, three byte strings are defined:

to_sign(step)      = canonical_encoding( fields 1..5 of step )
to_timestamp(step) = canonical_encoding( fields 1..6 of step )   // includes signature
full_step(step)    = canonical_encoding( fields 1..7 of step )

The attestor signs to_sign(step) to produce signature. The timestamp authority attests to the existence of to_timestamp(step) — which by construction includes the attestor's signature and excludes only the timestamp field — at the timestamp value, producing timestamp.token. A step's identity (§2.5) is SHA-256( full_step(step) ).

A step is verified in three layers, in order: signature validity over to_sign; timestamp validity over to_timestamp; identity computation over full_step. A verifier MUST perform all three.

2.2 Step types and payloads

PoI defines exactly four step types. The taxonomy is minimal in the sense that no two types may be collapsed without losing a verification distinction that this protocol relies on; it is not extensible without a protocol revision. Domain-specific predicates that might naively appear to require additional step types are instead expressed via the attest step's claim-type vocabulary (§2.2.4) under a profile (§7.0).

payload = {
  "content_hash":  <SHA-256 of observed content, hex-encoded>,
  "content_type":  <string: MIME type or domain identifier>,
  "source":        <URI or structured descriptor of origin>,
  "provenance":    <optional reference to external provenance attestation>
}

payload = {
  "function":        <URI or content-hash identifier of the function>,
  "invocation":      <inline canonical invocation object | content-addressed
                     reference of form { "uri": <URI>, "hash": <SHA-256> }>,
  "invocation_hash": <SHA-256 of canonical encoding of the invocation object>,
  "output_hash":     <SHA-256 of canonical output encoding>,
  "output_artifact": <optional inline or by-reference output; required for
                     tolerance replay regimes; see §3.2>,
  "environment":     <execution environment descriptor; see below>
}

invocation = {
  "function":   <same as payload.function>,
  "inputs": [
    {
      "name":           <local name used inside the function>,
      "step":           <SHA-256 identity of predecessor step>,
      "output_hash":    <SHA-256 of that predecessor's output; redundant
                        with the predecessor record but recorded here for
                        verifier convenience and to bind the linkage>
    },
    ...
  ],
  "parameters": <function parameters not sourced from predecessor outputs>
}

payload = {
  "model": {
    "identifier":   <URI or string identifier>,
    "weights_hash": <SHA-256 hash of weights, where available>,
    "version":      <string, where applicable>
  },
  "replay_class":   <"R1" | "R2" | "R3">,
  "invocation":     <inline canonical reason-invocation object | content-
                    addressed reference { "uri": <URI>, "hash": <SHA-256> }>,
  "invocation_hash":      <SHA-256 of canonical encoding of invocation>,
  "input_messages": <inline canonical input message sequence | content-
                    addressed reference { "uri": <URI>, "hash": <SHA-256> }>,
  "input_messages_hash":  <SHA-256 of canonical encoding of input messages>,
  "tool_call_log_hash":   <SHA-256 of canonical encoding of tool calls and
                           responses occurring during inference, if any;
                           absent for non-tool-calling steps>,
  "visible_rationale_hash": <SHA-256 of any model-produced explanation,
                             rationale, reasoning summary, or analytic
                             narrative exposed to users or reviewers;
                             absent if not applicable>,
  "finding_type": <"conclusion" | "no-finding" | "insufficient-evidence"
                  | "negative-result" | <profile-defined>>,
  "output_hash":          <SHA-256 of canonical output encoding>,
  "output_artifact":      <optional inline or by-reference output; required
                           when replay_class = R1 (see below)>,
  "sampling": {
    "temperature":  <number>,
    "seed":         <integer | null>,
    "top_p":        <number, optional>,
    "top_k":        <integer, optional>,
    ...
  },
  "redaction_policy": <optional reference to a profile-defined redaction
                       policy applied before hashing>
}

reason_invocation = {
  "model":          <same as payload.model>,
  "input_bindings": [
    { "name": <name>, "step": <id>, "output_hash": <hash> },
    ...
  ],
  "input_messages_hash":    <same as payload.input_messages_hash>,
  "context_frame": {
    "conditioned_on": [ <step id>, ... ]
  },
  "sampling": <same as payload.sampling>
}

payload = {
  "claim_type": <URI from registered claim-type vocabulary>,
  "role":       <attestor role identifier>,
  "claim_body": <inline structured claim object | reference>,
  "claim_hash": <SHA-256 of canonical encoding of claim_body>
}

2.3 Edge relations

Every entry in a step's predecessors array is an edge. The protocol admits two equivalent surface forms for edges. The compact form is a two-field object:

edge = {
  "step":     <SHA-256 identity of predecessor step>,
  "relation": "derived-from" | "conditioned-on" | "about"
}

The extended form, used only with conditioned-on edges, optionally pins the role and a declared-relevance hash of the contextual relation:

edge = {
  "step":     <SHA-256 identity of predecessor step>,
  "relation": "conditioned-on",
  "context_role":            "policy" | "prior-finding" |
                             "review-context" | "analysis-plan" | "other"
                             | <profile-defined string>,
  "declared_relevance_hash": <SHA-256 of a short producer-supplied statement
                             of why the predecessor is relevant context>
}

The extended form is OPTIONAL in the base protocol. Profiles MAY require it for conditioned-on edges within their regulated scope. When the extended form is used, the verifier MUST canonically encode the full edge object (including the extended fields) when computing the step identity. The extended fields are not subject to replay verification — they discipline what the producer asserts about the contextual relation, they do not establish operational influence.

The permitted relations per step type are summarized below. A proof in which a step has a predecessor edge with a relation not permitted for its type is malformed and MUST fail verification.

The semantics of each relation are:

• derived-from: the predecessor's output is part of the input. For a compute step, this means the predecessor's output is consumed by the function. For a reason step, this means the predecessor's output is part of the prompt or system input. A derived-from predecessor MUST be a step type for which STEP_RESOLVE (§3.0) is defined; it MUST NOT be an attest step.
• conditioned-on: the predecessor is declared as evidentiary context relevant to the current step but is not a direct input to the operation. Common cases include a prior reason step whose conclusion frames the current step's question through producer-side workflow logic, or a policy or charter asserted as governing the analysis but not literally bound into the model input. The protocol records conditioned-on predecessors as part of the invocation but does not establish how, or whether, they affected the operation; their inclusion is an attestor assertion that may be surfaced for human review or compliance predicates. Where the extended form is used, the assertion is further pinned by context_role and declared_relevance_hash, giving reviewers a producer-supplied basis for the contextual relation without making the relation replay-verifiable. Distinguishing conditioned-on from derived-from matters because the verifier's replay procedure differs (§3.2).
• about: the current step asserts something regarding the predecessor. The current step does not depend on the predecessor's output for its own derivation; it claims something about it.

2.4 Timestamp binding

Every step MUST carry a timestamp field of the following form:

timestamp = {
  "value":     <RFC 3339 timestamp>,
  "authority": <URI identifying the timestamp authority>,
  "token":     <opaque token from the timestamp authority>
}

The timestamp authority's binding mechanism is profile-defined. A profile MUST specify how a verifier confirms that token represents a valid attestation by authority that to_timestamp(step) — the canonical encoding of fields 1–6, which includes signature and excludes only the timestamp field itself — existed at value. The timestamp therefore covers the signed step content (including the attestor signature), giving the property that the signed evidence is what is timestamped, not merely the unsigned content.

PoI does not mandate any single timestamp authority. Acceptable authority types include but are not limited to: RFC 3161 timestamping services, Sigstore Rekor inclusion proofs, public-blockchain anchors, and notarial attestations. Profiles bind specific authority types and specify their verification procedures (§7).

A timestamp on a step MUST NOT precede the timestamps of any of its predecessors. A verifier MUST check this ordering as part of structural validation (§3.1).

2.5 Canonical encoding and identity

A step's canonical encoding is the JSON representation of the step record using RFC 8785 (JSON Canonicalization Scheme). All hashes referenced in this document are computed over the canonical encoding of the relevant object.

A step's identity is computed as:

id(step) = SHA-256( canonical_encoding(step) )

where canonical_encoding(step) includes all fields, including signature. The identity is determined only after the attestor has signed the step.

2.6 Construction-time invariants

A step is well-formed if and only if:

1. Its type is one of the four defined values.
2. Its predecessors array satisfies the relation constraints of §2.3 for its type, including the prohibition on attest steps appearing as derived-from predecessors. Edges of relation conditioned-on MAY use the extended form (§2.3); edges of other relations MUST use the compact form.
3. Its payload matches the schema for its type (§2.2), including the presence of invocation (and, for reason, input_messages) either inline or as a content-addressed reference.
4. Its timestamp is structurally valid and does not precede any predecessor's timestamp.
5. Its signature verifies against the public key bound to attestor.
6. Each predecessor referenced exists in the proof, and the proof is acyclic when traversed via predecessors edges.

A proof is well-formed if and only if every step in it is well-formed and condition (6) holds globally. Well-formedness is necessary but not sufficient for verification; verification additionally applies type-specific checks and conformance-level checks (§3, §5).

2.7 The proof manifest

A PoI proof is not transmitted or verified as a bare collection of steps. It is carried alongside a proof manifest, a top-level object that names the steps comprising the proof, identifies the output steps whose outputs are claimed as conclusions, declares the conformance level being asserted, and binds the proof to one or more profiles under which it is to be verified.

manifest = {
  "manifest_version":     "0.6.2",
  "proof_id":             <UUID or content-derived identifier>,
  "steps":                [ <step identity>, ... ],
  "outputs":              [ <step identity>, ... ],
  "conformance_claim":    "L1" | "L2" | "L3" | "L4A" | "L4R",
  "verification_basis":   <optional> "replay-verifiable" |
                                     "linkage-verifiable-only" |
                                     "resolution-limited",
  "profiles":             [ <profile URI>, ... ],
  "manifest_attestor":    <URI identifying the producer claiming this proof>,
  "manifest_signature":   <signature over canonical encoding of preceding fields>
}

The manifest's outputs field replaces the parameter O in §3.1's structural-validation algorithm. Each identity in outputs MUST identify a step of type compute or reason unless a profile explicitly permits otherwise. observe steps carry external data rather than derived output; attest steps carry claims rather than output (§3.0). Permitting them as outputs without profile authorization would create ambiguity in conformance evaluation.

The manifest is signed by the producer asserting the conformance claim. The manifest signature is structurally identical to a step signature but is not itself an Insight Step — it carries no step type, no predecessor edges, and does not appear in the proof DAG. This separation resolves an issue that would otherwise arise: a conformance claim made via an attest step inside the proof would require the proof to contain attest steps even when claiming a level (L1) that prohibits them. The manifest sits outside the typed-step DAG specifically to avoid this circularity.

The handling of attestations about the manifest (rather than about individual steps) is specified in §2.2.4 under "Manifest-level attestations."

Verification basis. The OPTIONAL verification_basis field records the producer's claim about what gate of verification the proof supports:

• replay-verifiable: the producer asserts that every compute step is replayable under its declared regime and every reason step is verifiable under its declared replay class, given the profile-defined resolution services. A verifier with full resolution access SHOULD be able to perform gates 1–5 (Appendix A).
• linkage-verifiable-only: the producer asserts that the proof supports gates 1–3 only (schema, structural, cryptographic), and does not undertake to make functions, models, or weights resolvable to the verifier. Replay is not claimed.
• resolution-limited: the producer asserts a mixed state — some steps support replay, others do not — and acknowledges that the achievable verification basis depends on the verifier's resolution capabilities and on which artifacts are supplied alongside the proof.

The field is informational at the base protocol level. Profiles MAY require a specific verification_basis value as a precondition for use of the proof in their regulated scope. A verifier MUST report, alongside its accept/reject decision, the verification basis it actually achieved (which may be weaker than the claimed basis if resolution services are unavailable). When the achieved basis is weaker than the claimed basis, the verifier MUST identify the steps for which the gap arose.

The absence of verification_basis is permitted for v0.6.2 compatibility with v0.6.1 proofs; in that case the verifier treats the basis as unspecified and reports its achieved basis without comparison.

3.0 The STEP_RESOLVE operation

The verification algorithm uses an internal operation STEP_RESOLVE(s), returning the "output" of a step s. Its behavior is defined per step type:

• observe: returns the observed artifact, identified by payload.content_hash. If the artifact itself is not supplied to the verifier, STEP_RESOLVE returns content_hash as an opaque reference; downstream linkage checks confirm hash equality without requiring artifact retrieval. The verifier MUST track which form was returned for downstream diagnostics.
• compute: returns the output, identified by payload.output_hash. The output bytes are retrievable from payload.output_artifact if present; otherwise from replay if replay is enabled and succeeds; otherwise STEP_RESOLVE returns output_hash as an opaque reference.
• reason: returns the output, identified by payload.output_hash. The output bytes are retrievable from payload.output_artifact if present (REQUIRED at R1, RECOMMENDED at R2 and R3 when the proof is intended to be reviewable without replay). Otherwise STEP_RESOLVE returns output_hash as an opaque reference.
• attest: STEP_RESOLVE is undefined. attest steps record claims, not derived outputs. An attest step MUST NOT appear as a derived-from predecessor of any step (§2.3, §2.6). A proof violating this constraint MUST fail well-formedness.

A step "resolves to bytes" if STEP_RESOLVE returns concrete content rather than an opaque hash reference. Replay verification (§3.2) requires that all derived-from predecessors of the step under examination resolve to bytes; in their absence, the step is verifiable in the weaker sense of structural, signature-, and linkage-validity only, without replay. The verifier records which sense applied per step for the verification-basis report (§2.7).

3.1 Structural validation

Given a proof manifest M (§2.7) and the set of steps P it references, the verifier first validates the manifest itself and then the proof DAG:

STRUCTURAL_VALIDATE(M, P):
    0. Verify M.manifest_signature against the public key bound to
       M.manifest_attestor. On failure: FAIL("manifest signature invalid").
       Confirm that the set of step identities in M.steps equals the
       set of identities computed for P. On mismatch:
         FAIL("manifest does not describe proof").
       Confirm that every identity in M.outputs is present in M.steps.
       On mismatch: FAIL("output not in proof").
       Confirm that every output step is of type `compute` or `reason`,
       except where the named profiles explicitly permit other types as
       outputs. On violation: FAIL("output of impermissible type").
    1. For each step s ∈ P:
         if not WELL_FORMED(s):  return FAIL("step ill-formed", s)
    2. Build the predecessor graph G over P. If G contains a cycle:
         return FAIL("proof contains cycle")
    3. For each edge (s → s') in G:
         if s' ∉ P:                return FAIL("dangling predecessor", s, s')
         if timestamp(s') > timestamp(s):
                                   return FAIL("timestamp inversion", s, s')
         if relation = "derived-from" and type(s') = "attest":
                                   return FAIL("attest cannot be derived-from",
                                               s, s')
    4. Let O = M.outputs.
    5. Compute the structural ancestor closure A = transitive closure of
       predecessors of O. This closure includes all steps regardless of
       supersession status; the protocol does not erase the historical
       derivation of any output. Steps in P \ A are "unreached." A
       verifier MAY emit a warning for these but MUST NOT reject on
       this basis.
    6. Compute the effective ancestor closure A* = A minus any step
       superseded by an attest of claim_type "supersession/retract" or
       "supersession/replace" (§5.4). A* is the closure over which
       conformance checks of §5 are evaluated.
    7. For each output step o ∈ O: if any step in the structural
       ancestor closure of o is superseded but o itself is not
       superseded, return FAIL("output derived from superseded ancestor
       not itself superseded", o). A producer correcting an analysis
       MUST supersede both the retracted predecessor and any downstream
       output that depends on it (or replace the output with a non-
       superseded successor); see §5.4.
    8. Return PASS.

WELL_FORMED(s) is the conjunction of conditions 1–5 of §2.6 (condition 6 is checked globally in steps 2–3 above).

3.2 Type-specific verification

Given a structurally valid proof, the verifier walks the steps in topological order (predecessors before successors) and applies type-specific checks.

TYPE_VERIFY(s):
    case s.type of:

      observe:
        a. If an external artifact for s is supplied, recompute its SHA-256
           and compare with payload.content_hash. On mismatch: FAIL.
        b. Resolve s.attestor under the profile's authority model. If the
           attestor is not authorized to make observations from
           payload.source: FAIL.
        c. If payload.provenance references an external attestation,
           verify it using the relevant external verifier. On failure: FAIL.

      compute:
        a. Obtain the canonical invocation object: either from
           s.payload.invocation inline, or by resolving s.payload.invocation
           as a content-addressed reference (profile-defined resolution).
           Compute SHA-256 of its canonical encoding. If the result does
           not equal s.payload.invocation_hash: FAIL.
        b. Confirm that the invocation object's `inputs` list, when matched
           by step identity, equals the set of `derived-from` predecessors
           of s. For each entry (name, step, output_hash) in inputs,
           confirm that output_hash matches the predecessor's recorded
           output_hash. On any mismatch: FAIL.
        c. Resolve s.payload.function. If the function is not resolvable,
           replay is impossible and the step is verifiable in a weaker
           sense only: it remains structurally, signature-, and linkage-
           verified, but no replay claim is made. The verifier records
           this with diagnostic `compute: function-unresolvable` and
           accounts for the step under linkage-verifiable-only basis.
        d. If replay is enabled, the function is resolvable, and every
           `derived-from` predecessor resolves to bytes:
             - If environment.replay_regime = "bit-identical":
                 re-execute the function on the resolved inputs in an
                 environment matching s.payload.environment. Compute
                 SHA-256 of the canonical replayed output. If it does not
                 equal s.payload.output_hash: FAIL.
             - If environment.replay_regime = "tolerance":
                 s.payload.output_artifact MUST be present. Re-execute
                 the function on the resolved inputs. Apply the
                 equivalence predicate named in s.payload.environment to
                 the pair (replayed output, recorded output_artifact).
                 If the predicate returns false: FAIL. The verifier MAY
                 additionally hash the recorded output_artifact and
                 confirm it matches output_hash; this confirms the
                 artifact has not been tampered with relative to the
                 signed step but does not by itself verify replay.

      reason:
        a. Obtain the canonical reason-invocation object from
           s.payload.invocation (inline or by resolving the reference).
           Compute SHA-256 of its canonical encoding. If it does not
           equal s.payload.invocation_hash: FAIL.
        b. Confirm that the invocation object's input_bindings list, when
           matched by step identity, equals the set of `derived-from`
           predecessors of s, and that its context_frame.conditioned_on
           list equals the set of `conditioned-on` predecessors of s. For
           each input binding (name, step, output_hash), confirm that
           output_hash matches the predecessor's recorded output_hash.
           On any mismatch: FAIL.
        c. Obtain the canonical input message sequence from
           s.payload.input_messages (inline or by resolving the
           reference). Compute SHA-256 of its canonical encoding. If it
           does not equal s.payload.input_messages_hash: FAIL.
        d. (Optional, recommended.) Reconstruct the input messages from
           the resolved `derived-from` predecessor outputs using the
           binding names recorded in the invocation, and confirm the
           reconstruction is consistent with the resolved
           input_messages. The base protocol does not normatively
           specify a single reconstruction rule because the templating
           and message-assembly conventions are model- and producer-
           specific; profiles MAY require a specific reconstruction
           predicate.
        e. Dispatch on s.payload.replay_class:
             - R1 (recorded only):
                 s.payload.output_artifact MUST be present. Hash the
                 artifact and confirm it matches s.payload.output_hash.
                 No re-execution is performed. Record the step as
                 `reason-class: R1, replay: not-attempted` and
                 contributing linkage-verifiable basis only.
             - R2 (re-executable):
                 If replay is enabled and s.payload.model is resolvable
                 at the recorded version, re-execute under
                 s.payload.sampling. Compute SHA-256 of the canonical
                 replayed output and compare to s.payload.output_hash:
                   - Match: record `reason-class: R2, replay: stable`.
                   - Mismatch: record `reason-class: R2, replay:
                     divergent` together with the replayed output hash.
                     This is NOT a verification failure (§3.3).
                 If model is unresolvable, record `reason-class: R2,
                 replay: model-unavailable` and contribute linkage-
                 verifiable basis only.
             - R3 (reproducible):
                 s.payload.model.weights_hash MUST be present. The
                 verifier MUST resolve weights by hash; if unable, FAIL
                 with `reason-class: R3, replay: weights-unavailable`.
                 Re-execute under the fully pinned conditions. Compute
                 SHA-256 of the canonical replayed output. If it does
                 not equal s.payload.output_hash: FAIL. (At R3,
                 divergence IS a verification failure, because R3
                 asserts reproducibility.)

      attest:
        a. Resolve all `about` predecessors. Confirm each is present in
           the proof. (Ill-formed proofs would have failed at step 1
           of STRUCTURAL_VALIDATE; this is a defensive check.)
        b. Resolve s.attestor and confirm the attestor's role
           (s.payload.role) is authorized — under the profile's
           authority model — to make claims of type s.payload.claim_type
           about steps of the predecessor's type. On unauthorized: FAIL.
        c. Confirm s.payload.claim_hash matches the canonical encoding
           of s.payload.claim_body. On mismatch: FAIL.

A note on the semantics of "hash match." For SHA-256 digests, comparison is exact: digests match or they do not. There is no notion of hash equality "within tolerance." Where tolerance replay is required (numerical equivalence under non-deterministic floating-point reductions, for example), the protocol carries the recorded output as an artifact and applies a profile-defined equivalence predicate to the outputs, not to the hashes. This separation — exact comparison for hashes, predicate comparison for outputs — is the protocol's way of admitting numerical practicality without compromising the integrity guarantees of content-addressing.

3.3 The semantics of reason divergence

A reason step that re-executes to a different output than its recorded output_hash is divergent. Divergence is information, not a verdict. The protocol commits to recording divergence; what to do with the record is delegated to the conformance regime and to human reviewers.

This delegation is deliberate. Possible meanings of divergence include:

• Stochasticity within tolerance. The model is non-deterministic by design and the divergent output expresses substantively the same conclusion. Whether two outputs express the same conclusion is generally not mechanically decidable.
• Material change in conclusion. The divergent output expresses a conclusion that, if it had been recorded originally, would have led to a different downstream analysis. This is a finding for human review and may trigger a supersession (§2.2.4).
• Model drift or unavailability. The model identifier resolves to a model whose behavior has changed since the original step was produced. This is a finding for the producer's model-management process.

A future version of this protocol may specify a richer semantics for divergence — for example, by typing each reason step's output_hash under one or more semirings whose composition rules determine which downstream conclusions remain valid under which divergence conditions. Specifying this semantics is out of scope for v0.6.2.

3.4 Complexity

For a proof with n steps, the graph-theoretic portion of verification — well-formedness checks, cycle detection by Kahn's algorithm, ancestor closure computation, supersession analysis — runs in O(n) time and space. Total verification cost is dominated by the additive cost of cryptographic operations (signature and timestamp verification, scaling per-step but constant in n), external resolution (function and model retrieval, content-addressed reference resolution, external provenance verification), artifact retrieval, replay execution itself (which for reason steps may be the dominant term), and profile predicate evaluation. The structural claim is that the graph-traversal cost is linear and tractable; the operational cost is dominated by terms outside the graph itself, which scale with the producer's resource decisions rather than with proof size.

This complexity bound is the basis for the claim that the graph-theoretic portion of PoI verification is decidable and tractable for proofs of practical size.

4.1 Traceability

For every step s not of type observe, every input to s is reachable, by transitive traversal of predecessors edges, to one or more observe steps.

This holds by induction on the predecessor graph: every non-observe step has at least one predecessor (§2.3), and the graph is acyclic (§2.6), so every backward path terminates at an observe. Traceability is therefore not an external property; it is a structural invariant of any well-formed proof.

4.2 Reproducibility

Every compute step is replayable under its declared replay regime — bit-identical, or output-equivalent under a profile-defined predicate. Every reason step is verifiable under its declared replay class — R1 (recorded only), R2 (re-executable with possible divergence), or R3 (reproducible bit-identically against pinned weights).

This follows directly from §2.2.2 and §2.2.3. The protocol distinguishes deterministic and non-deterministic operations by step type, and within each, distinguishes the strength of the reproducibility claim being made. Reproducibility is not a single property but a regime-and-class lattice; the conformance levels of §5 select which regions of the lattice are admissible for which classes of analysis. Per §2.2.3, R3 is currently aspirational for closed-weight hosted models; the lattice is structured so that practical analyses operate at R2 under L4A without prejudice to migration to L4R as the open-weight ecosystem develops.

4.3 Reviewability

Every step's payload is independently inspectable given its predecessors and the profile-defined resolution mechanism for its identifiers.

Content-addressing (§2.5) ensures that any inspector with the proof and access to the profile's resolution services can recover the data described by every payload field. No proprietary tooling is required. Visible rationale (§2.2.3) is independently inspectable in the same way.

4.4 Robustness (tamper-evidence)

Any modification to any field of any step changes that step's identity. Any modification to a step's identity invalidates every descendant that references it.

This follows from the definition of step identity as a hash over the canonical encoding (§2.5) and the use of identities (not positions or pointers) in predecessors edges (§2.3). The cost of forging a modification is the cost of producing a SHA-256 collision and of forging or coercing every signature on every descendant step.

4.5 Regulatability

Compliance rules expressible as predicates over typed steps and signed roles in the proof DAG can be mechanically checked against any well-formed proof.

The combination of typed steps (§2.2), typed edge relations (§2.3), and role-bearing attest steps (§2.2.4) is sufficient to express predicates such as: "every reason step on the path to a regulated conclusion has at least one about predecessor of type attest with role qualified-reviewer," or "every compute step performing a confirmatory analysis is preceded by a prespecification/locked-plan attestation with timestamp earlier than its earliest input data lock." A profile MAY supply a library of such predicates corresponding to a specific compliance regime (e.g., 21 CFR Part 11, SR 11-7, GMLP).

This is the precise form of the protocol's claim to support compliance: not that PoI implements any specific regulation, but that PoI's structure permits expressing compliance rules as decidable predicates over the proof. The mapping between PoI mechanisms and specific regulatory frameworks is provided informatively in Appendix C.

Editor's note (§4). Each of these subsections currently states the property and gives a one-paragraph justification. In the published version, each will be elevated to a numbered proposition with a sketch of proof. The proofs are short — none requires more than half a page — but their correctness depends on the precise wording of §2 and §3, which is why they are deferred from this draft.

5.1 Level definitions

L1 — Provenance. The proof DAG contains only steps of type observe and compute. All steps are signed. All compute steps declare a replay_regime (bit-identical or tolerance) and meet the corresponding replay requirements when verified by a party with access to the function and environment. The proof DAG contains no reason and no attest steps. At L1, attestor resolution MAY be limited to cryptographic key resolution sufficient to verify the signature; the bound key is not required to be linked to a verified organizational or individual identity. Profiles MAY permit self-declared or locally-issued keys at L1. Sufficient for low-risk computational analyses where no reasoning operations contribute to conclusions, no in-proof attestations are claimed as part of the evidence, and identity binding is not required by the consuming process. (External attestations, including the manifest's own signature, are unaffected by this restriction.)

L2 — Identity. L1 plus: at L2, the key resolved for every attestor MUST be bound, under the profile's authority model, to a verified organizational or individual identity and role. All timestamps resolve to a profile-recognized timestamp authority. Sufficient for regulated computational analyses without reasoning components.

L3 — Reasoning. L2 plus: reason steps MAY appear. Every reason step that is an ancestor of an output step MUST declare replay_class of at least R2 — that is, R1 (recorded-only) reason steps are not permitted as ancestors of output steps at L3. The model identifier MUST be resolvable under the profile's resolution mechanism at the recorded version. attest steps MAY appear and follow the rules of §2.2.4. Sufficient for agentic analyses contributing to regulated conclusions where re-execution access (but not full reproducibility) is available.

L4A — Independently Attested. L3 plus the following two requirements:

1. Independent qualified review. For every output step s of type reason, there MUST exist an attest step a in the proof such that:

   • a has an about edge pointing to s,
   • a.payload.role is in the profile-defined set of qualified review roles,
   • a.payload.claim_type is in the profile-defined set of approval claim types,
   • a.attestor resolves to an identity distinct from s.attestor.

   (Note that a is a successor or sibling of s in the DAG, not a predecessor. The relationship is established by the about edge from a to s, not by any edge from s to a.)

2. Prespecification for confirmatory analyses. Profiles designating a compute or reason step as a "confirmatory analysis" output MUST require that an attest step of claim_type prespecification/locked-plan (or a profile-specific variant) exists, with an about edge pointing to the analysis step, whose claim_body references an external locked plan with a timestamp earlier than the earliest observe step in the analysis step's ancestor closure that corresponds to data unblinded after the lock. The base protocol provides the structural mechanism; each profile binds the determination of "confirmatory analysis" and "unblinded data" to its domain.

L4A admits reason steps with replay_class R2 throughout, including for outputs that downstream regulatory regimes may consider high-stakes. The strength of L4A rests on the combination of identity binding (L2), re-executability with model resolution (L3, R2), independent qualified review, and prespecification rather than on bit-identical reproducibility. L4A is the level appropriate to regulated agentic workflows on closed-weight hosted models with strong governance.

L4R — Reproducible. L4A plus the following requirement:

3. Reproducibility for high-stakes reasoning. Profiles MAY designate certain output classes as "high-stakes." For any reason step that is an ancestor of a high-stakes output step, replay_class MUST be R3 (reproducible). For other output steps, R2 remains permitted. Profiles SHOULD acknowledge the aspirational status of R3 per §2.2.3 in defining their high-stakes-output set.

L4R is the strongest conformance claim and is sufficient for regulated analyses where bit-identical reproduction of high-stakes reasoning outputs is both required and achievable — characteristically open-weight model deployments under controlled runtimes. L4R subsumes L4A: a proof satisfying L4R necessarily satisfies L4A.

Choosing between L4A and L4R. Producers SHOULD claim the higher of the two levels their analysis can support. Profiles MAY restrict their regulated scope to one of the two — for example, a profile addressing a regulatory regime that demands bit-identical reproducibility for primary endpoints would require L4R; a profile addressing a regime that demands independent qualified review and prespecification but accepts non-deterministic reasoning would accept L4A. The protocol does not by itself decide which level a given regulatory regime should require; this is a profile and regulator concern.

5.2 Decision procedure

For each level, the additional checks beyond L1's are mechanically expressible as predicates over the manifest, the proof DAG, and per-step attributes. The verifier of §3 takes the level as a parameter (read from M.conformance_claim) and applies the corresponding predicate set. No level requires the verifier to interpret natural-language content; all checks are over types, hashes, identities, replay classes, edge relations, roles, and timestamps.

A useful framing of the level definitions is as the following graph query: at each level, the set of output-reaching steps must satisfy a level-specific predicate set. The predicate set grows monotonically with level: L1 ⊂ L2 ⊂ L3 ⊂ L4A ⊂ L4R. An L3 verifier checking an L4A-claimed proof would not detect missing review attestations as failures; an L4A verifier checking an L1-claimed proof would not require them. Conformance is checked against the claimed level, not against the highest level the proof structurally satisfies.

5.3 The handling of reason divergence at L3, L4A, and L4R

At L3 and L4A, a reason step with replay_class R2 that diverges on re-execution is recorded as divergent (§3.2 reason.e) but is not a verification failure. The proof's conformance status is unaffected by R2 divergence at the protocol level. Profiles MAY require that divergence above a threshold trigger a supersession (§5.4) before the proof is admissible to the regulated process the profile addresses; the protocol provides the mechanism, the threshold and trigger are profile-level decisions.

At L4R, a reason step in the path of a high-stakes output step MUST be R3 and therefore MUST replay bit-identically. Divergence in this case IS a verification failure (§3.2 reason.e, R3 branch). This is the central reason for the R3 class: it admits the strongest, regulator-grade claim that recorded outputs can be reproduced. The split between L4A and L4R isolates this claim from the independent-attestation claims, so that regulated workflows whose reasoning is structurally non-reproducible can still earn the independent-attestation guarantees of L4A without overclaiming reproducibility.

5.4 Supersession and amendment

The protocol does not permit modification of a step once signed. Amendment is expressed by appending new steps:

• An attest step of claim_type: supersession/retract about the original step records the retraction.
• A new step (typically of the same type as the original) records the corrected derivation.
• An attest step of claim_type: supersession/replace about both the original and the replacement records the binding between them.

Verifiers MUST treat a step as superseded if there exists in the proof an attest step with claim_type: supersession/retract or supersession/replace about it. As specified in §3.1, the structural ancestor closure preserves the historical derivation of every output; the effective ancestor closure used for conformance evaluation excludes superseded steps. An output that depends on a superseded predecessor and is not itself superseded fails structural validation (§3.1 step 7); a producer correcting an analysis MUST therefore supersede the affected output as well, or replace it with a non-superseded successor.

This pattern preserves the immutability of the chain while admitting the practical reality that regulated analyses are revised, and prevents the inadvertent retention of conclusions whose derivation has been retracted.

5.5 Insufficient-evidence findings

A reason step MAY declare its finding_type as no-finding, insufficient-evidence, negative-result, or a profile-defined variant (§2.2.3). Such steps are first-class evidence: they record what the analysis examined and what it could not conclude, and they are subject to the same well-formedness, signature, timestamp, and replay requirements as any other reason step. They are not the absence of analysis; they are the recorded result of an analysis that did not produce a positive finding.

The protocol's treatment of finding_type is structural. A finding_type of insufficient-evidence does not exempt the step from any conformance check; the step's input bindings, conditioned-on relations, replay class, and (at L4A or L4R) qualified review are checked as usual. The protocol does not by itself decide whether an insufficient-evidence determination is correct; that determination is the substance of qualified review, and may be the subject of an adequacy/finding-confirmed or adequacy/finding-disputed attestation (§2.2.4).

The motivation for first-class treatment is regulatory. In pre-submission contexts and adverse-event review, the analyses that found nothing are as important as the analyses that found something. A proof that records its no-finding outcomes alongside its conclusions provides a regulator a complete view of what the analysis examined; a proof that silently omits them does not. Profiles SHOULD require explicit finding_type for reason steps in regulated contexts rather than relying on the default conclusion.

Editor's note (§5). The level definitions are committed; the precise role vocabularies, approval claim-type vocabularies, high-stakes output classifications, and confirmatory-analysis designations that L4A and L4R require are profile-specific and not specified here. Reference vocabularies for the clinical-trials and finance regimes are sketched in §7.4 and §7.5 respectively.

7.0 The Profile Mechanism

A PoI profile is a specification document that binds the abstract protocol of §§2–3 to a concrete cryptographic ecosystem, identity model, and predicate vocabulary. Profiles are the protocol's mechanism for domain and ecosystem specialization without revising the base protocol.

The profile mechanism specified in this subsection is normative. The individual profile sketches in §7.1–§7.5 are informative placeholders; they become normative only if separately published as formal profile specifications.

A profile MAY specify:

• The signature scheme and key infrastructure (e.g., Sigstore keyless via OIDC)
• The timestamp authority and its verification procedure (e.g., Rekor inclusion proofs, RFC 3161 tokens)
• The canonical encoding algorithm if other than JCS
• The function-identifier resolution mechanism for compute steps
• The model-identifier and weights resolution mechanism for reason steps
• The resolution mechanism for content-addressed invocation and input_messages references
• The registered vocabulary of claim_type URIs and the authorized roles for each
• Whether the extended form of conditioned-on edges (§2.3) is required, and if so the registered context_role vocabulary
• The interpretation of "high-stakes output" and "confirmatory analysis" at L4A and L4R (§5.1)
• The required verification_basis (§2.7) for proofs within the profile's regulated scope
• The equivalence predicate vocabulary for tolerance-regime compute replay
• The finding_type vocabulary beyond the base set (§5.5)
• The input-message reconstruction predicate for reason step verification (§3.2 reason.d)
• Domain-specific predicates expressed as additional attest claim types
• Whether output steps may be of types other than compute and reason (§2.7)

A profile MUST NOT modify the four-step taxonomy, the three edge relations, or the verification algorithm of §3. Extension is by predicate vocabulary and resolution mechanism, not by new step types or new verification semantics. This constraint preserves the property that a single verifier implementation can verify a proof under any profile, given the profile's resolution services.

A proof manifest's profiles field (§2.7) lists the profile(s) under which the proof is to be verified; the verifier MUST apply each named profile's resolution rules and predicate set in addition to the base protocol's requirements.

7.1 Sigstore profile

Binds signature to Sigstore's keyless signing scheme. Binds timestamp to Rekor inclusion proofs. Specifies attestor URI form using OIDC subject identifiers. Specifies the authority model for §3.2's observe and attest checks via OIDC claim verification.

7.2 in-toto interoperability profile

Specifies how an observe step's provenance field references an in-toto attestation, and how a verifier consumes the in-toto attestation as part of the observe check. Provides a reverse mapping: a sequence of in-toto attestations representing a build pipeline can be lifted into an L1 PoI proof.

7.3 RFC 3161 timestamping profile

Specifies token format and authority resolution for environments where Sigstore Rekor is not appropriate.

7.4 Clinical Trials Profile (Informative, Forward-Reference)

A profile targeting clinical-trial readiness analyses and AI-assisted clinical decision support. Anticipated specializations include:

• Identity model. Industry-standard signing scheme (e.g., Sigstore via institutional OIDC) with role bindings for principal-investigator, biostatistician, qualified-reviewer, independent-validator, sponsor-medical-monitor, and data-monitoring-committee-member.
• Source-data integrity bindings. observe step provenance references MUST resolve to attestations from systems operating under 21 CFR Part 11 §11.10 (clinical data management systems with audit trails meeting predicate-regulation requirements), or to equivalent attestations under EU CTR Annex 11 or ICH E6(R3) §5.5.
• Prespecification predicates. Required claim_type vocabulary including prespecification/locked-sap, prespecification/locked-protocol, prespecification/locked-charter, each binding to a pre-DCO content-hashed external artifact.
• Subgroup analysis predicates. claim_type vocabulary including subgroup-analysis/prespecified and subgroup-analysis/post-hoc, allowing structural distinction between confirmatory and exploratory subgroup findings.
• Insufficient-evidence handling. finding_type vocabulary aligned with ICH E9(R1) estimand framework, distinguishing intercurrent-event treatment and missingness handling. Required for reason steps contributing to safety or efficacy determinations.
• Bias and fairness predicates. claim_type vocabulary for bias-assessment/subgroup-performance, bias-assessment/representativeness, supporting structural distinction between assessed and unassessed bias dimensions.
• Conformance level for hosted-model workflows. Anticipated to accept L4A for analyses on closed-weight hosted models with the required independent attestations, prespecification, and identity governance; L4R required for analyses where bit-identical reproducibility of primary endpoint reasoning is achievable and demanded by the regulatory regime.
• High-stakes output classification at L4R. Any reason or compute step contributing to a primary or co-primary efficacy endpoint, or to a safety determination at the protocol's prespecified threshold.

7.5 Finance Profile (Informative, Forward-Reference)

A profile targeting model risk management under SR 11-7 and analogous regulatory regimes. Anticipated specializations include:

• Identity model. Institutional signing with role bindings for model-developer, model-validator (independent per SR 11-7), model-owner, model-risk-officer.
• Source-data integrity bindings. observe step provenance MUST resolve to attestations from systems operating under firm-level books-and-records controls.
• Tiering predicates. claim_type vocabulary aligned with the firm's model tiering (typically three or four tiers); high-stakes classification under L4R at this profile is mapped to the firm's tier-1 or tier-2 designations.
• Effective challenge predicates. claim_type vocabulary for model-validator attestations recording independent replication, conceptual soundness review, and ongoing-monitoring sign-off.
• Lifecycle predicates. claim_type vocabulary for production-deployment, periodic-revalidation, retirement, supporting the lifecycle obligations of SR 11-7.

Profile sketches §7.1–§7.5 are informative with respect to the base protocol — non-normative until separately published as formal profile specifications — but a producer MUST identify the profile(s) under which a proof is to be verified, by reference, in the proof manifest (§2.7).

C.1 21 CFR Part 11 (Electronic Records, Electronic Signatures)

C.2 SR 11-7 (Model Risk Management)

C.3 FDA AI/ML Draft Guidance (Seven-Step Credibility Framework)

C.4 NIST AI Risk Management Framework (AI RMF 1.0)

C.5 ISO/IEC 42001 (AI Management System)

C.6 ICH E6(R3) (Good Clinical Practice) and ICH E9(R1) (Statistical Principles)

C.7 What These Mappings Do Not Establish

Each row above identifies a structural correspondence between a PoI mechanism and a regulatory requirement. None establishes that a proof conforming to PoI at any level constitutes compliance with the regulation. Compliance is determined by the regulator under the regulation's own evidentiary standards; PoI's role is to provide structured, mechanically verifiable evidence against which the producer's compliance claim can be assessed. PoI conformance is a necessary structural property for mechanical verification, not a sufficient compliance determination. The verification-versus-credibility distinction of §1.4 applies in full to every mapping in this appendix.