~/djzs/ruleset $ cat DJZS-PM-v1.0
The taxonomy the gate scores against, the formula it hashes with, and the binding contract that lets anyone recompute a verdict from its intent, without trusting DJZS. Weights are hash-locked; a change is a versioned re-derive, never a hot patch. That immutability is what makes every hash reproducible.
unknown. The caller halts; the response returns unknown_fields. Under-specified reasoning drains here, never to a silently guessed PASS.Abstain over guess.
Weights sum to 100. FAIL threshold 25. A CRITICAL code forces FAIL on its own. All four codes are implemented and calibrated. Extraction contract DJZS-X-v1.1 (2026-09-01): a rule in the extraction layer had been demoting a correctly-detected unsourced claim to unknown unless the intent contained probability vocabulary (%, odds, chance, likely, probably), so "gut feel" and "everyone knows" produced WAIT, not M03. Found by measurement (Q2), reproduced from raw samples, removed as a versioned contract change with before/after evidence in tests/out/. Every response now states its extraction contract as taxonomy.extraction.
| Code | Name | Severity | Weight |
|---|---|---|---|
| DJZS-M01 | NARRATIVE_RESOLUTION_GAP | CRITICAL | 30 |
| DJZS-M02 | FALSIFICATION_ABSENT | CRITICAL | 30 |
| DJZS-M03 | PROBABILITY_UNSOURCED | HIGH | 25 |
| DJZS-M04 | CONSENSUS_NO_EDGE | MEDIUM | 15 |
M04 is advisory-grade: alone it rides a PASS with the flag on the certificate (weight 15 is below threshold). It blocks only by stacking, e.g. M03 + M04 = 40 → FAIL.
An 11-code taxonomy (weights sum 200) is frozen: four codes wired live (E01, I01, X01, S01; a position stated with no thesis is the degenerate circular chain: the position as its own premise), the other seven reserved. Served since 2026-09-08 by verify_perp_trade (2.00 USDC on Base, same rail as the PM tool; prediction-market bets refused free) with their weights but not yet firing, and no served surface today. Disclosed as roadmap, not sold as done. The full table lives in the repository.
The verdict is computed by a frozen deterministic engine: pure code, no model, no network, no clock. Swap the model and extraction quality changes; the rules, weights, and hash do not.
// verdict_hash: computed by the frozen engine verdict_hash = sha256(canonicalize({ verdict, risk_score, flags: flags.map(f => f.code).sort(), unknown_fields }))
The verdict hash proves the engine's output is well-formed. It does not, by itself, let a third party prove which intent the verdict describes; verdict_hash is not injective. The binding key is intent_hash, and for a receipt to be independently verifiable, that digest must be a pure, reproducible function of the intent alone.
v2 anchors the binding where the client already verifies: EIP-712 typed data, the hashing layer ERC-8004 and EAS use, displayable by every wallet, recomputable inside a Safe Guard's checkTransaction. The receipt is an EAS attestation on Base under a registered DJZS schema. No server-side field enters the binding key; anything time-varying lives in the attestation envelope.
// intent_hash: the binding key. PURE function of the intent. EIP-712. domain = { name: "DJZS", version: "2", chainId: 8453 } DJZSIntent { string action // pm_trade · swap · defi · transfer · contract_call · deploy string venue string market string side string thesis string probability_basis uint256 size_usd_cents uint256 max_loss_usd_cents string exit_condition bytes32 params_hash // class-specific extension; 0x00…00 if none } intent_hash = hashTypedData(domain, DJZSIntent, intent) // receipt: EAS attestation on Base. EIP-712-signed by the DJZS attester. Never revoked. schema = "bytes32 intentHash, string verdict, uint8 riskScore, string[] flags, string rulesetVersion" uid = 0x5ef67e2b8c617635431401d2872b2a6f79eeba54a8e19fd5ecd45aceda2a2030 // deterministic; precomputed recipient = the audited agent's address
// intent_sha256: the v1 binding key. Also pure. Also reproducible. Published here for the first time. // engine-adapter.ts · renderIntentText(intent): // keys sorted · one `key: value` line each · strings verbatim · numbers/booleans as written // nested objects as compact JSON (no spaces, insertion order) · lines joined by "\n" intent_sha256 = sha256( renderIntentText(intent) )
Reference implementation: djzs-intent.ts (intentHash(), self-tested structural + sensitive) and eas-attest.ts (registerSchema(), attestVerdict(), readVerdict()). v1 (intent_sha256) remains alongside and is equally reproducible; its rule is published below. Recompute any receipt at djzs.ai/verify.
Recompute or it didn't happen.
821da611 (2026-09-01) every paid verdict returns intent_hash and writes an EAS attestation from 0xfB0e…7824 under schema 0x5ef67e2b…2030 onto the paying agent. First attestation: 0xc5995989…5a89, binding key independently recomputed byte-identical. intent_sha256 (v1) remains alongside for pipeline continuity.thesis_statement field for DJZS-LF S01) was run the same day in three variants: 96.3% / 96.3% / 95.0% (inside the band), but class match fell to 13–14/16, with one definite no-invalidation thesis drifting from FAIL to WAIT under every variant. Acceptance for extraction changes is two-dimensional: designed-class match not worse (primary), and verdict stability inside the measured band for an identical contract, which three same-prompt runs put at 1.000 / 0.975 / 0.950, so ≥95%. That bar was revised after the fact, and the deploy it graded missed the earlier one. The bar first written here was stability within 0.02 of 0.975 with class match 16/16. The 2026-09-08 deploy (Worker 697a014a) measured 0.950 with class match 16/16 (2.5 points below the 0.975 reference, 0.5 below the band floor) and shipped; the bar was then rewritten to "class match primary, ≥95%" in the same message that disclosed the miss. Recorded as a breach with the bar revised afterward, not as a re-measurement: the revision is defensible on its merits, but a bar that moves once the number is known measures nothing, and the sequence was number first. No caller got a wrong class: class match was 16/16 and the harness’s own gate (mean ≥ 0.95) passed. What the episode cost is the meaning of the word "passed", which is why it is written here rather than quietly fixed. The rule it produced: an extraction-contract change pre-registers its threshold in the commit that introduces it, before any harness run; a miss gets a published deviation note, never a redefinition; and re-measuring the noise band is a separate commit on the unchanged contract, done before the next change rather than after a disappointing number. Full note in tests/q3/SCAN_SPEC.md §11. Resolved by splitting the contract by tool rather than sharing one prompt: verify_pm_trade runs X-v1.1 byte-verbatim; verify_perp_trade runs X-LF-v1.2. Perp harness, 2026-09-08, 14 theses × 5 replays: stability 97.1%, 13/14 identical, class match 13/14; every FAIL class lands (S01 on a thesis-less position, X01 on an unbounded one, both on the position with neither); the one split is the designed boundary case ("feels right": reason or not). Getting there took three bugs out of the layer between model and engine, none visible to the exhaustive engine sweeps: consensus demanded unanimity on objective numbers (one dissenting sample zeroed a stated leverage), the parser coerced bare values to unknown, and the harness did not record the two fields that gate S01/X01. All three are regression tests in CI now. Note: at temperature 0 the three consensus samples are near-identical draws, so this measures production determinism more than independent agreement. Harness and raw runs in tests/.contracts/DJZSVerdictRule.sol is the last step of that engine as bytecode: given the fired codes, how many scored fields were unknown, and whether the bet was bounded, it derives the risk score and the verdict, and it refuses a code or a ruleset it does not know rather than scoring it as zero. contracts/DJZSVerdictResolver.sol is an EAS schema resolver for a v3 schema (the v2 fields plus that tally): EAS accepts an attestation under it only when the stated verdict is the one the rule derives, whoever the attester is, so the public record cannot hold a verdict its own facts contradict. The rule exists in three places, the engine, a TypeScript function over the tally, and the contract, and they are held together by one fixture: every distinct tally the engine produces over its full input space (59,157 inputs, 267 tallies) scores identically in all three, in CI. What this does not do: the model still detects. The rule constrains what a verdict can be given the flags; it cannot make the flags true. Deployment on Base, schema registration, and the Worker switch are one runbook (VERDICT_RULE.md) and are pending; until they run, receipts keep landing under schema v2 exactly as before, and this rung reads BUILT rather than LIVE.verify_perp_trade. 59,049-input exhaustive sweep in CI. Roadmap.WAIT is the engine declining to rule. It says something about the thesis, not about the agent, so query_agent_trust excludes it from both sides of the fail rate and reports it separately as wait_count. Anyone reading the subgraph directly, rather than through the tool, gets a different answer. The indexed mapping increments failCount on an else-branch (verdict == "PASS" / else), so a WAIT lands in failCount and inflates the rate for any agent that ever received one. The Worker recomputes from per-audit verdicts, so the tool is right; the indexed counters are not, and they stay that way until the mapping is corrected and re-indexed. Both are returned side by side, labelled, so the discrepancy is visible rather than discovered. Tracked as a follow-up rather than folded into the read-layer fix, because a mapping change needs a subgraph redeploy and a re-index.7tNyZtffqCerZ9CdoQJTFMcrdjbRi3B9KbstAGe3G1br (audit a3a5ad8f-0418-4d63-ae7b-85b39973a25b, 2026-08-18) carries target_system: "Coinbase". It was operator-entered free text during testing; Coinbase had no involvement in that audit and no relationship to it. A certificate is immutable by design, so it cannot be edited or withdrawn — only corrected forward by a separate, separately-anchored record, which is what Correction Record 001 is. Found by a read-only audit of the first 100 mainnet certificates on 2026-09-13, which also found 94 of 100 carrying target_system: unknown. The canonical anchor for a correction is the one this register names AND the DJZS Irys signer 0xcf2d8ef4…f990cd signed; any other copy is not ours — tags on an Irys item are strings anyone can write, the signature is not, and one item does exist carrying this correction's text and tags signed by a public test key (8Kqfic6P…1Fvk, created 2026-09-13 while testing the anchoring harness, named in the register rather than left for a reader to trip over; Irys does not permit deletion). The rule that followed: from 2026-09-13 target_system is written only from a claim signed by the subject address, and is otherwise null. Every value predating the rule is unsigned by construction and now renders as unverified:<value> on every surface — a prefix that says the certificate records someone's assertion, not a verified relationship. A signature proves who authored a claim; it never proves the signer is who the name says. That part stays the reader's judgement.Disclosed as roadmap, not sold as done. Corrected forward, never rewritten.