Verifiable agent actions. Every action becomes signed context for the next.
atrib signs agent actions as records that later agents, teams, and verifiers can check. A record can describe a tool call, browser click, desktop action, policy decision, handoff, transaction, or intentional note from the agent.
Agent work already crosses tools, memory, identity, authorization, observability, evals, handoffs, and payment rails. atrib does not replace those systems. It gives them a common record that carries the action, selected evidence, and graph links across sessions, agents, teams, organizations, and protocols.
Product teams can put atrib in the execution path. A harness can sign an allow, block, or escalate decision before a high-impact browser click, desktop action, support reply, admin change, deployment, or payment-impacting step. The outcome then becomes signed context for later recall, review, handoff, or verification.
Browser and computer-use agents make the product concrete. Follow-up work can cite the decision and outcome without exposing raw browser state, desktop state, private tool payloads, or full runtime logs in public records.
Shared memory and context systems still decide what an agent should remember. Observability tools still inspect live runs. Authorization systems still issue policy and credentials. atrib signs the action trail so those systems can carry forward the same verifiable facts without trusting the runtime that stored them.
Everything below depends on one substrate property: an action is signed when it happens and remains verifiable later.
| Surface | What atrib gives you | What it composes with |
|---|---|---|
| Action control | A host can sign an allow, block, escalate, or approval decision before a selected action runs. The outcome cites the decision, so later review can see what was proposed and what actually happened. | @atrib/action-gate, policy engines, approvals |
| Cross-session continuity | Signed action hashes can travel with follow-up work. Later sessions and agents can cite accepted records instead of relying on a transcript, replay link, or runtime-local memory. | Memory systems, shared context layers, recall tools, agent runtimes |
| Browser and desktop review | Clicks, form fills, desktop actions, support replies, admin changes, and payment-impacting steps become decision/outcome pairs that can be recalled or verified later. | Browserbase, browser-use, OpenAI Computer Use, support teams, admin teams |
| Verified handoffs | A receiving agent can verify incoming record hashes, body commitments, signer trust, context policy, freshness, and inclusion proofs before signing follow-up work through informed_by. |
@atrib/verify, the recall verification parameter (@atrib/recall), continuation packets |
| Investigations and audit | Support, incident, billing, and RCA agents can sign ticket intake, scoped log reads, code-path checks, hypotheses, diagnostics, revisions, and human handoffs. A reviewer can verify the path without trusting the original runtime. | Observability tools, logs, traces, support systems, SOC 2 evidence |
| Evals and repair loops | A harness can link task setup, tool calls, verifier checks, diagnostic outcomes, and scorer output through informed_by, then publish evidence another team can replay. |
Eval harnesses, benchmark reports, inspection tools |
| Commerce settlement | The same signed record set can feed a deterministic settlement document under an agreed policy. Any merchant or auditor can recompute the payments profile §8 result. | AP2, Verifiable Intent, x402, ACP, merchant policies |
| Private evidence by default | The public log stores commitments, not private work product. Verifiers can check signatures, hashes, inclusion proofs, and selected evidence without dumping tool arguments, tool results, memory text, authorization material, or workflow context into the public payload. | Local mirrors, sidecars, opt-in archive evidence, private evidence stores |
atrib is the substrate underneath the action layer. Consuming it well (surfacing an agent's history at session start, exposing recall tools the agent can call, persisting signed records locally for replay, and putting policy gates around high-impact actions) is the job of an agent harness or runtime. atrib does not prescribe a harness. The substrate is independently useful to any harness (Claude Code, Cursor, custom agent products, in-house agent runtimes) that wants to give agents and teams contextual awareness, coordination, control, and proof over work the agent performs.
Hard boundary: the public Merkle log proves a commitment, but it is not enough context for a future agent to continue the work. A continuation agent needs Tier 2 and Tier 3 material: canonical record bodies or archive references, redacted evidence references, skill pack identities and hashes, the latest chain tail, parent dispatch anchors for subagent work, and provenance anchors. Without those, it can prove a record existed but still has to guess what happened.
One canonical harness pattern is signed diagnostic outcome + trace replay: sign the action, sign the diagnostic outcome that evaluates it with informed_by back to the action, then let the next repair step walk informed_by back from the diagnostic record with recall. This keeps "what happened" and "what it supersedes" in one verifiable path without requiring a whole-session transcript dump.
Derived evidence products sit above the protocol. A harness can build a prior-work packet, suspect report, or eval summary from signed records, body commitments, verifier checks, and inclusion proofs. Those products can decide which records are useful for a task, which stale records to avoid, and which risks remain open. They do not change the record format, the graph derivation rules, or the attest/recall verb surface.
Logs and traces are primary integration inputs for atrib, but the word "trace" can point at several different objects. The boundary matters.
| What you already have | Use | What atrib adds |
|---|---|---|
| Tool calls through MCP or an SDK callback | @atrib/mcp, @atrib/mcp-wrap, or @atrib/agent |
Signed action records with chain continuity and optional local sidecars. |
| Pre-action policy gates, approval hooks, or host lifecycle hooks | @atrib/action-gate, @atrib/mcp-wrap preCallTransform, host-specific adapters, and signer proxies |
Verifiable control points around high-impact actions. The host records the decision, execution result, outcome hash, and selected evidence. |
| OpenTelemetry or OpenInference spans | @atrib/openinference |
Signed records and recall-readable sidecars from the span stream, while Langfuse, Phoenix, LangSmith, Braintrust, or another backend keeps the operations view. |
| A host-owned run log, event stream, session history, checkpoint log, fork log, or compaction log | @atrib/runtime-log |
A log_window_manifest that commits to the bounded run window, roots, projections, receipts, and redaction policy without publishing raw log bodies by default. |
| A hosted runtime API that exports session events after the fact | A future per-runtime adapter under Pattern 5 | Consumer-side attestation over what the vendor reported, not a claim that the vendor's private runtime state is itself true. |
| Application or service code with no MCP wrapper in the path | @atrib/sdk (TypeScript) or the atrib Python SDK |
One-import attest()/recall() client: daemon-first signed writes and mirror reads, byte-identical records across both languages, full §1 record layer re-exported. |
| A handoff, support investigation, or continuation packet | @atrib/verify, the recall verification parameter (@atrib/recall), and continuation packets |
Verifier-accepted record hashes that the receiving agent can cite through informed_by. |
The short rule: observability tools inspect and debug live traces; runtime systems own logs that reconstruct or resume a run; atrib signs actions and verifies claims over selected windows. Those layers compose, but they should not collapse into one product.
The "any agent framework" claim is about tool-call middleware, not every host
runtime feature. It covers SDK and MCP surfaces where application code owns the
agent loop: raw MCP SDK, Claude Agent SDK, Cloudflare Agents, Vercel AI SDK,
LangChain JS, and similar SDKs. Those integrations live in
@atrib/agent,
@atrib/mcp, and
@atrib/mcp-wrap.
Host runtime adapters cover a different shell: Claude Code, Codex, OpenClaw,
Hermes, Cursor, Goose, hosted runtimes, or another harness that owns sessions,
lifecycle hooks, approvals, subagents, checkpoints, telemetry, and run logs.
Those adapters use @atrib/mcp-wrap for MCP
tool calls, host-specific signing code for native tool hooks,
@atrib/openinference for
OpenInference-shaped span intake,
@atrib/runtime-log for bounded run windows,
@atrib/action-gate for pre-action policy
gates, @atrib/verify for accepted handoff claims,
and atrib-attest-cli (or the forwarded atrib-emit-cli) or the local substrate for hook-class observations.
The implementation rule: one host event has one signing owner. If an MCP wrapper
already signs a tool call, the host adapter should correlate ids and skip a
second tool_call record. The private integration package pins this rule in
packages/integration/src/host-runtime-proof.ts
so future OpenClaw, Hermes, and other host proofs share the same vocabulary.
- Each record is signed by the actor's Ed25519 key and JCS-canonicalized
- A Merkle log stores commitments (hashes, not content) with RFC 6962 inclusion proofs and C2SP-canonical signed-note checkpoints
- Nine deterministic edge types connect actions into one graph with two reading
planes: chronology edges (
CHAIN_PRECEDES,SESSION_PRECEDES,SESSION_PARALLEL,CROSS_SESSION,CONVERGES_ON) and declared-relationship edges (INFORMED_BY,PROVENANCE_OF,ANNOTATES,REVISES) - The explorer's primary trace path composes
/v1/traceand/v1/chainfor readability without adding a new graph edge, validity rule, or settlement input (D118) - A pure-function calculation maps graph + policy to value distribution when commerce closes
- A public-key directory (§6) resolves opaque keys to identity claims; rotation and revocation are normative (§1.9); identity claims may declare capability envelopes (§6.7) that verifiers check records against
- Transaction records require cross-attestation: at least 2 distinct verified signer keys (agent + counterparty) per §1.7.6
- Cross-log replication (§2.11) lets consumers submit records to multiple independent logs and detect equivocation
- Privacy is configurable per record (§8 privacy postures): tool_name forms (verbatim, opaque, hashed), commitment schemes (plain, salted-sha256, hmac-sha256), timestamp granularity (ms through day)
- Adversarial threat model (§8.7) enumerates the 10-layer trust assessment stack the substrate provides
No custom cryptography. No content exposure unless the harness opts in. No trust required.
One command, no setup beyond cloning. Generates a fresh key, spins up an in-process Merkle log, fake merchant, and fake agent, runs two tool calls plus one transaction, and prints what landed in the log.
ATRIB_PRIVATE_KEY=$(node -e 'console.log(Buffer.from(crypto.randomBytes(32)).toString("base64url"))') \
pnpm --filter @atrib/integration demoExpected output:
[demo] starting dev log...
[demo] dev log running at http://127.0.0.1:58958
[demo] starting merchant tool server (fake search API)...
[demo] starting agent client...
[demo] agent connected to merchant
[demo] step 1: agent calls 'search' for the first time (genesis)
[log] +tool_call ctx=7f71199d… chain=sha256:064692c27… idx=0
[demo] step 2: agent calls 'search' again (chained from step 1)
[log] +tool_call ctx=7f71199d… chain=sha256:381c22ac6… idx=1
[demo] step 3: agent observes a fake x402 payment receipt
[log] +transaction ctx=7f71199d… chain=sha256:96ac3e962… idx=2
[demo] final state
[demo] 3 records in the log
[demo] 2 tool_call records
[demo] 1 transaction record
[demo] chain length: 3
[demo] done.
The signatures, chain hashes, and transaction detection are production code. Only the surrounding environment (merchant, agent, network) is stubbed.
Now that you've seen the demo, pick the install path that matches what you're doing:
- Sign tool calls your MCP server handles:
@atrib/mcp(below) - Sign tool calls your agent makes:
@atrib/agent(below) - Gate high-impact actions before they run:
@atrib/action-gate - Attach signed records to an existing OpenInference span stream:
@atrib/openinference - Prove a bounded run window from a host-owned runtime log:
@atrib/runtime-log - Verify records someone else produced:
@atrib/verify(below)
import { atrib } from '@atrib/mcp'
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js'
const server = atrib(new McpServer({ name: 'my-tool', version: '1.0.0' }), {
creatorKey: process.env.ATRIB_PRIVATE_KEY,
serverUrl: 'https://my-tool.example.com',
})One line. Every successful tool call emits a signed attribution record, propagates W3C trace context, and submits to the log asynchronously.
@atrib/agent exports one interceptor plus a helper
per framework; side-by-side quick-starts live in its README. Every runnable
example and proof, one per framework or runtime surface, is cataloged in
Examples and proofs below.
import { AtribVerifier } from '@atrib/verify'
const verifier = new AtribVerifier({
merchantKey: process.env.ATRIB_MERCHANT_KEY,
})
const result = await verifier.verify(recommendationDoc)
// { valid: true, signatureOk: true, calcMatch: true, distribution: {...} }Verification re-runs the payments profile §8 calculation locally and compares the result. No trust in any intermediary.
atrib certifies five verifiable axes of agent activity: who acted (identity), what they did (event_type), when (timestamp), what came before what in the chronology plane, and what the signer claimed informed, anchored, annotated, or revised the action in the declared-relationship plane.
atrib does NOT certify that the agent's reasoning is truthful, that prior records actually influenced subsequent decisions, or that tool responses were real absent tool-side attestation. A signature proves who committed to a claim, never that the claim is true. The first two limits are intrinsic to signed claims. The third narrows when another party signs its own evidence: the tool signs its response, a counterparty co-signs a transaction, an evaluator signs a diagnostic, or a witness attests the outcome. Those signatures corroborate the action, not the agent's reasoning. The substrate is content-preserving (commitments, not content) and disclosure-configurable: harnesses pick how much each record reveals via the privacy postures in spec §8.
This positioning keeps the claim honest. See spec §3 "What atrib chains, what it does not" for the detailed enumeration and spec §7.6 for the outcome-verification patterns that close the tool-response gap.
This table covers framework tool-call middleware, not full host runtime integration. Host runtime work has its own boundary in Architecture and in the OpenClaw/Hermes map.
| Framework | Adapter | Status |
|---|---|---|
Raw @modelcontextprotocol/sdk |
wrapMcpClient(client, interceptor, { serverUrl? }) |
✅ Shipped |
| Claude Agent SDK (in-process, Case A) | Wrap McpServer with atrib() directly |
✅ Shipped |
| Claude Agent SDK (third-party, Case B) | createAtribProxy({ upstream, interceptor }) |
✅ Shipped |
| Cloudflare Agents | attributeCloudflareAgentMcp(agent, { interceptor, serverUrls }) |
✅ Shipped |
| Vercel AI SDK MCP | attributeVercelAiSdkMcp(mcpClient, { interceptor, serverUrl }) |
✅ Shipped |
| LangChain JS MCP | attributeLangchainMcp(multiClient, { interceptor, serverUrls }) |
✅ Shipped |
| OpenAI Agents SDK | Planned (different transport architecture) | ⏳ |
| Mastra | Receipt proof for @mastra/mcp; adapter planned |
🧪 Proof |
Each row is a runnable example or a pinned proof artifact under
packages/integration/examples/ (proof
packets under proof-packets/). Start with the row matching
your stack.
| Example | Path |
|---|---|
| Vercel AI SDK + AI Gateway | packages/integration/examples/vercel-ai-sdk/ |
| Claude Agent SDK (Case A + Case B) | packages/integration/examples/claude-agent-sdk/ |
| Cloudflare Agents | packages/integration/examples/cloudflare-agents/ including live-worker-proof, live-client-proof, the interactive approval-trace HITL example, the paid-x402-action-gate proof, the x402-path-b-reference proof, and the D111 oauth-evidence-infra Worker reference |
| Cloudflare x402 paid agent proof | packages/integration/examples/cloudflare-agents/paid-x402-action-gate/ and proof-packets/cloudflare-x402-paid-agent/ show a paid MCP request gated by @atrib/action-gate, with hash-only x402 lifecycle facts bound to the decision and outcome. |
| LangChain JS | packages/integration/examples/langchain-js/ |
| LangGraph Store memory | packages/integration/examples/langgraph-store/ |
| LangGraph Python checkpointing | packages/integration/examples/langgraph-python-checkpointer/ |
| LlamaIndex.TS memory | packages/integration/examples/llamaindex-memory/ |
| LlamaIndex Python memory | packages/integration/examples/llamaindex-python-memory/ |
| Letta memory | packages/integration/examples/letta-memory/ |
| A2A handoff evidence | packages/integration/examples/a2a-handoff/ signs an A2A AgentCard, carries an atrib evidence packet in an A2A DataPart, verifies the packet, and signs the receiver follow-up through informed_by. |
| Google ADK TypeScript and Python proofs | packages/integration/examples/google-adk-typescript/ and packages/integration/examples/google-adk-python/ cover callback signing and decision-ledger signing for each runtime. |
| Google stack chain proof | packages/integration/examples/google-stack-chain/ links AP2 / VI receipt verification, A2A signed handoff evidence, a Google ADK Python allow decision, and the ADK Python tool outcome through verifier-resolved informed_by records, with a deterministic snapshot, BigQuery Agent Analytics-shaped local fixture, Cloud Run-backed runtime path, and a visual workbench. |
| OpenAI runtime receipts | packages/integration/examples/openai-agents-runtime/ and packages/integration/examples/openai-responses/ |
| Mastra runtime receipts | packages/integration/examples/mastra-runtime/ |
| Action-control gate proof | packages/integration/examples/action-control-gate/ lets one browser-shaped read run, blocks one payment-impacting write, escalates one customer message, and proves each decision-to-outcome binding with @atrib/action-gate. |
| Cloudflare x402 Path B reference | packages/integration/examples/cloudflare-agents/x402-path-b-reference/ and proof-packets/cloudflare-x402-path-b-reference/ show the local x402 v2 header flow through @atrib/agent: 402 challenge, paid retry context propagation, PAYMENT-RESPONSE detection, Path B transaction emission, and counterparty attestation. |
| Browser workflow receipt | packages/integration/examples/browser-workflow/ |
| Browserbase Stagehand proof | packages/integration/examples/browserbase-stagehand/ and proof-packets/browserbase-stagehand/ |
| Firecrawl web ingestion proof | packages/integration/examples/firecrawl-web-ingestion/ and proof-packets/firecrawl-web-ingestion/ |
| OpenETR transfer proof | packages/integration/examples/openetr-transfer/ and proof-packets/openetr-transfer/ |
| ActiveGraph runtime-log proof | packages/integration/examples/activegraph-runtime-log/ |
| Reference runtime-log source | packages/integration/examples/reference-runtime-log/ |
| Dogfood runtime-log proof | packages/integration/examples/dogfood-runtime-log/ |
| Secondary runtime-log adapter pair | packages/integration/examples/secondary-runtime-log/ |
| Runtime-log verifier UX | packages/integration/examples/runtime-log-verifier-ux/ |
| Brief dcbench evidence | packages/integration/examples/brief-dcbench/ |
| Proof-log receipt | packages/integration/examples/proof-log-receipt/ |
| Trace repair suspect | packages/integration/examples/trace-repair-suspect/ |
| End-to-end demo | packages/integration/examples/end-to-end/ |
atrib detects transaction events from all six simultaneously. It does not move money or enforce transactions. The per-rail hooks are defined by the atrib Payments Profile, which versions independently of the core spec (D147); core keeps the transaction event type, the cross-attestation rule, and the evidence envelope.
| Protocol | Sponsor | Detection signal | Profile ref |
|---|---|---|---|
| ACP | Stripe / OpenAI | status === "completed" + embedded order |
§2.1 |
| UCP | Google / Shopify | Same as ACP + ucp.version envelope |
§2.2 |
| x402 | Coinbase | PAYMENT-RESPONSE HTTP header |
§2.3 |
| MPP | Tempo Labs / Stripe | Payment-Receipt HTTP header |
§2.4 |
| AP2 | Successful CheckoutReceipt or PaymentReceipt | §2.5 | |
| a2a-x402 | A2A task metadata payment-completed |
§2.5 |
x401 is intentionally not in this table. It is a 401 proof-requirement protocol for credential-gated HTTP routes, so @atrib/verify treats x401 artifacts as authorization evidence rather than transaction signals. The current Proof issue and PR map lives in docs/proof-x401-open-threads.md.
Current packages come first. The deprecated legacy packages follow: all are re-export shims (or, for summarize, a standalone server) whose tool names stay mounted as permanent aliases per D164. Private workspace packages that never publish close the list.
| Package | What it does |
|---|---|
@atrib/sdk |
Consolidated client SDK: attest()/recall() verbs, daemon-first over the local primitives runtime with in-process fallback, full §1 record layer re-exported. Byte-identical Python sibling at python/. |
@atrib/attest |
The write verb: one attest tool signs observations, annotations (ref.kind: "annotates"), and revisions (ref.kind: "revises"), with the legacy emit / atrib-annotate / atrib-revise tool names mounted as permanent aliases over the same handler. |
@atrib/recall |
The read verb: one recall tool dispatches every read shape (history, walks with direction, content search, session chain, annotations, revisions, orphans, by-signer) plus a verification parameter, with the legacy recall_* / trace / trace_forward / atrib-verify names mounted as permanent aliases. |
@atrib/daemon |
Stateless-native local daemon (binary atribd): serves the seventeen-tool alias-window union (fifteen legacy names plus the attest and recall verbs) over stateless Streamable HTTP, direct stdio, or a stdio-to-HTTP proxy shim, with per-context write serialization. The recommended local topology per D148. |
@atrib/mcp |
Server middleware. Wraps an MCP server, emits signed records. |
@atrib/agent |
Agent middleware. Interceptor + framework adapters. |
@atrib/action-gate |
Host-owned action gate. Signs policy decisions and outcomes before selected high-impact actions run. |
@atrib/verify |
Merchant verification. Re-runs the calculation locally, checks AP2 / VI evidence, verifies authorization evidence such as MCP/OAuth, AAuth, and x401, and verifies Pattern 3 handoff claims. |
@atrib/cli |
CLI: keygen, Keychain key management, identity-claim ops, key rotation and revocation. |
@atrib/mcp-wrap |
Generic config-driven MCP wrapper. Multiplies coverage to any MCP server at zero per-server code cost. |
@atrib/directory |
AKD-backed identity-claim directory SDK. Bundles WASM artifacts from the Rust bridge. |
@atrib/openinference |
OpenTelemetry SpanProcessor consuming OpenInference-shaped spans and emitting signed atrib records plus recall-readable local sidecar content. Reference impl of spec §9 Pattern #4; one adapter transitively covers every framework with OpenInference instrumentation. |
@atrib/memory-tool |
Anthropic Memory Tool handler wrapper. Signs memory commands as atrib records while the host keeps its own storage backend. |
@atrib/runtime-log |
Runtime-log proof helpers. Builds and verifies log_window_manifest objects for host-owned agent run windows. |
All six are deprecated on npm and remain installable. Their tool names stay mounted as permanent aliases, so existing configurations keep working and signed records are byte-identical either way.
| Package | What it was, and where it went |
|---|---|
@atrib/emit |
Legacy home of the emit write primitive; re-export shim over @atrib/attest, binaries forward. |
@atrib/annotate |
Legacy home of atrib-annotate (marks past records' importance, topics, and summary); folds into attest and stays mounted as a permanent alias. |
@atrib/revise |
Legacy home of atrib-revise (supersedes a prior position with a stated reason); folds into attest and stays mounted as a permanent alias. |
@atrib/trace |
Legacy home of trace / trace_forward (informed_by walks); re-export shim over @atrib/recall; the tools fold into recall shape walk with a direction. |
@atrib/summarize |
Cognitive-primitive MCP server: reads N records and synthesizes a narrative via an OpenAI-compatible LLM. No successor shape in the read verb; stays mounted through the alias window. |
@atrib/verify-mcp |
Legacy home of atrib-verify (handoff-evidence acceptance); re-export shim over @atrib/recall; the tool folds into the recall verification parameter. |
Fixtures, test harnesses, and superseded local runtimes. Marked private: true; never published.
| Package | What it does |
|---|---|
@atrib/primitives-runtime |
Local MCP runtime: exposes the seventeen-tool alias-window union through one stdio or Streamable HTTP MCP server for dogfood harnesses that would otherwise spawn one process per primitive. Superseded as the recommended topology by @atrib/daemon. |
@atrib/log-dev |
Dev-only in-memory log stub. Not for production. |
@atrib/integration |
Cross-package tests + runnable examples. |
The twenty designed-public packages split fourteen current and six deprecated; the tables above are the canonical list. The python/ directory ships the atrib Python SDK (published on PyPI), the first non-TypeScript implementation of the §1 record layer, held byte-identical to the TypeScript implementation by the shared conformance corpora and a cross-implementation determinism harness.
Four services are deployed today: services/log-node/ (https://log.atrib.dev/v1), services/graph-node/ (https://graph.atrib.dev/v1), services/directory-node/ (https://directory.atrib.dev/v6), and services/archive-node/ (https://archive.atrib.dev/v1). The public explorer at https://explore.atrib.dev/ composes their read APIs into one product surface, and a 13-gate end-to-end verifier runs daily in CI against the deployed log.
The record layer, transparency log, graph, key directory, payments profile, and verifier evidence checks are implemented, deployed, and pinned by conformance corpora. Witnessing and multi-log replication are spec-defined but not yet deployed. The full enumeration, with spec and decision references, is in STATUS.md.
node -e 'console.log(Buffer.from(crypto.randomBytes(32)).toString("base64url"))'Store the output as ATRIB_PRIVATE_KEY. The public key is derived at runtime.
atrib-spec.md covers:
- §0: Foundations
- §1: Attribution record format, signing, propagation, transaction event boundary
- §1.9: Key rotation and revocation (D033)
- §2: Merkle log protocol (C2SP tlog-tiles, proofs, witnessing)
- §3: Graph query interface (nine edge types)
- §4: Position of the policy layer; the policy format, negotiation, and calculation live in the payments profile (D147)
- §5: SDK contract, automation, degradation guarantees
- §6: Public-key directory (AKD-based; D034)
- §7: Harness integration patterns (informative)
- §8: Privacy postures (D045; per-record disclosure dials)
- §9: Runtime integration patterns (informative; seven peer patterns per D069 and D102)
- Provenance travels with the artifact. Embedded at creation, not inferred later.
- Accountability without content exposure. The log stores hashes, not content.
- Settlement is separate from attribution. The protocol records what happened. It does not move money.
- No central arbiter of value. Trust from math and open spec, not from trusting atrib.
- The protocol is open. The product is commercial. Spec, signing libraries, calculation algorithm, and log software are open. Anyone can self-host. atrib operates a hosted service as a commercial product built on the open protocol.
DESIGN.md is the source of truth for atrib's public product surfaces: website, explorer, docs, package README patterns, share images, and user-facing reliability states. It records the current state, target direction, tokens, components, writing rules, and remaining design backlog.
- Policy templates and guide
- Product design system
- Architecture and trust model
- Prior art and standards map
- Decision log
atrib-log-pp-cli: a Printing-Press-generated Go CLI for the public log API (signed checkpoint, recent entries, lookups by hash / context / creator, Merkle tiles, local SQLite mirror). Complementary to theattest/recallMCP verbs: agents use the verbs, humans and scripts use the CLI.- Implementation status
- Contributing
Apache 2.0