The "unit of proof" is documented with two materially different schemas:
README.md:191-200 — a GatewayClaim with namespaced/dotted fields: trace.eat_profile, trace.runtime, trace.policy.bundle_hash, trace.cnf.jwk, gateway.audit_chain, signature.
docs/SPEC.md:132-160 — a flat snake_case JSON object: trace_version, session_id, tee_public_key, attestation_report, policy_bundle, tool_catalog, call_summary, audit_chain_root, audit_chain_tip, signature.
These are not field-compatible, so a verifier implementer cannot tell which is normative.
Separately, LIMITATIONS.md:17 refers to "the tool_transcript.hash field in the TRACE Claim," but that field appears in neither schema.
Proposed fix: pick one normative schema (ideally in SPEC), have the README show the same field names, and reconcile tool_transcript.hash (either add it to the schema or correct the LIMITATIONS reference).
Found during a docs-consistency pass.
The "unit of proof" is documented with two materially different schemas:
README.md:191-200— aGatewayClaimwith namespaced/dotted fields:trace.eat_profile,trace.runtime,trace.policy.bundle_hash,trace.cnf.jwk,gateway.audit_chain,signature.docs/SPEC.md:132-160— a flat snake_case JSON object:trace_version,session_id,tee_public_key,attestation_report,policy_bundle,tool_catalog,call_summary,audit_chain_root,audit_chain_tip,signature.These are not field-compatible, so a verifier implementer cannot tell which is normative.
Separately,
LIMITATIONS.md:17refers to "thetool_transcript.hashfield in the TRACE Claim," but that field appears in neither schema.Proposed fix: pick one normative schema (ideally in SPEC), have the README show the same field names, and reconcile
tool_transcript.hash(either add it to the schema or correct the LIMITATIONS reference).Found during a docs-consistency pass.