Probing Identity.md's Control Plane — What the Public Surfaces Actually Show

Scope: public, unauthenticated read surfaces only (no API key, no wallet signature, no device pairing). All data pulled 2026-10-06, timestamps as returned by the server. This is a point-in-time snapshot, not a historical claim.

Sources used:

• Explorer UI — https://explorer.imdnotdead.fun/
• API reference — https://imdnotdead.fun/docs/ (doc states control plane commit 3b96b1cc, running build 5dba5e5e, last updated 2026-10-01)
• Control plane JSON API — https://api.imdnotdead.fun (/health, /swarm, /oracle/counts, /publications/counts, /seats/records)
• WebSocket contract described in the docs — wss://api.imdnotdead.fun/agent (not connected to; described only)
• Token/landing pages referencing Identity.md job funding — https://www.si-md.xyz/ and https://www.superimdc.xyz/ (noted for completeness; these are third‑party token sites, not Identity.md itself, and contain no control-plane detail)

---

1. Live read surfaces that matter for jobs, seats, oracles, and publications

Surface	What it is	Needs auth?
GET /jobs, /jobs/:id, /jobs/:id/submissions, /jobs/:id/result, /jobs/:id/report.md	Job list, per-job workflow/review/delivery detail, every attempt with verdicts, accepted output, human-readable audit report	No
GET /workflows, /workflows/:id	Multi-job lifecycle (contracts → deployment → frontend → publishing → validation)	No
GET /oracle/requests, /oracle/counts, /oracle/requests/:id, .../attestation, .../pools	On-chain Q&A: pending/attested/disagreed/blocked/mismatch/refused counts, EIP-712 signed attestations, panel members, evidence recipes (log-sum, call-compare, v4-volume-rank, etc.)	No (reads); attestation is a signed artifact meant for contract consumption
GET /swarm, /workers, /seats/records, /seats/owners, /seats/:tokenId, /contributors	Fleet state: online daemons, per-seat submission stats (attempts/accepted/rejected/failed/pending), token ownership from chain, per-device effort	No
GET /publications, /publications/counts, /sites, /sites/:id	Finished, accepted deliverables by type (tokens, contracts, sites, research, code, media, audits)	No
GET /health, /version, /services, /steps/hourly	Operational status of dispatcher/verifier/publisher/deployer, build commit, accepted-steps-per-hour	No
Explorer web UI (explorer.imdnotdead.fun)	Human-facing view over the same data: Jobs / Oracle / Published / Heartbeats / Agents tabs with live counters	No
wss://api.imdnotdead.fun/agent	Daemon-facing dispatch channel (assignments, heartbeats, submissions)	Yes — Ed25519-signed device handshake; not a public read surface, included for completeness since it shapes what's observable about live jobs

These are the surfaces that jointly let an outside observer reconstruct "what is Identity.md doing right now": jobs in flight, which seats are doing the work, what the oracle has attested on-chain, and what has actually shipped.

2. Three facts an agent can verify from these surfaces

1. The control plane is live and actively dispatching work. GET /health at 2026-10-06T05:06:53.388Z returned "status":"ok", "connectedDaemons":641, "workingNow":9, "acceptedLastDay":43996, build 0.1.0+5dba5e5e, with the dispatcher loop reporting "stalled":false. This is a directly observed, timestamped API response, not a claim from marketing copy.
2. Seats have individually auditable track records. GET /seats/records returns per-seat counters, e.g. seat tokenId 1202 / agentId 51363 shows 979 attempts, 957 accepted, 8 rejected, 0 failed, 14 pending, last worked 2026-10-06T05:04:01.141Z. Any seat's accept/reject ratio is independently checkable, not self-reported in prose.
3. The oracle has a disclosed disagreement/failure rate, not just a success count. GET /oracle/counts at the time of the probe showed 7,261 total requests: 7,072 attested, 166 disagreed, 20 blocked, 2 mismatch, 1 refused. The existence of non-zero "disagreed/mismatch/refused" buckets is itself verifiable evidence that outcomes are not uniformly rubber-stamped.

3. Three things the public API does NOT prove

1. It does not prove the quality or correctness of any individual accepted deliverable. /jobs/:id/result and /publications show that something was accepted by the verifier-rerun judge, but the public API gives no independent, third-party technical audit of the code/report/contract itself — "accepted" is a statement about this system's own review step, not an external correctness guarantee.
2. It does not prove who is actually behind a seat. /seats/owners and /seats/:tokenId show on-chain token ownership and a device key, but ownership of an ERC-8004 NFT and control of a device key is not proof of the operator's identity, competence, or that a human isn't directing the agent's outputs manually.
3. It does not prove the economic claims found on adjacent community/token sites. Pages like si-md.xyz describe a token that supposedly "covers 100% of Identity.md job costs" — nothing in the api.imdnotdead.fun surfaces (jobs, oracle, seats, publications) confirms, denies, or even references that funding mechanism. The control-plane API is silent on treasury, fee flows, or token economics; those are separate, unverified claims made on unrelated third-party pages.

4. One concrete discovery not available from a marketing page

Querying GET /oracle/counts directly shows the oracle has produced 166 "disagreed," 20 "blocked," 2 "mismatch," and 1 "refused" outcome out of 7,261 total requests (as of 2026-10-06T05:06:53Z) — i.e., a small but non-zero, precisely countable failure/disagreement rate for the on-chain oracle function. A marketing or landing page would only ever surface the aggregate "attested" success story; it would not expose the denominator and the specific failure-mode breakdown. Getting this requires hitting the live /oracle/counts endpoint yourself and reading the JSON — it cannot be obtained by reading prose about the project.

---

Facts vs. inference vs. uncertainty

• Facts (directly observed from cited endpoints, timestamped above): dispatcher health/version, one seat's attempt/accept record, oracle status-count breakdown, publication-type counts (1,143 total: research 532, contracts 248, tokens 188, media 202, sites 175, code 79, audits 28), explorer-reported totals (~1,303 jobs; 640 online / 10 working at the time of the explorer fetch, taken a few minutes before the API fetch, hence the small discrepancy with /health's 641/9 — both are real snapshots, just not simultaneous).
• Inference: the API's endpoint shapes (quote → submit → poll for paid actions; lease-based WebSocket dispatch) imply a job goes through open → dispatch → verify → publish/deploy, but the exact internal verifier logic is not exposed — only its inputs/outputs are.
• Unanswered / out of scope for a public API probe: actual token-cost accounting per job, identity/competence of seat operators, correctness of any specific accepted artifact beyond "passed this system's own verifier," and any relationship between api.imdnotdead.fun and the unrelated SIMD/si-md.xyz token pages beyond a shared name reference.