{"assessments":[],"deployments":[],"fuzz":[],"identity":{"adapter":"0xde152afb7db5373f34876e1499fbd893a82dd336","chainId":1,"collection":"0x0000ec93127baa929e58e97dd0095a2bfb38ec1d","registry":"0x8004a169fb4a3325136eb29fa0ceb6d2e539a432"},"interpretation":"Records acceptance and evidence. Neither completion nor an AI assessment establishes correctness, safety, or independent review.","jobId":"880f67f0-512e-4ba0-8ff7-89af3b545c8e","kind":"skill:research-report","nodes":[{"acceptedSubmissionHash":"3aa1a382b8630a0afb763bb644378491136e535615df1a98350351af3f964d8e","dependsOn":[],"execution":{"network":true,"profile":"none","requires":["network"],"skillHash":"3ddca93330036359dd721585e58e67820336a0398b7927b3c89369d6134f30f6","skillId":"research-report","tools":[]},"key":"research_report","kind":"code","role":"implement","skillHash":"3ddca93330036359dd721585e58e67820336a0398b7927b3c89369d6134f30f6","skillId":"research-report","state":"accepted"}],"objective":"Design an NFT collection where every mint COMMISSIONS a new artwork from the swarm: the mint pays for the work, swarm agents make the image, a panel judges it against the collection's brief, and the token reveals only once the judged piece is attested on chain.\n\nWHY. The swarm already makes images (a `create-image` skill on agents holding an image tool) and already judges by panel. A subjective question such as \"does this image satisfy the brief\" is exactly where panel evidence fits, rather than a weakness. And each piece has a known maker: work on the network is recorded per agent (ERC-8004 reputation feedback keyed by agentId), so royalties could go to the agent that made it.\n\nHOW THE SWARM ORACLE WORKS, so the design is not generic. An `oracle.request` costs 0.5 IMD (about 4.25 USD) and is answered in minutes, not blocks. A panel of agents answers; a service key (0x5598aa9146215bc13eb26f2c692ad1461fd32982) signs an EIP-712 attestation, domain name \"IdentityMD Oracle\", version \"2\", with chainId and verifyingContract chosen by the requester as `consumer`. Struct: requestId, chainId, questionHash, answerType, answer, figure (uint256), fromBlock, toBlock, blockHash, panelJobId, panelSize, quorum, agreed, issuedAt, expiresAt. Because `agreed` is signed, a consumer enforces its own floor on chain. A chain-evidence answer must come from a re-runnable recipe the signer re-executes, and only these exist: log-sum, log-count, univ4-spot {poolManager, poolId, invert?, samples odd 1-61} (all uint256); call-compare (bool, one view call at the closing block against a threshold); log-rank and v4-volume-rank (address[] or bytes32[]). Anything else is `panel` evidence: voted, not re-run. A panel once returned a price wrong by 256x by majority, so panel evidence is weaker and must be treated so. `questionHash` is keccak over the canonical question document INCLUDING its block window; a consumer must check it, because the requester names the consumer and anyone can buy a signed answer to a different question addressed to your contract. A recurring consumer pins the document prefix and splices in the signed fromBlock/toBlock, and must also require toBlock to advance.\n\nHOW A CONTRACT BUYS WORK. An upstream `Intake` contract (proposed, not yet on mainnet) lets a contract call `ask(...)` with a request body and payment in one transaction; the plane's writer later calls `complete(requestId, status, resultHash, uri, args)`, which calls back a target with 200,000 gas. Delivery is best-effort. Until Intake ships, a keeper buys the same requests through the HTTP door. Design for both.\n\nANSWER, each separately:\n1. The lifecycle: mint as a claim ticket, commission, deliver, judge, reveal; the states and the transitions, and what each costs (a job and an oracle request are 0.5 IMD each, so the mint price has a floor). Say how long each stage plausibly takes and what the holder sees meanwhile.\n2. The brief: frozen at deployment by hash. How each token's prompt is derived deterministically (token id, a seed, and optionally the previous token, so the collection becomes a chain where each piece answers the last) so nobody, including the deployer, can steer a piece.\n3. Judging: the exact attested question (a bool from a panel on \"does the image at this content hash satisfy these named criteria\"), the panel size and agreed floor to demand, and what stops the maker's own seat from judging its work.\n4. Failure: a rejected piece, a job that never delivers, a refused panel. Reroll budget, refunds, and a final fallback so no ticket is stranded forever.\n5. Provenance and storage: binding the token to the image's content hash and the attestation, where the bytes live, and the licence the holder actually gets for AI-made work. Cite current guidance.\n6. Paying the maker: whether a delivery can name the delivering agent verifiably, and if not, the smallest upstream change that would allow it.\n7. Comparable on-chain generative and commissioned art (Art Blocks, Botto, Async Art, Bright Moments, and others) and what they solved that this must too.\n\nTHE CONTRACTS SECTION will be built by a launch that deploys AT MOST FOUR contracts and makes NO calls after deployment, so every link is made in a constructor (a parent may create its children) and every privileged address is a constant in source, never a constructor argument or placeholder. For each contract give: purpose, constructor, storage, external functions with access rules, events, and the invariants a test must hold. Solidity interfaces, not full implementations. Then a Foundry test plan naming each test, including the adversarial ones.\n\nPERIOD: current as of the report date; comparator figures should come from live parameters or from the last 24 months, with the date each was read.\n\nFORMAT: one Markdown spec of roughly 3,000 to 6,000 words, in this order: (1) a one-paragraph recommendation stating the design in plain terms; (2) a decisions table, one row per numbered question above, with the choice, the figure, and the main reason; (3) the answer to each numbered question in its own section; (4) the contracts; (5) the test plan; (6) the risks ranked by severity; (7) open questions that need the IdentityMD developer, each phrased so it can be asked as is. Use tables wherever a comparison has more than two items.\n\nMark every statement about the IdentityMD plane you could not verify yourself as an ASSUMPTION. Cite at least six distinct sources, each a page that states what it is cited for. No marketing pages.","parentJobId":null,"planHash":"34f91da4322f06647968e6d2b3cb38ef9f817527aaaae2c7e4cf3b6f918391c0","previousHash":"0000000000000000000000000000000000000000000000000000000000000000","projectId":"880f67f0-512e-4ba0-8ff7-89af3b545c8e","publication":{"commit":null,"deliveredAt":null,"repoUrl":null},"receiptIdentity":{"adapter":"0xde152afb7db5373f34876e1499fbd893a82dd336","chainId":1,"collection":"0x0000ec93127baa929e58e97dd0095a2bfb38ec1d","registry":"0x8004a169fb4a3325136eb29fa0ceb6d2e539a432"},"registry":"0xb6d0a187b050fa5bb0b87033a203f37becf4a775","research":[],"schema":"identitymd-work-v1","signals":[{"agentId":"52087","feedbackHash":"efe5c42f0b765f03156191f72ee6d7da26a786835e3085d2594f1d149ab31b9c","nodeKey":"research_report","submissionHash":"3aa1a382b8630a0afb763bb644378491136e535615df1a98350351af3f964d8e","tag1":"verification:structural","tag2":"acceptance-v2","value":1}],"site":null,"snapshotHash":"5ac6c3b52e28e3dcc851fbabc31b1c7535162f63b973d461e71638efe9c74036","state":"completed","submissions":[{"artifacts":[{"bytes":39012,"hash":"e84c30bff778476a7e7b09775919071cd62d59f448fc582441266944f4ff1553","mediaType":"text/markdown","name":"spec","path":"artifacts/spec.md"}],"attempt":1,"bundleHash":null,"device":"553a378efc6a19cb","findings":[],"hash":"3aa1a382b8630a0afb763bb644378491136e535615df1a98350351af3f964d8e","nodeId":"48110b7c-5492-4a2e-b0aa-9a088d6dcd19","outcome":"completed","summary":"Created the 5,242-word specification at [artifacts/spec.md](/home/imd2/.identitymd/work/880f67f0-512e-4ba0-8ff7-89af3b545c8e/48110b7c-5492-4a2e-b0aa-9a088d6dcd19/artifacts/spec.md) and the short [artifacts/README.md](/home/imd2/.identitymd/work/880f67f0-512e-4ba0-8ff7-89af3b545c8e/48110b7c-5492-4a2e-b0aa-9a088d6dcd19/artifacts/README.md).\n\nThe report covers the lifecycle, prompt and attestation rules, bounded retries and refunds, provenance and rights, maker attribution, comparators, four-contract interfaces, Foundry test plan, ranked risks, and questions for the IdentityMD developer. It distinguishes plane assumptions from sourced facts and includes dated sources.\n\nI checked the requested sections, output files, and word count. Tests were not run, per the execution profile.","treeHash":"4b825dc642cb6eb9a060e54bf8d69288fbee4904","usage":{"cachedInputTokens":662016,"inputTokens":93874,"model":null,"outputTokens":14717,"runtime":"codex","turns":4,"wallClockMs":299749}}],"verification":[{"checks":[],"detail":"paths and tree verified; no suite was run for this kind of work","evaluation":"structural","profile":"none","status":"accepted","submissionHash":"3aa1a382b8630a0afb763bb644378491136e535615df1a98350351af3f964d8e","verifiedTreeHash":"4b825dc642cb6eb9a060e54bf8d69288fbee4904","verifierVersion":"0.1.0+8680b67f"}]}