Informative mapping venue — downstream institutional reconstruction consumer

[riscas028]

Filed after the technical feedback on agentrust-io/trace-tests#96. This is not a defect report, does not propose a normative TRACE change, and makes no TRACE conformance claim.

N’KEMBA is a downstream institutional-reconstruction consumer. It can ingest runtime/session evidence, action receipts and assurance-neutral external references, then evaluate whether a bounded institutional conclusion is actually supported across authority, operative document/version, external outcome and institutional adoption.

We now have reproducible mutation vectors where the expected verdict exists only in the test harness and the evaluator derives the conclusion from mutable evidentiary inputs.

Before preparing any annex or PR, I would like to confirm the correct venue:

1. Is a downstream consumer / institutional-reconstruction mapping in scope for the vendor-annex track? CONTRIBUTING.md currently describes that track for silicon/cloud attestation vendors.
2. If not, what informative track would you prefer for reproducible consumer-side mapping vectors?
3. Is this interoperability boundary consistent with TRACE v0.2 semantics: references may bind pointers to authority/approval/external facts, while the downstream consumer independently evaluates those targets and does not treat them as attested evidence merely because a valid Trust Record references them?

The intended boundary is deliberately conservative: a valid runtime record does not by itself prove institutional authority; a valid action receipt does not prove external completion; a document digest does not prove that version was institutionally operative; and a resolved reference is not promoted into attested evidence.

If this belongs outside vendor-annex, a pointer to the preferred contribution path is sufficient and we will adapt the vectors to that venue rather than forcing the fit.

[imran-siddique]

All three, and the first two are settled by CONTRIBUTING.md rather than by my judgement.

1. Not vendor-annex, and that is not a demotion

That track is narrow on purpose: vendor-co-authored claim-mapping annexes for §4.4, authored by the party that produces the attestation being mapped. CONTRIBUTING.md says "if you represent a silicon or cloud attestation vendor and want to author the annex for your platform". N'KEMBA consumes TRACE evidence rather than producing platform claims, so the annex track would be the wrong shape even if it were open, and the label carries a co-authorship expectation you would not want.

2. The venue is docs/crosswalks/, and it needs no sponsor

From the same file, verbatim:

No sponsor is required for editorial changes, examples, conformance tests, tooling, schema changes tracking an already-merged spec change, and informative additions such as crosswalks and mappings to external schemas. Informative text carries no RFC 2119 keywords and binds no implementation, so it is the right home for a mapping that is still settling.

docs/crosswalks/ already holds owasp-agentic-top-10.md and acta-decision-receipts.md, both in the mkdocs nav. The Acta one is your precedent almost exactly: it came out of #97, an outside party proposing to map an independently specified receipt format into TRACE evidence, and it landed as informative with the boundary stated in its own first line. Read its opening section before you draft; it shows the shape that gets merged. Add a nav entry in mkdocs.yml in the same PR, because a docs page without one is invisible.

Two things that crosswalk does and I would ask of yours. It states in the first paragraph that it is non-normative and changes no schema field, wire format, required claim or conformance requirement. And it says which TRACE obligations the external format satisfies and which it does not, rather than only where the two agree. The second is what makes a crosswalk useful to an implementer instead of a compatibility advertisement.

3. Your reading of references is correct, and it is normative rather than inferred

Confirmed at 5c69dc1679f866bdc6e997b782a91bb992458db1, spec/trace-v0.2.md §3.1.2:

A references entry is a pointer, not evidence. What the signature attests is that this record points there, not the truth of what it points at. The pointer is produced inside the boundary that produced the record; the target is not.

And rule 3 of that section:

A verifier MUST NOT reject a record because an entry in references cannot be resolved, and MUST NOT treat a resolved reference as attested evidence.

So a downstream consumer independently evaluating the target, and refusing to treat it as attested merely because a valid Trust Record points at it, is exactly the behaviour the section requires. The same subsection also says a reference cannot carry compliance evidence at all: a record pointing at a policy, configuration or approval attests that it points there and nothing about what the target says or whether it was in force. That is the strongest form of the boundary you have been describing, and it is already in the normative text.

One thing to build against rather than around: the registered rel set is currently three values, authorized-intent, approval-outcome and behavior-trace. If your reconstruction needs a relation that is not one of those, #226 is the open tracker for exactly that question and the right place to say which one and why. Four separate governance requests turned out to be one missing rel value, so yours would not be the first.

On the demonstrator

I have posted a finding on trace-tests#96 against v0.7. It is the answer to the question you asked there, and it is a real one, so please read that before you draft the crosswalk. The mapping is welcome either way; the crosswalk should not cite the demonstrator's verdicts as evidence of anything until it is fixed.

[riscas028]

Thank you — this resolves the venue question clearly.

We reproduced the v0.7 default-pass finding from trace-tests#96 and fixed the root cause in v0.8 by making the evaluator fail closed: all six required dimensions must be present and explicitly recognised, and absent or unknown values cannot fall through to PROVED. We will not cite the demonstrator's verdicts as TRACE conformance or as evidence of anything beyond its bounded synthetic logic.

For the mapping, we will follow the docs/crosswalks/ route and the Acta crosswalk shape you pointed to. The opening section will state that the document is non-normative and changes no TRACE schema field, wire format, required claim, or conformance requirement. The mapping will also distinguish explicitly between TRACE obligations the downstream format can satisfy and those it cannot, rather than presenting only points of agreement.

We will also keep the references boundary exactly as §3.1.2 defines it: a pointer is not attested evidence about its target. If the reconstruction genuinely needs a relation outside the current registered rel set, we will take that specific question to #226 rather than overloading an existing value.

No sponsor request from our side. This gives us a concrete contribution path.