Vendor platform annex: software-only deterministic multi-agent orchestrator (Bernstein)

[chernistry]

Filed per the issue chooser's "Vendor platform annex interest" link — this proposes an informative annex, not a normative change to existing text.

Spec section affected

Platform profiles / vendor annexes (new informative annex; no existing normative text changes).

Problem

The quickstart shows a software-only platform profile, but there is no annex yet that maps Trust Record production for a software-only multi-agent orchestrator — a producer whose evidence root is signed journals and deterministic re-execution rather than a TEE. Two composition questions come up immediately when mapping one:

1. Delegation composition. When agent A spawns agent B under a narrowed policy, what is the intended record shape — one Trust Record per agent with cross-references, or nesting? Delegation chains are the daily case for orchestrators.
2. Replay as evidence. Is there room in the claims model for deterministic re-execution — an assertion of the form "re-running this workload reproduces measurement X"? For software-only producers this is a strong complement to signatures: a verifier can re-run rather than only check that a log was signed.

Proposed change

An informative platform mapping annex for a software-only deterministic orchestrator, which we would draft and contribute:

• mapping of orchestrator run journals (hash-chained, HMAC-signed; Ed25519 producer identity; content-addressed artifact lineage) onto Trust Record / EAT claims;
• the delegation-composition pattern for multi-agent runs, whichever shape the editors prefer;
• test vectors generated from real runs, suitable for the conformance suite.

Backward compatibility

• Non-breaking (new optional field, informative addition)
• Breaking (removes or changes required field, changes wire format, changes algorithm set)

Motivation

I maintain Bernstein, an Apache-2.0 multi-agent orchestrator. Every agent action already lands in a hash-chained, HMAC-signed journal: which model served the step, the policies in force, tool invocations, and content-addressed hashes of every artifact produced. Installs carry a signed Ed25519 identity, and lineage receipts bind each artifact to the step that produced it. The scheduler is deterministic — no LLM in the coordination loop — so a run can be re-executed byte-identically from its journal.

We intend to emit TRACE Trust Records natively per orchestrated run, validate against the conformance suite at tests.agentrust-io.com, and keep the annex maintained as the spec evolves. If a list of implementations is planned, we would like Bernstein on it once we pass.

Related issues or PRs

None yet; we will file focused spec-change issues from the mapping work as concrete normative questions surface.

---

AI was used to revise grammar and translation, but initially I wrote it myself.

Thanks - Alex.

[lywinged]

I contribute here and wrote the delegation-link vectors. Nothing below is a maintainer decision, so treat it as information rather than a ruling. On your first question there is an answer already in the repository. On the second there is a problem worth knowing about before you draft anything, and it is larger than the missing claim.

1. Delegation composition: cross-references, and the schema enforces it

schema/trace-claim.json already carries the delegation block, and it settles the shape. Checked by validating records rather than by reading the description:

delegation value	validate_json
{parent_record_hash, credential_id}	accepted
the same plus an embedded parent record	refused, Additional properties are not allowed ('parent' was unexpected)
{parent: <record>} alone	refused, 'parent_record_hash' is a required property
a list of hops	refused, not an object
parent_record_hash: "md5:..."	refused, pattern is ^sha(256:[0-9a-f]{64}|384:[0-9a-f]{96})$

So it is one Trust Record per agent, linked upward by the SHA-256/384 digest of the parent hop's record. Nesting does not fit: additionalProperties is false and there is no member to nest into. The block's description says a chain of these "forms an offline-verifiable delegation DAG". It is optional and absent on a root execution, which is how a walk knows where to stop. examples/delegation-link/02-valid-full-depth-out-of-order.json is a five hop chain and it is stored as five separate records, four carrying a delegation block and the root carrying none, which is the shape rather than a description of it.

Precise about what is settled: the block is normative in v0.2, so its shape is enforced whenever it is present. The binding rules are not. §4.1 says the block "landed in v0.2 as the foundation; the normative A2A binding rules are targeted for v0.3". Build against the shape now and expect the rules to be written around you.

docs/rfcs/a2a-delegation-profile.md drafts those rules and states on its first line that it binds nothing. It ships examples/delegation-link/: 23 vectors, a generator, a published key. Coverage is 3 valid chains plus ten failure classes at two vectors each:

credential_holder_mismatch  2      digest_algorithm_unsupported  2
credential_issuer_mismatch  2      parent_not_found              2
credential_unknown          2      record_signature_invalid      2
credential_window           2      root_key_untrusted            2
data_class_widened          2      depth_exceeded                2

Two matter most for an orchestrator. depth_exceeded: the walk follows no more than max_depth links. data_class_widened: a hop's data_class is no more sensitive than its parent's, per a caller-supplied lattice. Each vector carries its own records, its context including trusted_root_keys, and its expected, so you can run them against your producer without this repository's code; examples/delegation-link/README.md has a "Running them" section.

2. The thing to settle before the annex: what a software-only record is worth

This is not what you asked, but it decides the value of what you are proposing, so it is worth putting first.

schema/trace-claim.json, on runtime.platform:

software-only marks development-mode records with no hardware backing; they must never be treated as attested evidence.

Read literally, every record Bernstein emits carries that mark, and a conformant consumer is told never to treat any of them as attested evidence, however strong the journal behind them.

The prose is not so absolute, and it is two documents against one. §3.1.1 of the specification says software-only is the honest value in two situations, a dev-mode record and a record transcribed from another vendor's control plane, and that a consumer needs to tell them apart. docs/schema.md says the same. Only the field description in schema/trace-claim.json says the value marks development-mode records and caps what they may ever be worth, and that is the one a validator reads.

Neither framing describes a producer like yours: a runtime that produced its own record, with no TEE, and a signed hash-chained journal behind it.

There is no rung above software-only that is not hardware. The platform enum is nine hardware roots and then software-only, with nothing in between and nothing in ROADMAP.md about adding one.

I think that, and not the missing replay claim, is the question your annex actually runs into. A mapping is straightforward; what it maps onto is capped.

3. Replay as evidence: nothing today, and a word to avoid

There is no claim for deterministic re-execution. Searching spec/, schema/ and ROADMAP.md for re-execution semantics returns nothing, and nothing is planned.

The word replay is taken and currently means close to the opposite. docs/platforms/amd-sev-snp.md lists "Replay protection | Nonce-based freshness", that is, preventing a record from being re-presented. Proposing "replay as evidence" under that word costs a round of clarification with everyone who reads it. "Deterministic re-execution" says what you mean and collides with nothing.

One sentence you will be asked about. The threat model in §2 says, of what TRACE does not control: "AI agents are non-deterministic. They may invoke tools, route data, and act in ways no software policy anticipated." Your claim is narrower and compatible with that, since it is the scheduler that is deterministic and no model sits in the coordination loop, but it is narrower than the sentence a reviewer will reach for. Saying up front which part of a run you claim reproduces byte for byte, and which part does not, will save a round.

Where the question probably lives. §3.1.2's references block binds a fact held outside the record by rel, id and resolver, with optional retention and digest, under rules 3 and 4:

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.

Which relationships get a registered rel is being decided in #226, and its point 4 is whether that registry is normative at all, which determines who may write it.

Whether re-execution fits there is a real question rather than a formality, and I do not think it is settled. references is for a fact someone else holds, and rule 3 caps what a resolved one can ever be worth. Deterministic re-execution is a property a verifier establishes for itself by re-running, which is a different kind of thing and possibly a stronger one than that block is allowed to carry. You are better placed to argue it than I am.

4. One correction to something you might otherwise reach for

origin (§3.1.1) looks like the field for disclosing what is behind a software-only record, and it is not. origin.kind is self, third-party-control-plane or log-import, and the spec is explicit on two points:

• self: the runtime produced its own record. Equivalent to omitting the block; stating it is allowed so a producer can be explicit rather than leave it inferred.

This block does not launder assurance in either direction. It cannot raise a record: nothing about naming your producer makes unattested evidence attested.

Bernstein is a runtime producing its own records, so it is self, so setting it says exactly what saying nothing already says. origin distinguishes who assembled a record, not how strong the evidence behind it is. I raise it because it is the closest-looking field and reaching for it would cost you time for nothing.

5. A gap in the process you were pointed at, which is not yours

You filed per the issue chooser, whose wording is open to anyone:

.github/ISSUE_TEMPLATE/config.yml: "Interested in co-authoring a platform mapping annex? Open an issue with the vendor-annex label."

§4.4 is narrower:

vendor-co-authored claim-mapping annexes, one per silicon-root and cloud-attestation surface

followed by a five-row table: NVIDIA, Azure, Google, Intel, AMD. A software-only orchestrator is neither a silicon root nor a cloud attestation service, so the section has no slot for the class of producer the chooser invited.

GOVERNANCE.md is broader, saying annexes are informative and reviewed by the vendor author and one Maintainer without the full spec-change process, but it points at §4.4 for scope. So "may this exist" reads differently depending on which document a reader opens, and that is worth a maintainer settling once rather than you discovering halfway through drafting.

[chernistry]

@lywinged — this is exactly the review I hoped the issue would get. Answers in your order, shortest first.

1. Delegation: settled, we build against it

One record per hop, linked by parent_record_hash, root carries no delegation block — understood, and the vector table you pasted is more useful than the prose would have been. We will run all 23 delegation-link vectors against our producer before claiming anything, and depth_exceeded / data_class_widened are the two our orchestrator exercises daily (spawn depth is bounded; a child task's data class is narrowed from its parent's), so those go first. Building against the v0.2 shape and expecting v0.3 to write the binding rules around it is fine for us.

4 (out of order because it's short). origin

Understood — we are self, self ≡ omitted, and the block cannot raise a record anyway. You saved us a wrong turn.

2. software-only: agreed this is the real question

Two separate things here, and I'd rather not tangle them:

The textual divergence — schema description ("development-mode records") vs §3.1.1 (two situations, one of them mandated by a MUST) — I've filed as #232, same shape as #172 was. Whichever text wins, that's a consistency defect worth settling independently of anything Bernstein wants.

The ceiling itself — to be explicit about what we are and are not asking: we do not propose that a software-only record be treated as attested evidence, and the annex would say so in its first paragraph. The annex's value, as I see it after your comment, is to state precisely what a record from this class of producer does warrant — a signed, hash-chained journal that a verifier can walk offline — and what it does not: no hardware root, no attestation. If the ceiling stands as worded, the annex documents the honest floor under it. Whether a rung between software-only and the nine hardware roots should ever exist is a spec question we are not raising now; I'd rather earn that conversation with a working producer and passing vectors than open it with a proposal.

3. Terminology accepted, scope stated

"Deterministic re-execution" from here on; "replay" dropped — the collision with nonce-freshness replay protection is real and I'd rather not spend a round on it.

The precise claim, since you're right that §2's sentence is what a reviewer will reach for: the scheduler and coordination layer re-execute byte-identically from the journal — task graph, policy evaluations, artifact routing. Model outputs are recorded, not reproduced: re-execution replays the recorded outputs through the deterministic scheduler and verifies the artifact hashes match. So the claim is "this journal, replayed, reproduces these artifacts", not "this agent, re-run, behaves the same" — the narrower claim, compatible with §2, and we'll state it in exactly that split wherever it appears.

On where it lives: agreed that references rule 3 caps a resolved reference below what re-execution establishes, and agreed the two are different kinds of things — a reference is a fact someone else holds; re-execution is a property the verifier establishes for itself. We'll watch #226 settle the registry question first and won't propose anything in the annex draft that presumes an answer.

5. The scope question — for the maintainers

The one thing I'd ask a maintainer to settle before we draft: does §4.4's scope ("one per silicon-root and cloud-attestation surface") admit an annex for a software-only producer at all, given the issue chooser's wording invites any vendor? A one-line ruling either way saves a dead draft — if the answer is no, we still emit records, run the vectors, and file focused issues as they surface; the annex just isn't the vehicle.

---

AI was used to revise grammar and translation, but initially I wrote it myself.

Thanks - Alex.

[chernistry]

Following up with the five items requested for this issue: the proposed claim mapping, the replay semantics, and the evidence-tier clarification are below; the two executable vectors follow as checked-in fixtures once the emitter slice lands in our tree, and will be linked from this issue so the trail stays reproducible.

1. Proposed mapping: Bernstein run receipt → TRACE v0.2 claims

One Trust Record per independently identifiable agent execution, per the composition discussed above. The run itself gets an aggregate record; each agent execution gets its own. Mapping below is per-execution unless noted; it is a proposal to be pinned by the emitter and the vectors, not a claim of conformance.

TRACE v0.2 claim	Bernstein source
eat_profile	constant for the profile version
iat	execution completion time, from the run journal
subject	run id + execution id (the journal keys every step by both)
model	the model identity the journal recorded for that execution's steps
runtime	orchestrator version + Python runtime, from the run header
policy.bundle_hash	hash of the resolved gate/policy configuration the run executed under
policy.enforcement_mode	enforced — gates block publication, they do not advise
data_class	operator-declared at run start; defaults conservative
tool_transcript	digest over the journal's tool-call entries for that execution
delegation	child executions only: parent_record_hash = the delegating execution's record hash, credential_id = the credential the child actually ran under
origin	omitted for self-produced records (≡ kind: self per the settled reading above); populated only for ingested external events
references	artifact digests: diff hash, produced-file digests, bundle digest where one exists
build_provenance	package version and install provenance
appraisal	software-only verification level, stated explicitly — none of this is hardware-attested
cnf	the install's Ed25519 public key
signature	EdDSA over the record, same key

Two places where implementation experience will push on the spec, flagged now rather than discovered later: (a) subject for a run-level aggregate record wants a defined convention distinct from per-execution subjects; (b) an aggregate record's way of listing its member execution record hashes currently has no dedicated claim — we would put them in references, but that overloads it.

2–3. The two test vectors (shape now, fixtures next)

Both will be emitted from checked-in fixture journals by the emitter, not hand-written, so they stay regenerable.

Single-agent: one execution, no delegation claim, origin omitted, policy hash of the fixture's gate config, verified with trace-tests verify --level 1.

Multi-agent, narrowed policy: agent A plans, delegates one task to agent B under a credential scoped to a subset of A's permissions. Three records: A (no delegation), B (delegation.parent_record_hash = hash of A's record, delegation.credential_id = the narrowed credential; policy.bundle_hash differs from A's, and the policy bundles themselves are in the fixture so the narrowing is inspectable rather than asserted), and a run-level aggregate whose references carry both record hashes. That gives both directions: child→parent cryptographically via delegation, run→children via the aggregate.

4. What replay guarantees, what may diverge, how divergence is detected

Adopting the "deterministic orchestration with replay verification" framing — it is the accurate name for the property.

Byte-identical on replay: the task graph (plan structure and task ordering), the scheduling decisions (no model in the coordination loop — scheduling is a pure function of plan + recorded events), the journal's step sequence and entry structure, and the gate configuration.

May diverge: model/agent outputs, and everything downstream of them (produced artifacts, token counts, timing). We do not claim output determinism and the record must not imply it.

Detection: the journal is an append-only sequence of step entries, each carrying a content hash, each entry binding to its predecessor. Replay re-executes the graph and compares entry-by-entry against the recorded chain; the first mismatching entry names the step, the input hashes, and which side diverged. So the guarantee is precisely: the recorded run is internally consistent and structurally reproducible, and any behavioural divergence in a re-execution is localised to a named step — not "the same bytes come out".

Happy to turn this section plus the multi-agent vector into a short WS4 write-up.

5. Evidence tiers: always-on vs opt-in, and how the pieces relate

Always produced, every run: the append-only run journal; the journal-completeness seal (a digest over the full entry sequence — a truncated or reordered journal fails verification, so "the journal is all of what happened" is checkable, not asserted); and the Ed25519-signed run receipt.

Opt-in: the HMAC audit chain. Operator-keyed, links runs into a cross-run append-only sequence, verifiable offline by whoever holds the key. It is operator evidence about the series of runs, not part of any single Trust Record; when enabled, a record can carry its chain entry digest in references.

How the receipt and the seal relate: the seal is a property of one journal (integrity + completeness); the receipt is the signed statement over the seal and the artifact digests, under the install identity in cnf. Verifying the receipt therefore transitively verifies the journal it seals. In TRACE terms: the receipt's signature and key become signature/cnf; the seal is what makes tool_transcript and references trustworthy inputs rather than self-reported ones.

All of it is software-only evidence and the appraisal claim will say so explicitly — nothing here should be read as attested.

[lywinged]

Coming back only because of the mapping table. Nothing below reopens anything that was settled, and the §4.4 ruling is still the maintainers' to give.

You wrote that the mapping is "a proposal to be pinned by the emitter and the vectors", so it is worth running before it is pinned. I built the smallest record the table describes and put it through validate_json at e7e2eca. Three rows make a record the schema rejects today, and five more things came out of the same pass. Two came from elsewhere: section 2 of your follow up, which is directly below because it is the one I would act on first, and the pull request now open against #232. At the end I built your three record shape with the corrections applied: it validates, round trips through the model, and signs and verifies.

Three rows produce a record the schema rejects today

policy/enforcement_mode  'enforced' is not one of ['enforce', 'advisory', 'silent', 'declared']
references/0             'rel' is a required property
references/0             'id' is a required property
references/0             'resolver' is a required property
subject                  'run-7f3a/exec-2' does not match '^(spiffe://|did:)'

• enforcement_mode is enforce, not enforced. Your intent is right and it is the default.
• references entries carry the rel, id, resolver shape we went through earlier in this thread, so the row as written, a list of digests, is the one place that shape did not make it into the mapping. digest is the optional member, not the entry.
• subject is constrained to ^(spiffe://|did:), so "run id + execution id" has to be carried inside a SPIFFE ID or a DID rather than as a bare pair. That also gives your open question (a) somewhere to live: spiffe://bernstein/run/<run>/exec/<exec> and spiffe://bernstein/run/<run> are two conventions in the same namespace, which is the distinction you were reaching for between per execution and run level records.

Level 1 is not reachable for these records

Section 2 of your follow up says the single agent vector is "verified with trace-tests verify --level 1". This is the operational edge of the ceiling we went through earlier, not a new argument about it: Level 1 will not accept a record from this producer, by definition rather than by any gap. docs/trust-levels.md:

Level 1 requires that the signing key be generated inside a verified TEE (AMD SEV-SNP, Intel TDX, NVIDIA H100, or TPM2). The runtime.platform field must be one of these values, and runtime.measurement must be a non-zero hardware measurement.

Level 0 is the ceiling for a software-only producer, and the CLI defaults to it: trace-tests verify --record <path> --level 0. Nothing about that weakens the annex's argument, since the annex's point is what a Level 0 record does and does not warrant.

Worth flagging while pointing at that page: do not take its Level 1 additional-fields row as the list of platform values. It says runtime.platform must be "tpm2, sev-snp, tdx, or opaque", and three of those four are not in the schema's enum, which is intel-tdx, amd-sev-snp, azure-cvm-sev-snp, nvidia-h100, nvidia-blackwell, aws-nitro, arm-cca, google-confidential-space, tpm2, software-only. Run against validate_json, tdx, sev-snp and opaque are all refused and only tpm2 passes. It does not touch you at Level 0, and it is the same shape as #232 again.

appraisal.verifier is declared format: uri

bernstein fails it; https://bernstein.example/verifier passes. This one is inert on main today. validate_json does pass a FormatChecker, but jsonschema only registers the uri format when a package implementing it is installed, and nothing in the dependency list does, so a bare name validates at the moment. It is declared, though, and any validator that does install a checker refuses it. There is also an open pull request, #236, which adds such a package to the dependency list, so this may not stay inert; that one is mine, so treat it as disclosure rather than as a reason. A URI costs nothing and is what the field asks for either way.

The appraisal row is not expressible, and that is a known open question rather than a gap in your mapping

You wrote appraisal as "software-only verification level, stated explicitly". appraisal is additionalProperties: false with exactly policy_ref, provenance_depth_verified, status, timestamp, verifier, and status is closed at affirming, warning, contraindicated, none. There is no member that carries "this was checked to a software-only level", and none of the four status values says it.

That is the same wall #190 exists to hold. The instruction there was given to a different lane, the revocation bundle consumer, and it was specific: "a function may return three states without anyone deciding which appraisal.status value two of them carry", and "if the implementation ends up naming an outcome, it has gone too far and has pre-empted the decision this issue exists to hold". Your case is not that lane, but it runs into the same closed enum, so the same caution seems worth carrying over. status is required, so something has to go there. Of the four, none is the only value that does not assert an appraisal happened, and that is written down rather than my inference: docs/trust-levels.md says under the Level 0 example that "The appraisal.status of "none" is correct when no hardware verifier is in the path". Leaving provenance_depth_verified absent rather than repurposed is my reading.

Two required members have no source in the table, and one of them is written down twice with different scope

The right column is where the content comes from, so this is not a complaint that the rows are short. It is that two required members have nothing feeding them.

• build_provenance requires slsa_level and digest, and the object is closed. "Package version and install provenance" is a source for digest and for provenance_uri, which is where a link to the install provenance goes. slsa_level is an integer 0 to 3 and nothing in that row produces one.
• runtime requires platform and measurement, and the object is closed, so "orchestrator version + Python runtime, from the run header" has nowhere to sit except firmware_version, which is optional and means something else. platform is software-only, which you already have.

measurement is required on every record, its pattern is a sha256: or sha384: digest, and its description is "Hardware measurement of the workload (e.g. TDX MRTD, SEV measurement, TPM PCR composite)", which a software-only producer does not have. The answer is an all zero digest, and docs/trust-levels.md gives it to you twice with different scope. The Level 0 minimum fields block writes "measurement": "sha256:0000...0000" for a record whose platform is software-only, with no qualifier. The sentence directly under that block says all zero "is conventional for software-only development records". Your records are software-only without being development records, so one of those two sentences covers you and the other does not. It is the same narrowing your #232 reports on the platform description, one field over. I would use the all zero digest and treat the development qualifier as the loose half. If you want it settled rather than assumed, this is the same kind of one paragraph issue #232 was, and you are in the same position to file it: the case that exposes the gap is yours.

#232 has a pull request, and the wording still does not name your case

You may not have seen it: #234 is open, from another contributor, and implements your proposal almost verbatim, ending "Such records must never be treated as attested evidence" where yours ended "are not attested evidence".

Worth reading it as the person who filed #232, because the wording enumerates two situations and yours is a third. Your text, and the PR's:

software-only marks records with no hardware root of trust: a development-mode execution, or a record assembled from evidence produced outside the runtime

Bernstein is neither. It is a runtime producing its own records, origin.kind of self, with no hardware root. The lead clause covers you and the two examples do not, and the whole argument of #232 is that a reader takes this description as complete and has no reason to look further. That is the same reading that put the old wording wrong, surviving into the replacement.

I have not raised it there. It is your issue and your sentence, and you are better placed to say whether the lead clause is enough or whether the third case wants naming.

Your open question (b), which has a better answer than "it overloads it"

You wrote that an aggregate record's way of listing its member execution record hashes has no dedicated claim, and that references would overload it. Half of that is right and the useful half is not.

The record object is additionalProperties: false, so references really is the only place. But rel is the field that names what a reference is, and it is deliberately open. The schema's own description says "The registered values are a registry that grows, so this is not a closed set", and tests/test_references_block.py asserts rel carries no enum for exactly that reason. So an aggregate record carrying {"rel": "...", "id": "<member record>", "resolver": "..."} per member is not overloading anything; it is using the field that exists to say what the relation is.

What is genuinely open is which value, and that is the question I flagged as #226 earlier in this thread rather than a new one. §3.1.2 registers three, authorized-intent, approval-outcome and behavior-trace, and none of them is "a member execution of this run". Your artifact digests row has the same gap: none of the three is "an artifact this run produced" either. So the aggregate record is blocked on #226's point 4, whether the registry is normative and who may write to it, and not on references being the wrong home. That is a smaller and more tractable question than the one you posed.

One thing that will bite the emitter, and it is not your fault

subject is stricter in the reference model than in the normative schema:

subject = "spiffe://bernstein"                    schema accepts, model REFUSES
subject = "spiffe://bernstein/run-7f3a/exec-2"    schema accepts, model accepts

The schema's pattern is ^(spiffe://|did:), a prefix test. models.py uses ^(spiffe://[^/]+/.+|did:[a-z0-9]+:.+)$, which requires a path after the authority. So a producer written against the normative schema can emit a record that TrustRecord.model_validate refuses, and that call is what sign_record's own docstring points a caller at to confirm structural validity before writing.

It is the only constraint of its kind that differs, in case one example reads like a sample. I compared every constrained field in models.py against its counterpart in the schema, subject, iat, measurement, platform, enforcement_mode, the four digest patterns, credential_id, producer, ingested_at, slsa_level, both depth enums, status, timestamp, call_count, eat_profile, and the three references members. Every one of them agrees. subject is the only shared constraint where the two texts differ, so building to the stricter of the two is the whole of the mitigation.

One piece of hygiene while you are writing the emitter, unrelated to that divergence: cnf.jwk is a public proof-of-possession key, and models.py refuses d, p, q, dp, dq, qi and k on exactly that ground. Whatever serializes your install identity should emit the public half only, and it is worth a test rather than a review habit, because a JWK serializer that takes a key pair and writes every member it has is the ordinary way this goes wrong.

The corrected shape, run rather than described

Your multi agent example, built with the corrections above: A with no delegation, B carrying delegation.parent_record_hash (which is patterned as a sha256: or sha384: digest) and credential_id, and a run level aggregate whose references name both members.

A (root)        schema OK, model OK, sign+verify OK
B (delegated)   schema OK, model OK, sign+verify OK
aggregate       schema OK, model OK, sign+verify OK

Subjects spiffe://bernstein/run/7f3a/exec/1, .../exec/2 and spiffe://bernstein/run/7f3a. So the shape you proposed works as proposed; what is above is the field level detail between here and there.

Everything above is reproducible against e7e2eca with agentrust_trace.validate.validate_json and TrustRecord.model_validate. Happy to paste the exact record if it is useful.

[chernistry]

@lywinged — running the table before it was pinned is exactly what "proposal, not conformance" was for, and the corrected three-record run at the end saves us the round trip that usually gets discovered in CI. Yes please to the exact records: we will diff the emitter's output against them byte-for-byte before posting the vectors, which is a stronger check than validating each side separately.

Point by point, decisions rather than intentions:

The three rejects — adopted as you state them.

• enforce, not enforced.
• references entries are {rel, id, resolver} objects with digest optional. The bare-digest-list row was a leftover from before the entry shape was settled in this thread; the corrected table below fixes it.
• subject becomes a SPIFFE ID. Pinning the convention now, since you gave question (a) its home: trust domain bernstein.run (a DNS name the project controls, per SPIFFE convention), spiffe://bernstein.run/run/<run>/exec/<exec> per execution, spiffe://bernstein.run/run/<run> for the aggregate. Both carry a path after the authority, so we are building to the stricter models.py pattern you isolated rather than the schema's prefix test — thank you for comparing every constrained field; "the only one that differs" is the sentence that makes that finding usable.

Level 0, and a correction to our own text. You are right and our follow-up was wrong: it said the single-agent vector is "verified with trace-tests verify --level 1". Level 1 requires a TEE-resident signing key, which this producer does not have by definition. The conformance results we post will be --level 0, and the annex gains a sentence saying Level 0 is the ceiling for this producer class — which is the annex's argument anyway, stated operationally.

appraisal. status: "none" per the trust-levels text you quoted, provenance_depth_verified absent rather than repurposed, verifier as a URI (https://bernstein.run/trace/verifier, which will document the verification procedure). We read #190 the same way you do: the enum is a held decision, and a producer that invents a value for "software-only checked" has pre-empted it. The "stated explicitly" cell in the old table dies; the annex prose carries that statement instead, where it belongs.

build_provenance. slsa_level is emitted as what the release lane actually warrants, which today is 0 — the wheels are built in CI but no signed provenance attestation is published, and the level should rise only when the evidence exists, not when the aspiration does. digest is the installed wheel's sha256; provenance_uri points at the release page.

runtime. platform: "software-only", measurement all-zero, orchestrator and Python versions dropped from this row — they live in the journal the tool_transcript digest already covers, and firmware_version means something else. On the two-scopes problem you found in the all-zero convention ("software-only" in the block, "software-only development records" in the sentence under it): filed as #240, since as you say the case that exposes the gap is ours. Same shape as #232, one field over.

#234. Read it as the #232 filer, and you are right that the third case survives into the replacement text — a production runtime emitting its own records, origin.kind: self, no hardware root, is the lead clause's case and neither example. Commented there with proposed wording rather than raising it here.

Aggregate rel — accepted, and it is a better answer. references with an open rel is the home; the vectors will carry rel: "member-execution" for member records and rel: "produced-artifact" for artifact digests, offered as candidate registry values, with the normativity question resting on #226 point 4 exactly as you framed it.

cnf.jwk. Agreed that public-half-only is a test, not a review habit. The emitter suite gets a test that serializes the install identity and asserts the private members models.py refuses are absent from the emitted JWK.

Corrected mapping, superseding the earlier table:

TRACE v0.2 claim	Bernstein source
eat_profile	constant for the profile version
iat	execution completion time, from the run journal
subject	spiffe://bernstein.run/run/<run>/exec/<exec>; aggregate: spiffe://bernstein.run/run/<run>
model	the model identity the journal recorded for that execution's steps
runtime	platform: "software-only", measurement: all-zero sha256 (scope question filed as #240)
policy.bundle_hash	hash of the resolved gate/policy configuration the run executed under
policy.enforcement_mode	enforce — gates block publication, they do not advise
data_class	operator-declared at run start; defaults conservative
tool_transcript	digest over the journal's tool-call entries for that execution
build_provenance	slsa_level: 0, digest: installed wheel sha256, provenance_uri: release page
appraisal	status: "none", verifier: "https://bernstein.run/trace/verifier", timestamp; provenance_depth_verified absent
cnf	public half of the Ed25519 install identity as a JWK; emitter test asserts no private members
delegation	child executions only: parent_record_hash (sha256 of the parent's record), credential_id
references	aggregate: one {rel: "member-execution", id, resolver} entry per member record; artifact digests as {rel: "produced-artifact", id, resolver, digest}

Next from our side, in order: emitter aligned to this surface, the two vectors emitted from fixtures (diffed against your records), trace-tests verify --level 0 on both, all linked from this issue.