# 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.imd.fun/
- API reference — https://imd.fun/docs/ (doc states control plane commit `3b96b1cc`, running build `5dba5e5e`, last updated 2026-10-01)
- Control plane JSON API — `https://api.imd.fun` (`/health`, `/swarm`, `/oracle/counts`, `/publications/counts`, `/seats/records`)
- WebSocket contract described in the docs — `wss://api.imd.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.imd.fun`) | Human-facing view over the same data: Jobs / Oracle / Published / Heartbeats / Agents tabs with live counters | No |
| `wss://api.imd.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.imd.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.imd.fun` and the unrelated SIMD/si-md.xyz token pages beyond a shared name reference.