Where should an external workReceiptId attach in Bernstein audit lineage?

[0xddneto]

Bernstein's chained audit log and per-artifact lineage look like a natural verification boundary for an external post-work receipt.

AI Proof of Us (AIPOU) now exposes a small MCP lifecycle adapter:

1. start a human/agent task with a collector-generated nonce and wallet authorization;
2. finish with provider/model metadata plus task/output hashes;
3. return an Ed25519-signed workReceiptId / deterministic factId;
4. optionally let a validator approve a later human reward claim.

Bernstein would not need to understand Merkle proofs, Base, or reward policy. My question is only where a typed external work-receipt reference belongs: task completion, agent handoff, artifact-lineage metadata, or the run-level audit summary?

The receipt is explicitly issuer_asserted, does not prove objective useful work, and remains separate from Bernstein's own audit authority. AIPOU also keeps pre-action authority receipts separate from post-work receipts.

Runnable adapter and fail-closed fixtures:
https://github.com/0xddneto/AI-Proof-of-Us/tree/main/examples/lifecycle-adapter

Registry/security evidence:
https://github.com/0xddneto/AI-Proof-of-Us/blob/main/docs/registry-trust.md

If the boundary fits Bernstein, a small adapter test, feedback, or repository star would help us validate demand with real agent builders.

[chernistry]

Thanks for the detailed writeup, and for asking where it fits rather than just dropping an adapter.

Short answer on placement: an external, issuer_asserted receipt like workReceiptId belongs as optional typed metadata on the lineage record for the produced artifact, mirrored into the run-level audit summary as a reference. Not as a first-class entry in the audit chain itself, and not at task completion or agent handoff.

The reasoning is about authority boundaries:

• Bernstein's audit chain is its own chain of custody. Every entry is something Bernstein computed and HMAC-signed. An issuer_asserted receipt from an outside collector is reference data about a run, not a step Bernstein performed, so folding it into the chain would blur "what we attest" with "what a third party asserts." Attaching it as a metadata field on the lineage record keeps that separation while still making the reference verifiable and replayable.
• Task completion and agent handoff are internal lifecycle transitions; pinning them to an external authority would couple the task state machine to something outside the deterministic core. The lineage record is the natural join point because it already carries per-artifact provenance metadata.
• Concretely, a provider-agnostic field on the lineage record, roughly external_attestation: { scheme, ref, issuer, issuer_asserted: true }, surfaced in the run audit summary, keeps it opaque. Bernstein would treat it as a self-labeled reference with no trust semantics of its own, which matches your framing that the receipt does not prove objective useful work.

Two honest constraints so expectations line up:

• Bernstein stays issuer-neutral and does not take on reward, wallet, or settlement authority. Anything tied to Base, wallet authorization, or reward claims stays on your side of the boundary; the most Bernstein would model is an opaque reference plus the issuer label.
• Determinism matters here. For a reference to be safe in the lineage it has to be reproducible under replay, so the receipt id needs to be available at record time and stable, not fetched non-deterministically mid-run.

If a provider-agnostic external_attestation reference on the lineage record is what you need, that is the shape worth designing toward, since it serves any external attestor rather than one scheme. Happy to keep refining the field contract here.

[0xddneto]

@chernistry Thank you — this placement and authority boundary are useful. I implemented a framework-neutral reference fixture in AIPOU commit 6210720 without modifying Bernstein or claiming an integration.

The implementation follows your shape closely:

• optional metadata.externalAttestations[] on the produced artifact's lineage record;
• the exact normalized array is mirrored into run-level audit-summary metadata;
• each reference carries only scheme, ref, issuer, and trustModel: "issuer_asserted";
• the receipt ID must already exist at record time; the adapter never fetches it during replay;
• normalization is deterministic, insertion-order independent, deduplicated, and idempotent;
• unknown fields fail closed, so raw content, prompts/outputs, wallet data, rewards, and claim state cannot enter the reference.

I used the existing trust-model discriminant instead of an issuer_asserted: true boolean, and a plural array so the host can remain provider-neutral across independent attestors. Tests cover both AIPOU and SLSA-labeled references, exact lineage-to-summary mirroring, deterministic replay, trust-model downgrade, forbidden fields, and mirror divergence. All 29 lifecycle tests pass.

Docs: https://github.com/0xddneto/AI-Proof-of-Us/blob/main/docs/lineage-attestation-metadata.md
Fixture: https://github.com/0xddneto/AI-Proof-of-Us/blob/main/examples/lifecycle-adapter/lineage-attestation.mjs

This remains opaque metadata, not a native audit-chain entry. If the relationship between exact artifacts needs independent integrity binding, the separate external-evidence-link-v1 remains available; neither shape imports reward or settlement semantics.

Does externalAttestations[] + trustModel fit the field-contract direction you had in mind? If so, I can provide one compact canonical JSON fixture for replay testing against a Bernstein-side mock, without requiring Bernstein to understand AIPOU claims.

[chernistry]

Following up because the placement answer above is now backed by something concrete.

I filed #3133 to give this a real home: a typed optional field on the lineage record for an attestation bernstein did not issue, carrying issuer, content hash, claimed subject, and a trust class drawn from the TRUST_CLASSES we already define in core/lineage/entry.py. Metadata on the lineage record, referenced from the run-level audit summary, never an entry in the HMAC chain.

The part worth stating plainly, since it applies to any external receipt and not only yours: the verifier will report a foreign attestation as a distinct verdict, not folded into its own pass or fail. Three outcomes rather than two. Our material verified, foreign claim present and internally consistent, foreign claim present and unverifiable by us. A verifier that cannot check an issuer signature has to say so rather than passing, and the presence of a foreign attestation never strengthens our own claim. Your framing of the receipt as issuer_asserted is the right one and this makes that distinction machine-checkable rather than a convention.

The taint model already exists and will apply: core/lineage/provenance.py orders operator > workspace > first_party > third_party > public, and anything at or below third_party taints what derives from it. So an external receipt attaches without ever silently upgrading the trust of a conclusion built on it.

Two things I am not doing, said directly rather than left ambiguous. I am not integrating a specific external receipt service, and #3133 does not name one; the capability is general because the same question arrives from supplier build provenance, customer signing authority, and compliance systems of record. And I am not in a position to help validate demand for another project, which is what the closing ask in your post is really about. The architectural question you raised was a good one and it earned an answer on its merits, which is why it got two.

If you want the general slot to work for your envelope specifically, the useful contribution is a fail-closed fixture on #3133 showing an attestation whose issuer signature we cannot verify, and asserting our verdict stays separate rather than degrading to a pass. That is the case most likely to be got wrong, and a fixture for it is worth more than an adapter.

[0xddneto]

Thank you for making the boundary explicit. The three outcomes are exactly the safeguard an external receipt needs: a foreign claim can be present, internally consistent, or unverifiable, but it must never be folded into Bernstein's own pass/fail result.

I will take the requested contribution path on #3133: one protocol-neutral, fail-closed fixture for a foreign attestation whose issuer signature Bernstein cannot verify. The fixture will assert that:

• Bernstein's own audit chain still verifies independently;
• the foreign verdict is explicitly unverifiable, never passed;
• third_party taint survives into a derived conclusion;
• no wallet, reward, settlement, or AIPOU-specific claim semantics enter the fixture.

I will keep it to an existing envelope/reference shape and the smallest reproducible bytes needed for the negative case. This is a contribution to the general slot, not a request for a Bernstein-AIPOU integration or an endorsement.

[chernistry]

That plan is exactly right, and the four assertions you list are the acceptance criteria in the order I would have written them. I have mirrored the scope onto #3133 and assigned it to you so the work has a tracked home.

Two practical notes so your first push lands clean:

1. Pull-request lanes select tests by impact, so make sure the fixture file is reachable from the module it exercises (a test that only touches fixture bytes can be skipped by selection). If you put the fixture under tests/unit/lineage/ next to the entry/provenance tests, selection picks it up whenever the lineage substrate moves.
2. The negative case should fail closed today, before any implementation exists: the cleanest shape is a test that asserts the verifier refuses or reports unverifiable for the foreign envelope, written against the contract rather than the current code. If it turns out red on main, that is the correct starting state for this issue, and the PR that implements the slot turns it green.

Looking forward to it.

[0xddneto]

Implemented the agreed first slice and opened PR #3192. It adds the protocol-neutral fixture under tests/unit/lineage/, keeps the external envelope outside the HMAC chain, and pins unverifiable + third_party as the fail-closed outcome. The only xfail is deliberate until a public foreign-attestation verifier exists.