Repository navigation
Downstream TRACE v0.2 consumer — evidence boundary observed in institutional reconstruction #223
Description
We have built an experimental downstream consumer of TRACE v0.2 focused on carrying verifiable agent-execution evidence into institutional evidence reconstruction.
In our interoperability work, we tested the separation between:
- session/runtime evidence;
- action issuance evidence;
- externally issued outcome evidence; and
- the subsequent institutional reconstruction layer.
One boundary has proved particularly important: a technically verified execution or valid action receipt should not automatically be promoted into proof that the corresponding physical, business, human or institutional outcome occurred.
Our prototype therefore preserves those states separately and hands them downstream with explicit proof boundaries. For example, a valid controller acceptance remains distinct from physical completion, institutional adoption, human validation and legal/business effect unless separate evidence establishes those facts.
This appears closely aligned with the direction now reflected in TRACE v0.2 and with the current work around binding external facts and attributable human-approval outcomes.
We would be interested in understanding whether this downstream institutional-evidence boundary is something the TRACE maintainers expect to remain deliberately outside core TRACE as the specification progresses toward v1.0.
We are happy to share a minimal interoperability demonstration and test observations. The internal reconstruction methodology itself is outside the scope of what we are disclosing.
N’KEMBA — Institutional Evidence Reconstruction
Experimental downstream TRACE consumer
Activity
riscas028 commentedon Aug 26, 2026
Update: we have now published a minimal external-safe downstream integration demonstrating the evidence boundary described in this issue.
The public repository includes a reproducible test against an official TRACE v0.2 signed vector. The test verifies the signed technical record, detects tampering, and deliberately preserves the distinction between technical evidence and downstream institutional claims.
In particular, a technically valid TRACE record is not automatically promoted into proof of physical completion, human validation, institutional adoption, legal effect, or business effect.
The same test is now running successfully in GitHub Actions in a clean hosted environment.
Public repository:
https://github.com/riscas028/nkemba-trace-handoff
We would welcome a technical review of this evidence boundary and whether it matches the intended downstream role of TRACE as the specification progresses.
The public repository contains only the interoperability boundary and test material. N’KEMBA’s internal institutional-reconstruction methodology is not disclosed.
— N’KEMBA, Institutional Evidence Reconstruction
imran-siddique commentedon Aug 26, 2026
Yes. The boundary stays outside core TRACE, deliberately, and it is not a v1.0 open question.
Answering directly because you asked a direct question and because you built something before asking it. I looked at
nkemba-trace-handoff:handoff.py,test_handoff.py, and a "TRACE boundary validation" workflow that failed at 17:41 and passed at 17:44 in a clean hosted runner. Testing against an official signed vector and demonstrating tamper detection alongside the boundary is more than most interoperability reports arrive with.Where TRACE already commits to this
Three places, none of them new, and one merged yesterday.
docs/verification-outcome-statements.md(#215) exists for exactly your concern. Every row pairs the strongest statement a verifier outcome supports with the claim that must stay out of the same sentence. The row for a fully verified record says outright that it is "not success of any physical or business outcome". The page's stated purpose is preventing assurance overclaim, "a conclusion written slightly stronger than the evidence behind it, so that a valid signature quietly becomes the agent complied."§3.1.2's
referencesrule. A verifier MUST NOT treat a resolved reference as attested evidence. A record can point at a fact held by an institution, commit to its digest, and name who is obliged to keep it resolvable, and none of that makes the fact true.cMCP's
outcome_unknown, landed this week. When an upstream tool may have executed and nothing establishes whether it did, the record says so rather than resolving to either answer.confirmed_occurredandconfirmed_absentare deliberately not written by the runtime, because a gateway is not a system of record for physical effects.Why it stays outside, rather than being unfinished
The line is the product. TRACE proves the environment was intact, the policy was bound, and the record was not altered after issuance. Whether a payment settled, a shipment arrived, or a person was actually informed are facts held by systems that are authoritative for them, and a runtime attestation cannot become authoritative for them by referencing them harder. A specification that blurred that would be more useful to demo and less useful to audit.
So your prototype is not working around a gap. It is implementing the boundary the specification asserts, which is why it lines up.
You are the third this week
Independently, and from different directions: a financial-mandate proposal reached the same distinction for settlement and KYC, and the cMCP work reached it for irreversible tool effects. Three unconnected parties converging on one boundary is the strongest signal we get that it is drawn in the right place.
Two things
Yes to the interoperability observations, and the most useful form is the negative cases: inputs where a naive consumer would promote a technical verification into an institutional claim, and what your layer does instead. Those make better conformance vectors than the passing cases.
Practical note: your repository's licence reads
NOASSERTIONto GitHub, so it cannot classify what people may do with the demonstration. Worth fixing if you want others to build on it.riscas028 commentedon Aug 27, 2026
Thank you for the direct review and for clarifying that this is a deliberate TRACE boundary rather than an unfinished v1.0 question.
We incorporated both pieces of feedback.
The public repository now uses a canonical Apache-2.0 LICENSE, with a separate NOTICE making clear that the open demonstration does not disclose or license N’KEMBA’s private institutional-reconstruction methodology.
We added three external-safe negative boundary cases, specifically following your suggestion:
Each case deliberately preserves the unsupported downstream claim as
NOT_PROVEDrather than promoting technical verification into an institutional assertion.These cases are now part of the reproducible GitHub Actions workflow alongside the official TRACE v0.2 signed-vector test. The clean hosted run is green:
https://github.com/riscas028/nkemba-trace-handoff/actions/runs/33049301875
Negative-case material:
https://github.com/riscas028/nkemba-trace-handoff/blob/main/tests/test_negative_boundary_cases.py
Repository:
https://github.com/riscas028/nkemba-trace-handoff
We have intentionally kept the cases minimal and conformance-oriented; the downstream institutional-reconstruction method remains outside the public repository.
— N’KEMBA, Institutional Evidence Reconstruction
riscas028 commentedon Aug 27, 2026
riscas028 commentedon Aug 29, 2026
A concise interoperability boundary we are using in the N’KEMBA downstream reconstruction work is:
Trust Record / runtime evidence → action issuance or receipt → independently evidenced external outcome → institutional reconstruction.
The key requirement is that each transition preserves its proof boundary. A verified Trust Record can establish facts about execution under the TRACE evidence model; an action receipt can establish issuance/acceptance as defined by that receipt; neither should, without separate evidence, be promoted into proof of the external outcome or of the subsequent institutional/legal effect.
For downstream consumers, it would therefore be useful if TRACE continues to make this boundary explicit and remains interoperable with external outcome evidence and institutional reconstruction layers, rather than absorbing those layers into the meaning of a Trust Record.
Our current N’KEMBA work treats TRACE records as potentially strong evidence inputs, while preserving separate states for corroborated, contested, inferred and not-confirmed downstream facts. This allows institutional reconstruction to ingest TRACE evidence without changing what TRACE itself attests.
We are recording this as an interoperability observation, not proposing that TRACE attest institutional truth or expand beyond its intended scope. The proprietary reconstruction methodology remains outside this disclosure.
riscas028 commentedon Aug 30, 2026
Small follow-up: the public N’KEMBA interoperability repository now links to an interactive public demonstration of the downstream institutional-reconstruction boundary discussed here:
https://nkemba.pt/pilot.html
The interactive demonstration is complementary to the external-safe
nkemba-trace-handofftests. It is intended to make the proof boundary inspectable at case level while keeping the proprietary reconstruction methodology outside the public repository.No TRACE certification or formal conformance is claimed.
— N’KEMBA, Institutional Evidence Reconstruction
imran-siddique commentedon Sep 3, 2026
Closing this one, because the question it asked has been answered and the work has moved to threads where it can land.
You asked whether the downstream institutional-evidence boundary stays outside core TRACE as the spec goes to v1.0. It does, deliberately, and that is now stated normatively rather than just in this thread:
spec/trace-v0.2.md§3.1.2 says areferencesentry is a pointer and not evidence, and requires a verifier not to treat a resolved reference as attested evidence.docs/verification-outcome-statements.mdpairs each verifier outcome with the claim that must stay out of the same sentence.What you did with the answer is worth recording, because it is not the usual pattern. You added a canonical Apache-2.0 licence with a NOTICE separating the open demonstration from your proprietary methodology, and you built the three negative boundary cases from the suggestion rather than asserting the boundary in prose: verified payment instruction is not settlement, verified notification is not proof a person was informed, verified tool execution is not institutional adoption or legal effect. Negative vectors are the part most interoperability reports leave out, and they are the only part that demonstrates a boundary rather than claiming one.
Continuing in two places:
referencessemantics. Answered there:docs/crosswalks/is the right home, no sponsor required, with the Acta crosswalk as the shape to follow.Reopen this if the boundary question itself comes back. Thank you for building something before asking about it.