Dynamic Model Update Provenance

Document type: Supplemental report derived from a sealed collaboration bundle hosted as a GitHub repository
For: AAIS Proof-of-Control project committee, insurers, and Provenance working group
Issued by: Pathways Project feedback collaboration
Engineering: DJ Thomson
Date: June 2026
Repository channel: djat-poc-20260602 · authoritative folder collaboration/20260602-160000/

Covers: The Dynamic Update Proof Loop, the Model Update Apply pattern, PoC-relevant scenarios, and why private trackability of training, inference, and updates matters
Status: The loop is designed and encoded in this repository; execution is pending (see validation proof slot)

Welcome

Why model changes matter for PoC

AI systems do not stand still after deployment. They are patched, fine-tuned, given new tools, rolled back, and governed under revised rules. For Proof-of-Control, that movement is the hard part: not only whether a system behaved within bounds at one moment, but whether each change left a trail an insurer, regulator, or counterparty can check without relying on the operator’s word or live access to production.

A collaboration container, not a standard

This brief is one readable chapter from a larger artifact: a proposed collaboration container, a sealed folder inside a GitHub repository that holds structured feedback on PoC architecture v0.1.0. The container is hash-bound, signed, and self-describing; anyone can verify its contents offline without trusting the authors or touching production systems. It is not an AAIS standard. It is a working sketch of how parties might exchange evidence, attribution, and early design ideas in a portable package.

Provenance as the through-line

The focus here is PoC’s Provenance domain, already flagged as proposed and TBD in the May 2026 draft, not invented in this repository. Rather than treating that label as a footnote, this brief argues Provenance should be central: chain-of-custody, model lineage, and collaborative context belong in PoC, especially when systems change after deployment.

The ideas below are early (we hope clear enough to react to) but they are only the surface. The same repository carries analysis PDFs, origin exports, pre-registered hypotheses, Pathway templates, and a full provenance ledger. Appendix A explains how the repository relates to this brief; Appendix B inventories the bundle; Appendix C lists Pathways encodings that mirror the prose as executable patterns, not narrative alone.

The Dynamic Update Proof Loop

The pattern this brief walks through is the Dynamic Update Proof Loop and its core step, Model Update Apply: bind authorized context to a before-and-after state transition, record what happened, return proof into the sealed package, re-seal, and let anyone run an offline integrity check. What follows is eight realistic scenarios where that pattern would apply, the exercises that could prove each one, and one singular experiment already encoded here (H-POC-VALIDATE) that can demonstrate the shared mechanism on this bundle itself before any wider adoption decision.

How to read this brief

You do not need to read pathway YAML, run a GPU cluster, or treat Pathways as production infrastructure to follow the argument. Technical sidebars throughout hold precise IDs and file paths for reviewers; skip them on first pass if you prefer.

What this brief is: A readable map of mechanism, scenarios, and proof strategy, and an invitation to inspect the collaboration container that carries them.
What this brief is not: A claim that AAIS has adopted any of this, or that every scenario has already been executed in production. Most are design targets; one exercise (H-POC-VALIDATE) is ready to run against this bundle itself.

Technical sidebar: verify command python3 tools/collaboration-bundle/sign_bundle.py verify collaboration/20260602-160000

Pathways and PathwayRuns: context for this brief

Pathways Architecture (open project, v1.1.0) is a pre-existing framework for describing multi-step AI workflows (who ran which step, with what inputs, under which gates) and recording the result as auditable artifacts. A Pathway is a reusable template (for example, “apply a model update with provenance”). A PathwayRun is a specific execution of that template: a ledger row with timestamps, outputs, and lineage back to upstream context.

This brief does not ask the PoC committee to adopt Pathways wholesale. It proposes that Pathways-style recording could implement some aspects of PoC’s Provenance domain. PoC defines what provenance questions must be answerable; Pathways offers one mature how for generating and binding answers when models change after deployment.

In this repository, every major artifact is tied to a PathwayRun in pathway-runs/. That is how the feedback records who contributed what, when, and under which hypothesis, without claiming AAIS endorsement.

Technical sidebar PathwayRun index: pathway-runs/index.yaml. Asset map: pathway-runs/ASSET_PROVENANCE.yaml. Co-originator record: collaboration-pathways/meta/co-originator-attribution.yaml.

LCP analysis: legal terms alongside provenance

Agentic systems need more than one kind of evidence. PoC asks whether independent proof exists of what a system did at runtime. LCP (Legal Context Protocol, v1.4-draft, co-stewarded by AAA-ICDR and Integra Ledger) asks a different question: which legal terms governed a transaction, and can a counterparty prove which version of those terms applied?

This repository includes dedicated LCP analysis (separate sidecars and executive briefs, summarized here) because model-update provenance rarely stands alone. When an enterprise fine-tunes on licensed data, rolls out an adapter, or changes approval policy, insurers and counterparties often need three layers at once:

These layers are complementary, not interchangeable. LCP explicitly scopes to legal-context discoverability and permanence, not AI output quality or operator logs. PoC scopes to cryptographic verification of control, not contract formation or click-through UX. The Dynamic Update Proof Loop proposed here binds the middle and bottom rows in one sealed package; the LCP analysis in this repository argues for hash-linked cross-references to the top row, not merged claims like “one hash proves everything.”

Why LCP analysis matters for this brief

• Scenario B (licensed fine-tune): Training must stay inside approved data and approved terms. An LCP atrHash can bind the license; the update loop binds model state before/after.
  
• Scenario H (policy / gate update): Governance rules can change without retraining weights. Legal authority to approve may itself be terms-governed (LCP) while the policy artifact change is provenance-governed (this loop).
  
• Disputes: AAA’s framing separates “which terms applied?” (LCP) from “what did the agent do?” (PoC). Insurers need both primitives, linked, not conflated.

What the bundled LCP analysis established (summary)

The full analyses live in linked sidecars. Headline findings:

• Payment, identity, and checkout protocols (MPP/x402, ACP, UCP, AP2, agent pay rails) handle value transfer but defer terms binding to a legal layer LCP is meant to supply.
  
• LCP uses a familiar internet pattern: one well-known URL, one discovery file, one hashable terms JSON (analogous to robots.txt or OpenID configuration).
  
• Four levels of trust (informational → provable → signed → integrated) scale evidence to transaction stakes without claiming PoC-style runtime proof.
  
• Convergence recommendation (ranked P0 in sidecar): never merge bundle seal hash and LCP atrHash into a single hash; preserve independent verify domains with explicit cross-reference fields.

Where to read more

• Plain English: PoC_LCP_Standards_Brief.md
  
• Protocol context analysis: sidecars/context-analysis-legal-context-protocol.md
  
• Bundle × LCP convergence: sidecars/convergence-analysis-bundle-x-lcp.md

Technical sidebar: future co-binding Proposed extension (not executed): record optional legal_context_ref (LCP atrHash) alongside upstream_context_anchor in model_update_provenance_json when H-POC-VALIDATE runs. See convergence sidecar Rank 3.

Shared design space: PoC attribution and cross-project coordination

When AAIS published architecture v0.1.0 and invited structured feedback, it set out a shared vocabulary (domains, tiers, trust assumptions, and the verification-vs-validation boundary) that responses could extend without replacing. This repository is one such response: it sits inside that design space, carries explicit lineage back to the draft and its contributors, and proposes scaffolding for coordination between PoC (what must be answerable) and Pathways (one mature way to record answers).

That lineage matters for attribution. PoC committee chairs, contributors, and the May 2026 draft text are part of the chain behind every proposal here. Dynamism classification, Model State Identity, the Provenance domain, and the Dynamic Update Proof Loop are extensions of questions the initiative already raised, especially around mutable and self-modifying systems, not a parallel invention.

The repository records that relationship in origin exports (analysis sessions and derivatives), PathwayRun lineage (which pathway produced each file), and co-originator metadata, not as a claim of AAIS endorsement, but as scaffolding for cross-project collaboration between an established standards initiative (PoC) and an established orchestration project (Pathways).

Concretely, the scaffolding enables:

PoC adopters, Pathways implementers, and LCP stewards (see LCP analysis above) can therefore coordinate on evidence shape and attribution without collapsing organizational boundaries. Each project keeps its normative authority; the bundle format carries who contributed what, when, and under which hypothesis.

Scenarios at a glance

Section 5 develops each scenario in depth. Here is the full set in one view.

Every scenario shares the same shape: sealed context anchor → Model Update Apply (before/after state) → proof returned into the package → optional sole signatory confirm → re-seal and verify: OK.

What proves what: exercises and hypotheses

Proof is layered. Format proof shows the loop can close. Domain proof shows a specific scenario’s payload (weights, adapters, tools, policy) binds correctly. Production proof shows the pattern at operational scale. This repository targets format proof first; domain proofs extend it.

Full registry: collaboration-pathways/test/HYPOTHESES.md

The one exercise that opens the door to all scenarios

H-POC-VALIDATE is deliberately designed as a single experiment whose success validates the entire collaboration-bundle-as-anchor thesis, the substrate every scenario above depends on.

If H-POC-VALIDATE succeeds, you have shown:

1. Anchor: A sealed package (this bundle) can be declared cryptographic context with verifiable hashes and signature.
   
2. Apply: A model update pathway can bind upstream_context_anchor to that package’s bundle_root_hash and origin manifest, recording state before and after.
   
3. Prove: A PathwayRun and model_update_provenance_json (plus optional Aqua revisions) constitute auditable evidence.
   
4. Return: Proof artifacts land in assets/validation-proof/ and enter the content manifest.
   
5. Confirm: Sole signatory (or successor policy) attests acceptance criteria; signatory roster itself is mutable via recorded pathway.
   
6. Re-seal: verify: OK on the enlarged bundle proves the loop closed without breaking integrity.

Why one exercise covers all scenarios: Scenarios A–H differ in what changes (weights, adapters, tools, policy YAML) and who must trust whom. They do not differ in the mechanism PoC needs: immutable context in, provenance record out, offline verify by anyone. H-POC-VALIDATE proves that mechanism on this repository’s own artifacts, the most honest first step, because the bundle already contains the analysis, hypotheses, and pathway definitions that justify the update.

Recommended instantiation for H-POC-VALIDATE (minimal, honest): Treat Scenario H as the live payload: update practice profile / gate rules or bundle validation policy metadata through Model.Update.Apply, not a fictional weight tensor. That exercise is technically accomplishable today, matches what the repository actually contains, and still proves the loop every other scenario would reuse. Scenario-specific extensions (MSID over weights, federated aggregation attestations, behavioral envelope metrics) then become H-POC2–H-POC7 add-ons, not prerequisites for believing the format works.

Success criteria (unchanged):

• Proof files under assets/validation-proof/ with SHA-256 in CONTENT_MANIFEST.yaml
  
• model-update-pathway-run.json references this bundle’s context anchor
  
• sole-signatory-confirmation.json recorded per policy
  
• python3 tools/collaboration-bundle/sign_bundle.py verify collaboration/20260602-160000 → verify: OK

What H-POC-VALIDATE alone does not prove: That a hospital federated round ran correctly (Scenario E), that a LoRA file hash matches production GPU memory (Scenario C), or that behavioral drift stayed within bounds (Scenario D). Those require the supplementary exercises in the table above, but none of them matter if the loop cannot close once. Run H-POC-VALIDATE first; extend by scenario as committee priority dictates.

Technical sidebar: singular exercise artifacts Expected outputs: context-anchor-descriptor.json, model-update-pathway-run.json, dynamic-update-proof.json, sole-signatory-confirmation.json. Orchestrator: Collaboration.Validation.DynamicUpdateProofLoop@v1. Update step: Model.Update.Apply@v1.

How to read this brief

The main text is written in plain English. Technical sidebars (indented blocks labeled “Technical sidebar”) hold precise terms, pathway IDs, and implementation notes. Skip them on first pass if you prefer.

1. The problem in one paragraph

Proof-of-Control asks whether an AI system can show independent evidence of what it did at runtime. That question is hard enough for a fixed model. It becomes much harder when the model changes (after fine-tuning, a safety patch, new retrieval data, or an adapter swap) because “the model” is no longer the same artifact auditors thought they were evaluating.

The Dynamic Update Proof Loop is a proposed pattern (not part of AAIS PoC v0.1.0 today) for answering: Given a sealed record of why and how a change was authorized, can we apply an update, produce a verifiable proof, and fold that proof back into the same sealed record, without trusting the operator’s word alone?

The Model Update Apply pattern is the middle step: the actual “apply the change and document before/after state with full lineage.”

Technical sidebar: Pathway IDs - Loop orchestrator: Collaboration.Validation.DynamicUpdateProofLoop@v1 - Update step: Model.Update.Apply@v1 (v1.1.0) - Context binding: Collaboration.Bundle.CryptographicContextAnchor@v1 - Singular test hypothesis: H-POC-VALIDATE

2. Two ideas to keep separate

2.1 Verification vs validation (PoC language)

• Verification: Cryptography and procedure show what happened and whether declared boundaries were respected.
• Validation: Humans or governance decide whether the change was wise, legal, or aligned with intent.

The loop is built for verification. A sole signatory confirmation (policy layer) is validation that the committee’s acceptance criteria were met, not a substitute for cryptographic verify. Who holds signatory authority, and what criteria apply, are policy fields that can change via Collaboration.Validation.SoleSignatoryConfirm@v1 (Section 3, Step 5).

2.2 Context anchor vs model state

• Context anchor: An immutable snapshot of the collaborative and documentary world that justified an update (reports, sessions, policies, hashes). In this repository, a sealed collaboration bundle is proposed as that anchor.
• Model state: The actual weights, adapters, prompts, tools, or policies inside the running system, captured as as “before” and “after” identifiers.

The loop binds context (why we were allowed to change) to state (what changed).

Technical sidebar: model_update_provenance_json Proposed record fields include: model_state_id_before, model_state_id_after, authorizer_did, upstream_context_anchor_ref, pathway_run_id. Maps conceptually to PoC Provenance questions: who authorized, what changed, when active, what context applied.

3. The full mechanism: six steps

Think of the loop as a closed circuit. Proof that starts outside the sealed package must return inside and survive a new integrity check.

Flow: 1 Anchor → 2 Update → 3 Prove → 4 Return → 5 Confirm → 6 Re-seal

Step 1: Anchor

A verifier confirms the context package is intact: every file matches published hashes; signature checks out. The package is then declared the upstream context for any update that follows.

Plain English: “This exact body of evidence, not a paraphrase, not a link that might rot, is what authorized thinking about a change.”

Technical sidebar: anchor contents CONTENT_MANIFEST.yaml, bundle_root_hash, BUNDLE_SIGNATURE.json, ORIGIN_MANIFEST.yaml, pathway-runs/ index, optional Aqua attestations. Output: context-anchor-descriptor.json.

Step 2: Update (Model Update Apply)

Five internal phases:

Certain acts are marked non-delegable (for example, publishing a model update or expanding the safety envelope cannot happen without explicit human gate approval in the design.

Technical sidebar: gate profile non_delegable_acts: [publish_model_update, modify_safety_layer, expand_capability_envelope]. Default autonomy band A1 (supervised). RIS §4.8 authority boundaries are planned engine features; encoded in pathway YAML today.

Step 3: Prove

The update run itself becomes evidence: step-level audit (models used, durations, inputs/outputs), optional cryptographic attestations on templates/runs, index entry in the provenance ledger.

Plain English: “We can show the update procedure ran, not just that someone claims it ran.”

Step 4: Return

Proof artifacts are written into a dedicated validation proof area inside the same sealed package, so assessors receive context + update + proof in one offline-verifiable unit.

Expected artifacts:

• context-anchor-descriptor.json
• model-update-pathway-run.json
• dynamic-update-proof.json
• (after Step 5) sole-signatory-confirmation.json

Step 5: Confirm (policy)

A designated sole signatory attests that acceptance criteria for the loop were met. In this bundle’s current policy, that role is Tricia Wang (AAIS Society PoC committee). This is organizational validation, recorded as its own artifact, distinct from from cryptographic verify.

Important: The signatory is not fixed forever. Policy is mutable: true: the current signatory may revise criteria, name a successor, or delegate to a different governance process (for example, a multi-member working group or threshold roster), but only through a recorded PathwayRun of Collaboration.Validation.SoleSignatoryConfirm@v1, not a silent edit. That mutability is itself a pattern primitive: governance evolution leaves the same provenance trail as model updates.

Technical sidebar: sole signatory policy Current policy: bundle-validation-policy.v1.yaml. Change mechanism: policy_change.how → PathwayRun via Collaboration.Validation.SoleSignatoryConfirm@v1. Output: updated policy YAML + sole-signatory-confirmation.json.

Step 6: Re-seal

The package is sealed again. Anyone can run offline verify. Success criterion: verify: OK on the enlarged package, meaning the proof returned home and still matches the manifest.

Technical sidebar: verify command python3 tools/collaboration-bundle/sign_bundle.py verify collaboration/20260602-160000

4. Implementation: parties, stages, and cooperative governance

This section describes how the pattern could work in practice, not as a single vendor product, but as a common governance substrate multiple independent parties can adopt without surrendering agency.

4.1 Likely parties

{: colwidths=“22 34 44”}

No party needs to trust another’s internal logs. Each verifies artifacts exchanged, not operational access.

4.2 Stage-by-stage responsibilities

4.3 What frontier model companies would plausibly do

Frontier labs and API providers are unlikely to merge governance with customers or standards bodies. Under this pattern they would more likely:

• Publish model state manifests (MSID or Merkle root over weight shards) at release time, without exposing weights
  
• Accept sealed context anchors as authorization inputs for customer-specific fine-tunes or adapter slots they support
  
• Record their own PathwayRuns for training and release pipelines they control
  
• Exchange proof bundles with enterprise deployers and insurers using a shared schema, not a shared control plane

That preserves commercial independence while making “which model state served this customer at time T?” answerable offline.

4.4 Cooperative best practices without collapsing agency

The pattern is designed so best practices can emerge cooperatively rather than by central mandate:

Multiple collaborators (AAIS PoC, Pathways implementers, frontier labs, enterprises) can coordinate on provenance while each retains authority over its own normative scope. The bundle carries attribution; it does not transfer endorsement.

Technical sidebar: reference deployment stack Minimum: sign_bundle.py verify, PathwayRun JSON, Model.Update.Apply@v1 YAML. Fuller: Aqua attestations, MSID external binding (H-POC3), behavioral envelope (H-POC7), multi-party Run Source hypergraph for federated scenarios.

5. PoC-relevant scenarios (plain English + what would be accomplished)

Each scenario below assumes the loop machinery exists in a deployment. This repository encodes the pattern as a demonstration target (H-POC-VALIDATE), not a live production run. See What proves what, exercises and hypotheses for the mapping from scenario to hypothesis; H-POC-VALIDATE (Scenario H payload recommended) proves the shared substrate for all of them.

Scenario A: Safety patch after committee feedback

Situation: An enterprise deploys an internal agent. AAIS-style feedback arrives as a sealed bundle (architecture review, gap analysis, recommended guardrails). Security requires a safety-layer patch before wider rollout.

What happens:

1. The feedback bundle is the context anchor, hash-bound, offline-verifiable.
2. Model Update Apply records model state before/after the patch, bound to that anchor.
3. Proof returns into the bundle; re-seal; verify OK.

What PoC gains: Evidence that the patch was applied in response to a specific, immutable context, not an undocumented hotfix.

Technical sidebar Maps to PoC Security and Authorization domains; proposed “Model Updated” lifecycle stage. Dynamism band: Periodically Updated.

Significance dimensions:

Scenario B: Fine-tune on licensed data with contractual terms

Situation: A model is fine-tuned on a licensed dataset. Contract requires proof that training used only approved data and that the resulting weights are traceable to that approval.

What happens:

1. Context anchor holds license terms, data manifest hashes, and approval signatures (could be LCP-linked terms hash in a fuller stack).
2. Update apply records before/after model state and binds data references in provenance.
3. Proof package supports audit: “This model state descended from that authorized data context.”

Technical sidebar MSID (Model State Identity) as Merkle root over weight shards is proposed, not v0.1.0. Pathways records MSID externally computed; does not hash tensors itself.

Significance dimensions:

Dynamism band: Periodically Updated to Continuously Learning depending on retrain cadence.

Scenario C: LoRA / adapter swap in production

Situation: Production uses a base model plus small adapters (LoRA, Low-Rank Adaptation: lightweight weight modules trained on top of a frozen base). Product swaps adapter v3 → v4 for a customer segment without retraining the full base.

What happens:

1. Anchor holds change ticket, eval results, and approval for adapter v4.
2. Update apply captures minimal state delta (adapter IDs, hashes) before/after.
3. Inference requests can cite model_state_id_after in PoC evidence.

Technical sidebar Vector commitments / subset-change proofs are research-grade extensions; Merkle over adapter files is near-term practical.

Significance dimensions:

Dynamism band: Periodically Updated.

Scenario D: Continuous learning with behavioral envelope

Situation: A continuously learning system updates from production feedback on a schedule. Regulators fear silent drift: behavior shifts without visible approval.

What happens:

1. Each update cycle runs the loop with anchor = policy + eval suite results for that window.
2. Behavioral envelope check (proposed): post-update metrics compared to pre-authorized thresholds; result attested.
3. Tier 3-style continuous monitoring evidence accumulates as a series of sealed proof returns.

Technical sidebar Proposed Model.Verify.BehavioralEnvelope@v1; Tier 3 operational rules (max unattested window, drift SLAs) not in PoC v0.1.0.

Significance dimensions:

Dynamism band: Continuously Learning.

Scenario E: Multi-party federated update

Situation: Three hospitals jointly improve a diagnostic assist model via federated learning, no raw patient data leaves sites.

What happens:

1. Anchor holds multi-party agreement, threshold authorization policy, and aggregation rules.
2. Update apply records aggregation event with participant attestations (who contributed round N).
3. Proof supports dispute: “Hospital C’s contribution was included per policy.”

Technical sidebar Threshold signatures and MPC aggregation proofs are complementary; Run Source hypergraph models multi-party lineage.

Significance dimensions:

Dynamism band: Periodically Updated or Continuously Learning.

Scenario F: Agent tool/plugin graph change

Situation: An agentic deployment adds a new tool (e.g., payment API). PoC cares about boundary crossing, not just weight changes.

What happens:

1. Anchor holds security review of the new tool and boundary definitions.
2. Update apply treats tool manifest + policy graph as part of model state (configuration state, not only weights).
3. Runtime PoC evidence links actions to configuration state ID after tool add.

Significance dimensions:

Dynamism band: Periodically Updated (config) even if weights static.

Scenario G: Rollback after incident

Situation: An update causes an incident. Operations rolls back to prior model state. Insurer asks: “Did post-incident traffic use the bad state or the rollback?”

What happens:

1. Historical proof artifacts retain state ID N (bad) and state ID N−1 (good).
2. Rollback is itself an update through the loop with anchor = incident report.
3. Post-rollback inference evidence references N−1 with monotonic sequence (anti-replay).

Technical sidebar Proposed anti-rollback: hardware counters or transparency-log sequence numbers.

Significance dimensions:

Scenario H: Specification / policy update (non-weight change)

Situation: An organization updates practice profile or gate rules (who may approve what) without changing neural weights, common in governed agent deployments.

What happens:

1. Anchor holds governance committee minutes and revised policy YAML.
2. Update apply records policy revision hash before/after (same machinery as spec self-provenance in Pathways RIS).
3. Proves agent behavior afterward was governed by policy revision R, not R−1.

Significance dimensions:

Dynamism band: Static weights, Periodically Updated governance.

6. Dimensions of significance: private trackability and provenance

“Private trackability” here means: a third party can verify lineage and control evidence without live access to your training cluster, without trusting your internal logs alone, and often without exposing trade-secret weights or raw data.

5.1 Three lifecycle phases

5.2 Significance matrix (who benefits)

5.3 What remains honestly unproven

Even a perfect loop does not prove:

• The update improved accuracy or safety (validation, not verification)
• Training data was ethically sourced (unless anchored separately)
• Future inference will stay in bounds (requires ongoing PoC runtime evidence)
• Agent had legal authority to act for a principal (LCP / contract layer)

Technical sidebar: PoC scope Aligns with draft strength #7: verification not validation. Loop strengthens Provenance domain proposals, not output correctness.

7. System dynamism classification (proposed)

PoC v0.1.0 does not yet require this taxonomy; feedback in this repository proposes it so assurance claims scale honestly with how much the system changes.

{: colwidths=“16 30 28 26”}

Full band names in PoC feedback: Periodically Updated, Continuously Learning, Self-Modifying, Recursive self-improvement.

Important nuance: Autonomy (how much the agent decides alone) and dynamism (how much the model changes) are different axes. A static model can run autonomously; a learning model can be tightly supervised.

Technical sidebar Proposed distinct fields: autonomy (A0–A3) and dynamism_band on each run. Do not collapse into one score.

8. What success looks like for this repository

H-POC-VALIDATE success criteria (when executed):

1. Proof files present under assets/validation-proof/ with hashes in the content manifest
   
2. model-update-pathway-run.json references this bundle’s context anchor
   
3. Sole signatory confirmation recorded
   
4. verify: OK after re-seal

Current status: design_pending: pathways and proof slot exist; loop not yet run.

For the PoC committee: Success demonstrates a reference pattern for the proposed Provenance domain and “Model Updated” lifecycle, not AAIS adoption until you choose to adopt it in WD 1.0.

Appendix A: GitHub repository supplement

Readers who arrive via GitHub see a feedback repository (djat_x_poc), not the AAIS PoC standard. The repo root is a pointer; the authoritative artifact is the dated bundle folder:

collaboration/20260602-160000/

That folder is a signed collaboration bundle: executive summaries (including this brief), architecture review PDFs, origin exports from multi-model analysis sessions, pre-registered hypotheses, Pathways templates with Aqua attestations, and an empty validation-proof slot pending H-POC-VALIDATE.

Integrity: verify: OK means bytes match the manifest and signature since last seal, not committee endorsement.

Relationship to this brief: Sections 1–8 are self-contained. The repository holds depth (full gap analyses, sidecars, pathway YAML, proof scaffolds) that this supplemental report summarizes and points to.

Appendix B: Repository inventory (high level)

Machine-readable index: collaboration-manifest.yaml · run ledger: pathway-runs/index.yaml

Appendix C: Pathways templates and enhancements encoded in this bundle

Every mechanism described in this brief has a Pathways encoding, new templates introduced for this PoC instance, or enhancements to the collaboration-bundle technique canon. Aqua-attested YAML lives under poc-pathways/ and collaboration-pathways/.

PoC-facing pathways (poc-pathways/)

Collaboration-bundle pathways introduced or extended (collaboration-pathways/)

Full indexes: poc-pathways/pathways-index.yaml · collaboration-pathways/pathways-index.yaml

Hypothesis registry (experiments that can prove scenarios in Section 5): collaboration-pathways/test/HYPOTHESES.md

Related reading (in-bundle)

Supplemental report from Pathways Project feedback collaboration (Engineering, DJ Thomson). Proposed patterns are not part of AAIS PoC architecture v0.1.0 unless the committee adopts them. Repository inventory: Appendices A–C.