An open trust format.
Hachures are the short strokes on hand-drawn maps that show the shape and steepness of terrain. This format does the same for trust: it shows the contours of what is supported, what is stale, what is disputed, and what is simply asserted.
Namespace hachure.org/v1
· pre-1.0, hard versioning
· Spec on GitHub opens external site
· npm i -D hachure opens external site
§ 1 The Three Verbs
Every implementation of Hachure is an implementation of three verbs over one ledger. The discipline holding all three together: nothing inside the trust layer silently decides. Models may propose, and proposals are records.
Say what you believe, on the record.
Claims registered with subject, value, and impact.
A Claim has a stable id, a subjectType / subjectId pair,
a claimType, a fieldOrBehavior, and a value.
Derived trust status is never stored on the claim; it is computed from the surrounding bundle at evaluation time.
Attach what actually happened, append-only.
Evidence, verification events, attestations, testimony that never mutates.
Events accumulate as a ledger; the most recent event of a given kind shapes derived status.
A non-passing blocking evidence item surfaces a disputed outcome.
Ask anything; every answer comes with receipts or admits it has none.
Inquiries match a claim directly, derive through a named rule, or honestly report the gap.
An InquiryRecord carries the original question, the resolution path, the answer with status,
and the statusFunctionVersion used — enabling re-evaluation if the algorithm changes.
§ 2 Recompute It Yourself
Status in Hachure is a pure, versioned, deterministic function of the bundle data and a
now timestamp. The same inputs and the same version must produce the same status
in any conforming implementation. Asking you to trust a dashboard is not the same thing as
publishing the function.
statusFunctionVersion = "1"
status = f(claim, evidence, events, policy, authority, now)
now is an explicit argument so point-in-time views are reproducible without
clock-tick events or background expiry. This is the same move transparency logs made for
certificates and Sigstore made for builds, applied to claims about work.
Eight possible statuses
unknown |
No supporting evidence or events; the claim cannot be evaluated. |
proposed |
Evidence exists or a verification event indicates proposed, but policy requirements are not fully met. |
assumed |
Treated as true for operational purposes without full verification evidence. |
verified |
Required policy evidence present; verification event asserts verified and is still fresh. |
stale |
The most recent verified event has expired under the policy's validity rule. |
disputed |
Blocking contradicting evidence exists, or a terminal dispute event has been recorded. |
superseded |
A terminal event marks the claim as superseded. |
rejected |
A terminal event marks the claim as rejected. |
§ 3 Core Record Shapes
Hachure defines these record types. Each is a first-class concept in the format; none requires a specific producer or product to instantiate. Normative JSON schemas are the wire contracts.
TrustBundle
The central wire record. A portable, point-in-time package of trust state from a single producer:
claims, evidence, policies, verification events, and optional identity links, claim groups, and authority traces.
Bundles from multiple producers can be merged; conflicts surface as disputed status — never last-write-wins.
Claim
An assertion about a real-world subject. Stable id, subjectType / subjectId,
claimType, fieldOrBehavior, value.
Carries optional impactLevel, integrity anchors, policy references, and derivation edges.
Evidence
An item of support for a claim, linked via claimId.
Carries evidenceType, method, sourceRef, excerpt, and observedAt.
supportStrength: "entails" feeds policy checks; "cited" is contextual only.
VerificationEvent
An append-only event representing a status decision for a claim. Events are never updated; they accumulate as a ledger. The most recent event of a given kind shapes derived status via the status-function fold.
AuthorityTrace
A record establishing that a named actor held a named authority over a subject during a time window. The credential that makes a dispute-resolution event binding: the fold checks that the resolution event's actor has an active trace at the decision timestamp.
InquiryRecord
An append-only record capturing the resolution of a consumer-side question against the ledger.
Carries the original question, resolution path, answer with status, frozen snapshot of input claim statuses,
and statusFunctionVersion. Records never go stale — they assert what was knowable at a specific moment.
DerivationRule
A named, versioned rule that derives a boolean answer from existing claims.
Composes claims using value predicates (eq, gt, in, exists)
and status predicates, combined with "all" or "any".
Weakest-link confidence ceiling propagates through rule evaluation unchanged.
VerificationPolicy
Declares what evidence and methods are required to reach verified status for a given
claimType, and how long verification remains valid.
validityRule: one of duration, commit, historical, manual.
§ 4 Interoperability
Hachure consumes and emits from existing standards as evidence. It invents no envelope, log, or identity scheme. The existing signing and attestation stacks do their job; Hachure adds the semantics above the signature — claims that evolve over time, a status function anyone can recompute, and authority-gated contestation that can change an outcome without mutating history.
Ships hachure.org/v1 as an in-toto predicateType,
inheriting DSSE signing and the cosign toolchain.
Consumes SLSA provenance as evidence on claims about software deliverables.
References OTel trace IDs from evidence records so "show the work" drills into what the agent executed. Emits trust-status changes as OTel events so status appears in existing dashboards. Does not build a tracing SDK.
First-class SARIF consumer: each run becomes a batch of evidence events (tool identity → authority trace; fingerprint → claim correlation). Optionally emits SARIF so trust status surfaces inside GitHub code scanning UIs.
Consumes C2PA manifests as a high-grade evidence class on Hachure claims. Adds the lifecycle after the signature: post-hoc verification, status that evolves, contestation. C2PA is frozen at signing time; Hachure status is recomputed from accumulating testimony.
Emits verification events as VCs signed by the verifying authority.
Publishes a JSON-LD context so hachure.org/v1 documents carry PROV-O terms
for semantic-web interop.
Anchors testimony log entries in Rekor or a Tessera-based log for third-party append-only witnessing. Inherits keyless certs from Fulcio via the cosign toolchain.
Positions the testimony log as an Article 12/19-grade logging substrate: append-only integrity is a strictly better story than mutable logs when facing market-surveillance authorities.
Maps gen_ai.agent.* and MCP attributes into authority traces.
Turns selected telemetry into durable, signed, disputable testimony.
Observability is not inspectability — OTel describes what happened; Hachure records what was verified.