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
Walkthrough: trust.html links this
site's own raw bundle and walks you through recomputing its status yourself —
curl … -o bundle.json then npx hachure derive bundle.json.
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.
This is the step every attestation standard leaves out. SCITT leaves registration policy to each transparency service; EAT says verifier rules "are a matter of local policy"; W3C VCs say verification "does not imply evaluation of the truth of claims." The status decision is always someone's unpublished local policy — Hachure publishes it.
statusFunctionVersion = "2"
status = f(claim, evidence, events, policy, authorityTrace, 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.
Nine 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. |
revoked |
An explicit invalidation event has revoked the claim's verification; single-claim derivation folds it to stale unless a later event re-verifies. |
§ 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 without last-write-wins and without deleting losing evidence;
conflicting claims surface as contradiction transparency gaps, never silently resolved.
Claim
An assertion about a real-world subject. Stable id, subjectType / subjectId,
claimType, fieldOrBehavior, value, and an optional facet grouping.
Carries optional impactLevel, freshness (expiresAt / ttlSeconds),
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 a growing set of 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. Some integrations below ship today; others are planned profiles, marked inline.
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.
Planned: will reference OTel trace IDs from evidence records so "show the work" drills into what the agent executed. Planned: will emit trust-status changes as OTel events so status appears in existing dashboards. Won't build a tracing SDK.
Planned profile: SARIF consumer — each run would become a batch of evidence events (tool identity → authority trace; fingerprint → claim correlation). Would optionally emit SARIF so trust status can surface 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.
Planned profile: will emit verification events as VCs signed by the verifying authority.
Will publish a JSON-LD context so hachure.org/v1 documents carry PROV-O terms
for semantic-web interop.
Registers bundles (or their DSSE envelopes) as SCITT signed statements; the receipt lands in the bundle's proof block as a transparency-log anchor. SCITT proves a statement was made; Hachure keeps deriving what its claims are worth as time passes.
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.
Positioning, not a shipped profile — 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.
Planned profile: will map gen_ai.agent.* and MCP attributes into authority traces,
turning selected telemetry into durable, signed, disputable testimony.
Observability is not inspectability — OTel describes what happened; Hachure records what was verified.