# FORGE audit and implementation report ## Question Can an existing site be redesigned into an ambitious but technically real IdentityMD swarm experience that coordinates research, competition, verification, execution, and evidence without pretending that an unsigned browser action is paid or verified? ## Scope and audit result The supplied repository was empty apart from metadata directories. There was no existing website, application code, dependency manifest, test suite, or deployment configuration to audit. I implemented a greenfield static-first site in index.html, styles.css, and app.js, plus native-Node server.mjs for local serving and a read-only API relay. No .git, .github, .env, or node_modules paths were touched. ## Delivered functionality FORGE is a mission-control surface, not a copy of the Explorer: - The mission composer turns an objective into a staged evidence ladder: research job.open, adversarial job.continue or a fresh job, oracle.request, fuzz/counterexample work, records, and a final workflow.open release path. - The generated plan is explicit about public reads, worker leases, verifiable outputs, and wallet-gated stages. The browser never signs, quotes, or submits a paid request. - The oracle body includes a typed boolean answer, a 24-hour window, panel size, quorum, evidence mode, validity, and a definition that missing evidence is not a positive answer. - Optional cadence produces a real schedule.create shape using an ISO 8601 interval and a frozen oracle input. - The telemetry view reads the documented public routes /health, /swarm, /jobs, /oracle/counts, and /publications/counts, then degrades visibly when the plane is unavailable. - The evidence view explains the chain from question to panel to EIP-712 attestation to hash-addressed artifact, and links back to the primary docs. - server.mjs serves the app and exposes /imd/* as a read-only same-origin relay for public GETs. It does not proxy payment credentials or implement a wallet. ## Attributable evidence ### Facts from the primary docs 1. IMD documents public routes for jobs, workflows, oracle requests, schedules, research/fuzz, workers/seats, publications, launches, records/reviews, and artifacts. The docs also state that paid routes refuse cross-origin browsers and that the explorer provides a same-origin pass-through for the paid request flow. [IMD API docs — base URLs and CORS](https://imd.fun/docs/#base-urls) [IMD API docs — explorer](https://imd.fun/docs/#explorer) 2. A job.continue is a new version of the project and is constrained to the wallet that paid for the project. [IMD API docs — continuing a project](https://imd.fun/docs/#continuing-a-project-jobcontinue) 3. A workflow covers contracts, deployment, frontend, publishing, and validation, and a workflow DAG can require an independent adversarial review before the frontend. [IMD API docs — workflows](https://imd.fun/docs/#workflows) [IMD API docs — a DAG](https://imd.fun/docs/#a-dag-with-a-named-site) 4. Oracle requests pin a question, block window, answer type, panel size, quorum, evidence mode, definitions, guards, and consumer domain; an attested request exposes EIP-712 typed data and a signature. The docs explicitly say payment buys the question and panel, not an answer, and that disagreement can end without one. [IMD API docs — oracle body](https://imd.fun/docs/#oracle-body) 5. Schedules accept either an interval or cron cadence, a run count, and an optional continue flag for jobs; only runs that actually open a question or job spend a run. [IMD API docs — schedule body](https://imd.fun/docs/#schedule-body) 6. Fuzz results are signed device envelopes, while bundles and artifacts are addressed by SHA-256 and publicly retrievable by hash. [IMD API docs — bundles and artifacts](https://imd.fun/docs/#bundles-and-artifacts) [IMD API docs — signed device calls](https://imd.fun/docs/#signed-device-calls) 7. The documented paid flow requires a quote, an x402 payment payload, and a separate EIP-712 quote approval; a quote can expire, and a rejected/invalid input is not charged. [IMD API docs — paid requests](https://imd.fun/docs/#paid-requests) [IMD API docs — quote approval](https://imd.fun/docs/#the-quote-approval) ### Inferences made - A useful maximum-potential demonstration should make handoffs and refusal states visible before it attempts a release. This is a product inference based on the documented primitives, not a claim that this static app has run a swarm mission. - A mission is represented as a graph rather than one giant prompt because the docs support multi-step jobs, DAG dependencies, continuations, oracle panels, schedules, and workflow validation. - The local relay is a convenience for public reads. It is not a paid-request relay and deliberately has no payment or signature handling. ### Uncertainty and unanswered questions - No paid request was made. No wallet, IMD balance, Permit2 allowance, EIP-712 signature, worker device key, or lease was available. - Live API reads could not be independently certified in this environment; the UI treats unavailable or rate-limited reads as OFFLINE and keeps composition usable. - Oracle signature recovery, EIP-712 domain checking, chain evidence reproduction, Merkle proofs, worker signatures, and artifact hashes are not independently verified by this frontend. The evidence panel says so explicitly. - The site does not yet submit a generated multi-step DAG job body or workflow.open draft because those require a quote and wallet authorization, and spending was not authorized. - The empty starting repository has no historical UI or code behavior against which regression claims can be made. ## Local checks - node --check app.js — passed. - node --check server.mjs — passed. - Static asset existence and required report path — passed. - Started node server.mjs and verified the root document was served over HTTP — passed. - Composer plan and cadence stage were verified by source inspection; browser execution was not available in the check profile. ## Review verdict The implementation is bounded, non-custodial, and grounded in documented IMD primitives. It demonstrates coordination and verification surfaces without fabricating a completed execution or claiming independent cryptographic verification. Quality: 8/10. The largest next step would be a wallet-enabled, explicit quote-and-submit flow with a server-side deployment policy and independent verifier for attestations and Merkle proofs. ```json {"apply":true,"quality":8,"reason":"Greenfield FORGE mission control implements a real IMD-aligned evidence ladder with job continuation, oracle panels, schedules, telemetry, workflow/release framing, and hash/attestation evidence boundaries. Paid actions are explicit and not executed; uncertainty is disclosed.","title":"FORGE / IdentityMD mission control","summary":"A static-first swarm mission composer and telemetry surface for research, adversarial review, oracle attestation, fuzzing, records, and validated release. It includes a read-only local relay, no secrets, no payment execution, and an attributable audit report.","html":"FORGE / IdentityMD mission control
FFORGE IDENTITYMD / EXPERIMENTAL
FIELD OPERATIONS / 01

Turn a hard question
into a verified release.

Compose a mission that makes the swarm research, challenge, attest, fuzz and ship in sequence. Every handoff is inspectable; every paid action stays in your hands.

Compose a mission ↓

Build the evidence ladder

Swarm telemetry

Public control-plane reads load here.

Nothing important is a black box

Question → panel → EIP-712 attestation → hash-addressed artifact.

Designed around the real plane.

Jobs, continuations, oracle panels, schedules, fuzzing, workers, records, reviews, publications and workflows.

"} ```