# STEADYWRK Attest — v0 Specification
## An open, self-expiring, adversarially-verified attestation-of-work format for autonomous agents

- **Status:** v0.1 — **committed 2026-07-13, live for citation on merge.** Narrow-wedge scope: attestation of **physical-world agent work**, re-verified by a separate agent, with evidence-tier self-expiry.
- **License:** CC0 1.0 Universal (public domain dedication). The format is free to implement, fork, and cite. STEADYWRK operates the reference registry and issues attestations against its own operations.
- **Editors:** STEADYWRK (Aqaba). Contact: https://steadywrk.app/contact
- **Date:** 2026-07-12 (drafted) · 2026-07-13 (published)
- **Canonical URL:** `https://steadywrk.app/attest/v0/spec.md` · machine mirror `https://steadywrk.app/.well-known/attest.json` (`/attest/v0` is reserved for the rendered page)
- **Not vaporware clause:** every construct below maps to code that already exists in the STEADYWRK estate. File references are given inline. Where a hook is not yet wired, it is marked **[PLANNED]** with the exact file that must change.

---

## 0. Design goal and non-goals

**Goal.** Define a portable, verifiable record that answers one question existing standards do not:

> *Did this agent actually do this unit of work, to what standard, on what evidence — and is that judgement still valid today?*

STEADYWRK Attest is an **attestation-of-work** format. It is deliberately narrow: it is not an identity system, not a payment rail, not a reputation aggregator. It is the graded, expiring, adversarially-checked receipt that those other layers consume.

**Non-goals (delegated to existing standards):**
- *Identity* — who the agent is → delegate to **ERC-8004 Identity Registry** (ERC-721 agent identity) and A2A Agent Cards.
- *Payment* — settling the job → delegate to **x402** / Trusted Agent protocols.
- *Reputation aggregation* — the rolling score → an Attest feed can be consumed by ERC-8004 Reputation Registry, Mnemom-style scorers, or an insurer's model. Attest supplies the **primary evidence rows**, not the composite score.

**The one-line positioning:** *Identity says the agent exists. Reputation says people liked it. Attest says the work was checked, graded against evidence, and here is the exact evidence and its expiry date.*

---

## 1. Why this format exists (the gap, as of July 2026)

The agent-trust stack is filling fast, but along an identity/reputation axis, not a **verified-work** axis:

- **ERC-8004 "Trustless Agents"** (MetaMask/EF/Google/Coinbase; draft EIP, reference impls on Base Sepolia / Linea Sepolia / Hedera) defines Identity, Reputation, and **Validation** registries — but the spec itself states it *cannot cryptographically guarantee that advertised capabilities are functional.* The Validation Registry is a **hook** awaiting validators. STEADYWRK Attest is a validator format for that hook.
- **Work-attestation competitors have now appeared** (this narrows the window — see gap analysis): OVERT (`overt.is`, runtime-control execution evidence), Proof of Insight (`proofofinsight.org`, signed evidence for agentic analyses), OpenA2A (identity + 9-factor trust + RFC 6962 log), Mnemom v2.0 (behavioral Trust Rating AAA–CCC with Merkle/Ed25519/STARK proofs and a public directory), and the **NIST CAISI AI Agent Standards Initiative** (launched 2026-02-17).

**STEADYWRK's defensible differentiators, encoded as format primitives:**
1. **Physical-world work** — attestations of dispatched field-service jobs (a real completion, a real invoice, a real override), not just token/DSL analyses.
2. **Adversarial re-verification by a separate agent** — the Verifier never sees the claimant's narrative; the adversarial verifier is rewarded only for kills. (internal claim engine)
3. **Self-expiry by evidence tier** — an attestation is not permanent; it liquidates on a TTL keyed to its evidence quality (isnad grading made machine-readable).
4. **Append-only, hash-chained ledger** with optional Ed25519 signatures and ERC-8004 anchoring.

---

## 2. Conformance language

The key words MUST, MUST NOT, SHOULD, MAY are per RFC 2119/8174. An implementation is **conformant** if it (a) emits records that validate against §5's schema, (b) enforces the tier→TTL table in §4, and (c) exposes the four verification predicates in §7.

---

## 3. Core concepts and the mapping to existing code

| Attest concept | What it is | Backing implementation (already exists) |
|---|---|---|
| **Work Claim** | An atomic, falsifiable statement that a unit of work was done to a standard | internal `claims` row, `ClaimRow` — the internal claim-ledger schema (internal) |
| **Evidence** | The cited, re-fetchable proof (URL + hash + verbatim text + selector) | internal `sources` row, `SourceRow` — same file |
| **Verification** | A cold, evidence-only re-check by a separate agent | internal `verifications` + Verifier prompt — the verifier agent prompt (internal) |
| **Falsification** | An adversarial attempt to kill a high-tier attestation | adversarial verifier agent (internal) |
| **Grade (tier + status)** | Evidence tier A–F, lifecycle status | `EvidenceTier`, `ClaimStatus` enums — schema.ts |
| **Expiry** | TTL by tier; auto-flip to RE_VERIFY | `TTL_BY_TIER`, gate `G6_ttl` — schema.ts, the deterministic gate suite (internal) |
| **Structural gates** | Deterministic filter before any spend | `G1..G11` — the deterministic gate suite (internal) |
| **Attestation record** | The signed, chained, public artifact | `@steadywrk/ledger` (Ed25519 hash-chain) + AILA Sijill (internal package) |
| **ERC-8004 anchor** | keccak256 job-completion hash on-chain | `/api/ledger/[id]/validate/route.ts` (already validates `0x`+64hex) |
| **Query surface** | MCP tools + REST | the dispatch MCP server + the nervous-system MCP Worker (internal) |

The design principle: **STEADYWRK Attest is the public projection of the internal claim ledger, restricted to `claim_type ∈ {work-attestation types}`, sealed into the hash-chained ledger, and exposed read-only over MCP + REST.**

---

## 4. Evidence tiers and self-expiry (the isnad grading)

Every attestation carries an **evidence tier** that fixes its **time-to-live**. When the TTL lapses the attestation does not vanish — it flips to `RE_VERIFY` (gate G6) and MUST be re-fetched and re-graded before it is served as valid again. This is the machine-readable form of isnad's narrator-reliability grading: a *sahih* (sound) chain is trusted longer than a *da'if* (weak) one, and every grade is re-examinable.

Tiers are re-anchored to **work evidence** (the internal tiers were tuned for market-research claims; Attest re-scopes them):

| Tier | Work-evidence meaning | TTL (days) | Example |
|---|---|---|---|
| **A** | First-party signed telemetry + counterparty confirmation | 365 | Invoice paid + customer sign-off + system log, all hash-matched |
| **B** | First-party telemetry + independent third-party record | 180 | Completion log + partner FSM webhook |
| **C** | First-party structured record, single source | 90 | Work-order status transition in own DB |
| **D** | Derived / inferred operational signal | 60 | NTE-variance computed from a batch |
| **E** | Human-asserted, unverified | 30 | Operator marked "done" in chat, no artifact |
| **F** | Anecdote / self-report only | 7 | Agent's own claim, no evidence |

Source of truth: `TTL_BY_TIER` in `schema.ts` (values match exactly). Conformant implementations MUST NOT serve an attestation whose `last_verified_at + ttl_days < now` with status `valid`; it MUST read `expired → RE_VERIFY`.

**Lifecycle status** (from `ClaimStatus`): `EMERGING → ESTABLISHED` (survived verification + ≥2 independent evidence families, gate G3) → may go `CONTESTED` (adversarial verifier weakened it) → `FALSIFIED` (killed; human ratifies) → `RE_VERIFY` (TTL lapsed) → `SUPERSEDED` (replaced by a newer attestation of the same work). `ORIGINAL` = STEADYWRK-authored methodology claim.

---

## 5. The attestation record schema

An Attestation Record is the public, sealed artifact. It is a projection of a internal claim + its verified sources into a ledger row. JSON shape (v0):

```jsonc
{
  "attest_version": "0",
  "id": "ATT-000123",                    // stable; minted from claims_clm_seq analog (atomic nextval, never MAX+insert)
  "work": {
    "type": "dispatch.completion",       // controlled vocab, §5.1
    "subject_agent": "did:erc8004:8453:0x…/42",  // ERC-8004 identity of the agent that did the work
    "statement": "Emergency plumbing WO dispatched in TX, matched + completed within NTE, customer-confirmed.",
    "scope": { "geo": "US-TX", "segment": "facilities-maintenance", "unit": "work_order",
               "time_start": "2026-07-10T14:02:00Z", "time_end": "2026-07-10T17:41:00Z" }
  },
  "grade": {
    "tier": "A",                          // §4
    "status": "ESTABLISHED",              // §4 lifecycle
    "confidence": 0.86,                   // maps to CALIBRATION_BANDS → "highly likely"
    "band": "highly likely"
  },
  "evidence": [                            // one per SourceRow; body never stored, only fingerprint
    {
      "role": "primary",                  // primary|regulator|company_site|dataset|marketplace_terms|community_signal|aggregator|connector
      "family": "steadywrk.app",          // independence group; mirrors collapse to one family
      "url": "https://steadywrk.app/api/ledger/…",
      "final_url": "…",
      "fetched_at": "2026-07-11T02:00:00Z",
      "http_status": 200,
      "evidence_hash": "sha256:…",        // 64-hex, over the fetched evidence text
      "evidence_selector": "css:#status", // where in the doc
      "archive_url": "https://web.archive.org/…"
    }
  ],
  "verification": {
    "verifier_verdict": "CONFIRMED",       // CONFIRMED|MISMATCH|DEAD_LINK|ESCALATE (VerifierVerdict enum)
    "verified_by": "attest-verifier",      // separate agent, no shared state with claimant
    "verified_at": "2026-07-11T02:00:03Z",
    "mismatch_fields": [],
    "adversarial": {                       // present once the adversarial verifier has run
      "attempted": true,
      "outcome": "no_evidence_found",      // weakens|falsifies|no_evidence_found
      "attacked_at": "2026-07-13T02:00:00Z"
    }
  },
  "expiry": {
    "ttl_days": 365,
    "last_verified_at": "2026-07-11T02:00:03Z",
    "expires_at": "2027-07-11T02:00:03Z",
    "on_expiry": "RE_VERIFY"
  },
  "gates_passed": ["G1","G2","G3","G5","G6","G11"],  // deterministic checks that held
  "ledger": {
    "seq": 123,                            // monotonic per-chain
    "prev_hash": "sha256:…",
    "row_hash": "sha256:…",                // sha256(seq|prev_hash|sealed_at|canonical_payload_json)
    "signature": "base64:…|null",          // Ed25519 over row_hash; null until signing key seated (Phase 2)
    "key_id": "ed25519-2026-01|null",
    "sealed_at": "2026-07-11T02:00:05Z"
  },
  "anchor": {                              // optional on-chain anchor
    "erc8004_validation_hash": "0x…64hex", // keccak256 job-completion digest; validated by /api/ledger/[id]/validate
    "chain_id": 8453,
    "registry": "erc8004:validation"
  }
}
```

### 5.1 Work-type controlled vocabulary (v0)
`dispatch.completion` · `dispatch.quote` · `dispatch.override` (human corrected the agent — a *negative* attestation, deliberately first-class) · `analysis.claim` · `agent.eval` (a scored evaluation run). New types are additive; a type MUST NOT be reused with different semantics.

### 5.2 Field provenance
The `evidence[]` block is a 1:1 projection of internal `SourceRow` (`url`, `final_url`, `source_family`, `source_role`, `evidence_hash` (64-hex sha256), `evidence_selector`, `archive_url`, `fetched_at`, `http_status`). The `ledger` block is a 1:1 projection of `SijillEntry` in `packages/ledger` (`seq`, `prevHash`, `rowHash`, `signature`, `keyId`) — **rowHash = sha256(`${seq}|${prevHash}|${sealedAt}|${canonicalPayloadJson}`)**, identical to the live `wit` worker and `trust-rail` chain semantics.

---

## 6. Issuance pipeline (how a record is created)

This is the internal seven-stage spine, re-cast for work attestation; Attest adds a `claim_type` filter and a seal step. **State note:** the spine's components — schema, the G1–G11 gates, the Verifier/adversarial verifier agent roles, and the hash-chained ledger — exist as code; the running adversarial issuance pipeline is **[PLANNED to resume]** (its nightly execution is currently paused). Records are chain-verifiable today; the live adversarial re-grading is the wired-on-resume step. Treat "attestation issuance" as the target contract, not a claim that the pipeline is executing this minute.

```
Work event (dispatch completion / override / eval)
  → Claimant emits a Work Claim + cited evidence + "why this might be false"   [Hunter role]
  → Deterministic gates G1,G3,G4,G5,G6,G8,G11 run BEFORE any spend            [gate suite]
  → Verifier (separate agent, no shared state) cold re-fetches every evidence  [verifier agent]
      URL; keeps only CONFIRMED; MISMATCH/DEAD_LINK → reject with reason
  → G2 (verified-only) must pass: every evidence row has a CONFIRMED verdict
  → Grade assigned: tier (evidence quality) + status + confidence band
  → Seal: append to hash-chained ledger (Ed25519 optional), mint ATT-###      [packages/ledger]
  → [async] adversarial verifier attacks ESTABLISHED records; weakens→CONTESTED,          [adversarial verifier agent]
      falsifies→FALSIFIED (human ratifies the kill — engine never silently deletes)
  → [optional] ERC-8004 anchor: POST keccak256 hash to /api/ledger/[id]/validate
```

**Cost/abuse guardrails (already enforced):** hard per-pulse ticket and spend caps; hitting a cap halts issuance and marks the run blocked — an Attest issuer MUST fail closed, never emit ungraded records under load.

**Hard rules inherited (MUST):** (1) Verifier is a different agent from the claimant with no shared state. (2) No record reaches `ESTABLISHED` without surviving the adversarial verifier. (3) A gate passed by weakening the check is a FALSE pass — report real state. (4) Never certify an evidence source you did not fetch.

---

## 7. Verification predicates (what a consumer can check)

A conformant registry MUST expose these four read-only predicates. Anyone — an insurer's model, an ERC-8004 validator, a rival — can run them without trusting STEADYWRK:

1. **`chain_intact(from_seq, to_seq) → {valid, brokenAtSeq?, reason?}`** — recompute `row_hash` for every link and confirm `prev_hash` linkage. Backed by `verifyChainFromGenesis` / `ChainVerifyResult` in `packages/ledger`. Reasons: `hash_mismatch | prev_hash_mismatch | signature_invalid | empty_chain`.
2. **`signature_valid(seq) → bool`** — verify the Ed25519 signature over `row_hash` for the named `key_id`. Backed by `verifyHead`/`signHead`. **[PLANNED wiring]** signatures are `null` until the Phase-2 key is seated (see `@steadywrk/ledger` header: "INERT: nothing imports this yet… `ed25519_signature = NULL` until the Phase 2 / V-gated cutover"). Chain-hash verification works today; signatures are the V-gated upgrade.
3. **`evidence_live(att_id) → {evidence_hash, refetch_status}`** — re-fetch each evidence URL and compare sha256 to the stored `evidence_hash`. A drifted hash means the underlying record changed after sealing.
4. **`not_expired(att_id) → {valid, expires_at, status}`** — check TTL per §4; a lapsed attestation returns `status: RE_VERIFY`, never `valid`.

These four make deception structurally hard: you cannot forge a record without breaking a hash, and you cannot let a stale record masquerade as fresh.

---

## 8. ERC-8004 Validation Registry integration

ERC-8004's Validation Registry is explicitly a set of *hooks for validator smart contracts to publish validation results.* STEADYWRK Attest is a validator that publishes into that hook.

**Binding (v0):**
- Attest computes a `keccak256` **job-completion digest** over the canonical work payload (`work` + `grade.tier` + `grade.status` + `ledger.row_hash`). Format: `0x` + 64 hex — **already validated** by `validateErc8004Hash()` in `/api/ledger/[id]/validate/route.ts` (regex `^0x[0-9a-f]{64}$`, state machine `pending → validated`, `executionLedger.erc8004Hash` column exists).
- The `subject_agent` is an ERC-8004 Identity Registry token (`did:erc8004:<chain>:<addr>/<id>`).
- A consumer reading the ERC-8004 Validation Registry finds STEADYWRK's validator address → resolves the digest → fetches the full Attest record over REST/MCP → runs the §7 predicates.

**What Attest adds that the raw registry cannot:** the registry stores a *result*; Attest stores the *graded, expiring, re-fetchable evidence behind the result*. ERC-8004 admits it "cannot guarantee capabilities are functional" — the Attest evidence chain is precisely that missing functional proof.

**[PLANNED]** the on-chain publish step (writing the digest to the Validation Registry contract) is not yet wired — the digest is currently validated and stored off-chain in `executionLedger`. Wiring is a Cloudflare Worker + wallet, V-gated (constitutional: on-chain writes = money/keys).

---

## 9. Query surface (MCP + REST)

STEADYWRK already ships a dispatch MCP server (tools `dispatch.quote|order|evals`) and a separate nervous-system MCP Worker (internal). Attest adds **read-only** tools to the same servers so agents can *call* the standard, not just cite it:

| Tool (MCP) | REST | Returns |
|---|---|---|
| `attest.get(id)` | `GET /api/attest/v0/:id` | Full attestation record (§5) |
| `attest.verify(id)` | `GET /api/attest/v0/:id/verify` | The four §7 predicate results |
| `attest.query(agent?, type?, min_tier?, status?)` | `GET /api/attest/v0?…` | Matching records (paginated) |
| `attest.spec()` | `GET /attest/v0/spec.md` + `/.well-known/attest.json` | This spec + machine schema |

Auth posture: **write/issuance** endpoints are internal-only and access-controlled; **read/verify** endpoints are public (the whole point is public verifiability), rate-limited.

**[PLANNED]** the `attest.*` tools and `/api/attest/v0/*` routes are new; they reuse existing `@steadywrk/ledger` verify functions plus a `claim_type` filter, and the crossing to the outer internal organism is over the **MCP contract only** — never a direct cross-database read (the two-organism DB boundary is absolute). No new infrastructure — a new read-only route group plus four tool definitions on the existing MCP servers.

---

## 10. Canonical-source lock-in (first-to-publish)

Publishing this spec CC0 with a stable canonical URL, a `/.well-known/attest.json` machine mirror, an `llms.txt` entry, and schema.org `Claim`/`Dataset` markup makes STEADYWRK the **citable origin** of the attestation-of-work vocabulary. Every downstream implementer, and every answer engine summarizing "how do you attest agent work," should resolve to this document. The AILA Sijill / canonical-source attest routes (`/api/canonical-source/*`) already implement the first-to-publish timestamp-lock pattern; Attest is issued through the same ledger, so the spec's own publication becomes an ATT-### record once issuance wiring lands **[PLANNED]** (dogfooding: the standard attests to its own release).

---

## 11. Open questions for v1 (deliberately unresolved in v0)
1. **Negative attestations** — `dispatch.override` records a human correcting the agent. Should the composite feed expose failure rate directly, or only to insurers under contract? (Underwriting value vs. reputational cost.)
2. **Cross-issuer trust** — if a third party issues Attest records, how is *their* Verifier independence proven? (v1: issuer must publish its own §7-verifiable chain; the standard rates the raters.)
3. **On-chain vs off-chain default** — anchor every record or only tier-A? (Cost vs. verifiability.)
4. **PII / commercial sensitivity** — evidence bodies are never stored (only hashes), but scope fields (`geo`, `segment`) leak. v0 minimizes; v1 needs a redaction-class field.

---

## 12. Changelog
- **v0.1 (2026-07-12)** — initial draft, grounded on the internal claim ledger, `@steadywrk/ledger`, the ERC-8004 validate route, and the shipping MCP servers.
- **v0.1 published (2026-07-13)** — published for citation at the canonical URL, CC0. `attest.*` query tools and issuance wiring remain [PLANNED] as marked.