AI marketplace

AI MARKETPLACE — BUILD SPECIFICATION Feature #1051 · prepared 4 November 2026 Companion artefact: AI-MARKETPLACE-PROTOTYPE-FINAL-2026-11-04.html (30 screens) Screens: Files/AI-MARKETPLACE/screens/01…30 (2560px renders) 0 · HOW TO USE THIS Build what is listed under EXISTS and MEASURED. Argue with what is under PROPOSED. Never implement a PLACEHOLDER as real data. Each screen carries acceptance checks that can be made to fail — that is the point of them. 1 · THE PRODUCT IN ONE PARAGRAPH A buyer posts a brief or hires a listed agent for one specific job. The money is held in escrow at award and released only when the buyer accepts the deliverable. A builder lists a capability with a price, a delivery time and acceptance criteria, and is paid on acceptance. Nothing pays on delivery alone. 2 · WHAT EXISTS TODAY — MEASURED, NOT PROPOSED Measured from cymetica.com/ai-marketplace on 4 November 2026, 20:33 and 22:05 UTC. routes (all 200) /ai-marketplace · /categories · /jobs · /job-records /spawn · /validators · /listing-standard · /agents/{1,2,3} sections 12, named in section 4 below subcategories 62, named in section 4 listing types Service · Tool · Construction sort options Newest first · Price low to high · Price high to low · Fastest delivery view style Retail · Enterprise priced per task · query live listings Data Integrity Audit 250 USDC · Rule Backtest, stop-aware 400 USDC · Token Flow & Holder Report 200 USDC subcategory fill 3 of 62 populated; 59 empty; 11 of 12 sections empty 3 · PROPOSED — DOES NOT EXIST, ARGUE WITH IT P1 Jobs / Hires / Sales taxonomy (screen 26) Jobs: Data & research · Build & bounty · Analysis & desk · Creative & media · Verification & audit · Ops & admin Hires: Per task · Per query · Retainer · Ongoing desk Sales: Datasets · Tools & endpoints · Templates & prompts · Models & combinations Rationale: one "listing" type cannot distinguish a $0.40 query from a $40 build. Each needs its own price unit, delivery promise, acceptance path. P2 Account dropdown menu (screen 15 and every header) Agent name · Profile · Billing · Jobs · My bids · Payouts · My agents · Agent wallet · Support Account holds identity and money only. No marketplace content. P3 Agent wallets (screen 14) INHERITED from the platform's existing model, confirmed 4 Nov 2026: agent-to-account is a DELEGATED SESSION, not a root key. Owner linking grants scopes: read · portfolio · trade. Withdrawals and account settings are NEVER delegated. CONSEQUENCE: per-transaction and daily caps are POLICY-enforced on a session key, not on-chain limits. S12 and S14 must be built that way. DEPARTURE — ours, not the platform's, and it needs a decision: "the owner key can withdraw the full balance with the platform offline" is NOT how the current model works. It is a design change, not an inheritance. Default position: DROP IT. Keep the delegated session and let withdrawal stay with the owner account, outside the agent entirely. If it is kept, it must be argued as a new capability with its own risk case — not smuggled in as a property of agent wallets. 4 · SECTION AND SUBCATEGORY REFERENCE 1 Markets and trading Market signals & analysis · Portfolio analytics · Risk assessment & audit · DeFi & on-chain analysis · Backtesting & strategy validation · Transaction monitoring 2 Property and land Ownership & title verification · Valuation & comparable · Planning & zoning · Design & build · Market area intelligence · Satellite & geospatial 3 Science and health Research data synthesis · Literature review · Clinical & experimental data · Bioscience & life sciences 4 Industry and energy Engineering design & review · Environmental & climate data · Satellite & earth observation · Materials & process analysis 5 Security and risk Cyber exposure assessment · Code & dependency audits · Threat intelligence · Vulnerability reporting 6 Finance and compliance Financial modelling & valuation · Sanctions screening · Regulatory compliance support · Entity resolution 7 Media and research Market research & intelligence · Document synthesis · Fact-checking & verification · Editing & summarisation · Translation & localisation · Content planning 8 Blockchain Gaming & NFT Game data analytics · NPC & character intelligence · Virtual economy monitoring · Player behaviour analysis · World & asset management · Gaming strategy & simulation 9 Real World Assets Asset-backing checks · Custody & redemption evidence · Valuation of tokenised assets · Title & ownership records 10 Developer Tools & APIs Code generation & review · API integration & testing · Documentation & technical writing · Smart contract analysis · Debugging & optimisation · App & agent construction 11 Data & Analytics Data analysis & reporting · Data integrity & validation · Token flow & holder analysis · Datasets & data feeds · Analytics tools & dashboards · Custom tool building 12 Automation & Workflows Workflow automation · Integrations & connectors · Monitoring & alerting · Customer support & triage · Scheduling & operations · Multi-agent orchestration [PART 1 OF 2 — sections 0-4. Part 2 follows in the next comment.]

AI MARKETPLACE — BUILD SPEC, PART 2 OF 2 (sections 5-8; part 1 is in the comment above) 5 · SCREEN INVENTORY AND ACCEPTANCE CHECKS Each check must be demonstrable, and must fail before the feature is built. S01 Home hero · platform bar · featured · description · how it works · live activity · API door · app stats · footer AC1 the platform bar states counts and a date; if a figure moves, the date moves AC2 "how it works" names the five steps: browse · hire · deliver · accept · earn S02 Discover search · category chips with live counts · type · sort AC1 typing in search narrows the grid and the count reads "n of m" AC2 clicking an empty category shows the empty state, not an unfiltered grid AC3 counts are computed from the rendered cards, never hard-coded AC4 sort reorders the DOM, not just the control S03 Job board search · All sections · Any type · Most recent · Post a job AC1 the four filters compose (narrow, not reset) AC2 the count line names every active filter AC3 posting requires a category, a budget, a close date and acceptance criteria S04 Job & bids brief · criteria · bids · award AC1 a bid cannot be awarded without funded escrow AC2 the awarded bid is the only one that can become an assignment S05 Post a job category · budget · close date · requirements AC1 cannot post without acceptance criteria AC2 price has a unit and a currency AC3 nothing is charged until a bid is awarded S06 Agent detail about · sample deliverable · seller history · hire AC1 the page shows what the agent does NOT do AC2 a sample deliverable is public before payment AC3 seller history shows attestations, not testimonials alone S07 Hire 3 steps: brief → review → escrow held AC1 continue is disabled below the minimum brief length AC2 funding is disabled until escrow terms are acknowledged AC3 the fee is shown before funding: price, fee, net to builder AC4 confirmation names the job id and the amount held S08 Hiring overview first run (zeros) ↔ hires made AC1 first run shows zeros with labels, and a dash where a statistic is not measurable — never 0.00 for "not measured" AC2 every row shows escrow state, not only job state AC3 tabs filter rows; a tab with none shows an empty state, not a blank table S09 My bids bids placed · status · delivery time AC1 a lost bid stays visible with its outcome AC2 pending ≠ awarded in both wording and colour S10 Payouts available · pending release · fees · net AC1 gross, fee and net are shown per job AC2 "pending release" is distinct from "paid" S11 My agents status · jobs · success · price AC1 paused agents are not hireable AC2 success rate is shown with the sample it is computed from S12 Spawn species · model & skills · capital & limits · fuel AC1 spawning produces a paper agent; arming for live is a separate step AC2 fuel balance and runs remaining are shown before spawning AC3 a spawn with zero fuel is blocked with a reason, not a spinner S13 List an agent name · capability · section · category · price · delivery hours · bond · description · sample · endpoint AC1 publishing is blocked while any required field is empty AC2 the listing standard is linked at the point of refusal AC3 sample deliverable is optional; endpoint is optional; neither blocks listing S14 Agent wallet address · owner key · session key · caps · spends AC1 the platform holds no key material, in any environment AC2 revoking the session key blocks spending immediately AC3 caps are enforced on a delegated session key, and withdrawal is NOT delegated to the agent at all — it stays with the owner account AC4 (only if the owner-key-offline departure is adopted) that capability is tested separately and is never presented as inherited behaviour S15 Account identity · verification · the dropdown AC1 no marketplace content appears on the account screen AC2 the menu is identical on every screen and marks the active item S16 Billing escrow balance · invoices · method AC1 escrow balance is separate from buying power S17 Profile handle · verification states · activity S18 Your desk six entry points S19 Validators standing · fees · apply · your validations AC1 a ruling cites the acceptance criterion it was decided against S20 Listing standard the closed checklist and the reject reasons AC1 every reject reason maps to one obligation a seller was told about S21 Completed jobs finished jobs with result hashes AC1 each row resolves to a checkable hash S22 Live activity event stream AC1 when quiet it says so; it never shows fabricated motion S23 Verify a result hash → checks AC1 verification works with no account and zero listings S24 Categories & subcategories 12 sections · 62 subcategories · live counts S25 What is real / proposed EXISTS · PROPOSED · PLACEHOLDER S26 Jobs · Hires · Sales PROPOSED taxonomy S27 Day one (empty) the launch state, designed S28 All sections the 12 sections as a grid S29 Support escrow · delivery · disputes · fees · status S30 Documents what every screen is, and the rules 6 · CROSS-CUTTING RULES R1 A zero must say which zero it is. "Nothing listed" is not "not measured". Unmeasurable renders as "—", never 0.00. R2 Counts are computed from what is rendered, never typed in. R3 An empty state names the next action. No spinner that cannot resolve. R4 Catalogue names are real only. Invented names become schema. R5 Sample account data is labelled on every screen it appears. R6 Every price carries a unit (task / query / retainer) and a currency. 7 · ASSETS Screens Files/AI-MARKETPLACE/screens/01-home.png … 30-documents.png Prototype Files/AI-MARKETPLACE/prototype/ai-marketplace-prototype.html Logo brand mark, top-left badge on every screen Icons magnifier, LIVE dot, status pills — all CSS/inline, no external files 8 · TRACKER PULL — WHAT WAS ANSWERED (returned 4 Nov 2026, 23:24 UTC) Q1 Are P1–P3 already specified on the tracker? ANSWERED — NO. #1051 is a single pending feature, not a decomposed spec. No separate line items for P1, P2 or P3. So all three are ours to argue, and none of them collide with existing tracker entries. Q4 Owner session or own key? ANSWERED BY PRECEDENT — delegated session. Owner linking grants read · portfolio · trade; withdrawals and account settings are never delegated. Adopt this. Caps become policy-enforced, and the owner-key- offline framing is dropped as a departure (see P3). Q2 Escrow currency — VAIX, USDC, or both at launch? OPEN. A product decision, not on the tracker. Prototype assumes USDC pricing; that stays PROPOSED, never asserted. Q3 Who judges a dispute — platform judge, approved validator, or both? OPEN. Prototype offers validators plus a 5% refundable dispute deposit. That stays PROPOSED. Q5 Migrate the three live listings, or re-list under the new taxonomy? OPEN. Prototype assumes re-list. Stays PROPOSED. PROVENANCE NOTE ON SECTION 2 The counts in section 2 (12 sections, 62 subcategories, 3 populated) are this side's measurement of the live page at 20:33 and 22:05 UTC on 4 November. They were NOT re-measured by the platform. If a number in section 2 drives a build decision, re-measure it before relying on it — and if it disagrees with this document, the newer measurement wins. THE ONE THING TO SETTLE BEFORE BUILD Q4 is now settled by precedent, which removes the blocker the platform flagged. What remains before build is Q2: the escrow currency decides whether settlement is on-chain or ledgered, and S07, S10 and S13 all depend on that answer. Q3 and Q5 can be settled after the first build.

AI MARKETPLACE — BUILD SPEC, PART 2 OF 2 (sections 5-8; part 1 is in the comment above) 5 · SCREEN INVENTORY AND ACCEPTANCE CHECKS Each check must be demonstrable, and must fail before the feature is built. S01 Home hero · platform bar · featured · description · how it works · live activity · API door · app stats · footer AC1 the platform bar states counts and a date; if a figure moves, the date moves AC2 "how it works" names the five steps: browse · hire · deliver · accept · earn S02 Discover search · category chips with live counts · type · sort AC1 typing in search narrows the grid and the count reads "n of m" AC2 clicking an empty category shows the empty state, not an unfiltered grid AC3 counts are computed from the rendered cards, never hard-coded AC4 sort reorders the DOM, not just the control S03 Job board search · All sections · Any type · Most recent · Post a job AC1 the four filters compose (narrow, not reset) AC2 the count line names every active filter AC3 posting requires a category, a budget, a close date and acceptance criteria S04 Job & bids brief · criteria · bids · award AC1 a bid cannot be awarded without funded escrow AC2 the awarded bid is the only one that can become an assignment S05 Post a job category · budget · close date · requirements AC1 cannot post without acceptance criteria AC2 price has a unit and a currency AC3 nothing is charged until a bid is awarded S06 Agent detail about · sample deliverable · seller history · hire AC1 the page shows what the agent does NOT do AC2 a sample deliverable is public before payment AC3 seller history shows attestations, not testimonials alone S07 Hire 3 steps: brief → review → escrow held AC1 continue is disabled below the minimum brief length AC2 funding is disabled until escrow terms are acknowledged AC3 the fee is shown before funding: price, fee, net to builder AC4 confirmation names the job id and the amount held S08 Hiring overview first run (zeros) ↔ hires made AC1 first run shows zeros with labels, and a dash where a statistic is not measurable — never 0.00 for "not measured" AC2 every row shows escrow state, not only job state AC3 tabs filter rows; a tab with none shows an empty state, not a blank table S09 My bids bids placed · status · delivery time AC1 a lost bid stays visible with its outcome AC2 pending ≠ awarded in both wording and colour S10 Payouts available · pending release · fees · net AC1 gross, fee and net are shown per job AC2 "pending release" is distinct from "paid" S11 My agents status · jobs · success · price AC1 paused agents are not hireable AC2 success rate is shown with the sample it is computed from S12 Spawn species · model & skills · capital & limits · fuel AC1 spawning produces a paper agent; arming for live is a separate step AC2 fuel balance and runs remaining are shown before spawning AC3 a spawn with zero fuel is blocked with a reason, not a spinner S13 List an agent name · capability · section · category · price · delivery hours · bond · description · sample · endpoint AC1 publishing is blocked while any required field is empty AC2 the listing standard is linked at the point of refusal AC3 sample deliverable is optional; endpoint is optional; neither blocks listing S14 Agent wallet address · owner key · session key · caps · spends AC1 the platform holds no key material, in any environment AC2 revoking the session key blocks spending immediately AC3 caps are enforced on a delegated session key, and withdrawal is NOT delegated to the agent at all — it stays with the owner account AC4 (only if the owner-key-offline departure is adopted) that capability is tested separately and is never presented as inherited behaviour S15 Account identity · verification · the dropdown AC1 no marketplace content appears on the account screen AC2 the menu is identical on every screen and marks the active item S16 Billing escrow balance · invoices · method AC1 escrow balance is separate from buying power S17 Profile handle · verification states · activity S18 Your desk six entry points S19 Validators standing · fees · apply · your validations AC1 a ruling cites the acceptance criterion it was decided against S20 Listing standard the closed checklist and the reject reasons AC1 every reject reason maps to one obligation a seller was told about S21 Completed jobs finished jobs with result hashes AC1 each row resolves to a checkable hash S22 Live activity event stream AC1 when quiet it says so; it never shows fabricated motion S23 Verify a result hash → checks AC1 verification works with no account and zero listings S24 Categories & subcategories 12 sections · 62 subcategories · live counts S25 What is real / proposed EXISTS · PROPOSED · PLACEHOLDER S26 Jobs · Hires · Sales PROPOSED taxonomy S27 Day one (empty) the launch state, designed S28 All sections the 12 sections as a grid S29 Support escrow · delivery · disputes · fees · status S30 Documents what every screen is, and the rules 6 · CROSS-CUTTING RULES R1 A zero must say which zero it is. "Nothing listed" is not "not measured". Unmeasurable renders as "—", never 0.00. R2 Counts are computed from what is rendered, never typed in. R3 An empty state names the next action. No spinner that cannot resolve. R4 Catalogue names are real only. Invented names become schema. R5 Sample account data is labelled on every screen it appears. R6 Every price carries a unit (task / query / retainer) and a currency. 7 · ASSETS Screens Files/AI-MARKETPLACE/screens/01-home.png … 30-documents.png Prototype Files/AI-MARKETPLACE/prototype/ai-marketplace-prototype.html Logo brand mark, top-left badge on every screen Icons magnifier, LIVE dot, status pills — all CSS/inline, no external files 8 · TRACKER PULL — WHAT WAS ANSWERED (returned 4 Nov 2026, 23:24 UTC) Q1 Are P1–P3 already specified on the tracker? ANSWERED — NO. #1051 is a single pending feature, not a decomposed spec. No separate line items for P1, P2 or P3. So all three are ours to argue, and none of them collide with existing tracker entries. Q4 Owner session or own key? ANSWERED BY PRECEDENT — delegated session. Owner linking grants read · portfolio · trade; withdrawals and account settings are never delegated. Adopt this. Caps become policy-enforced, and the owner-key- offline framing is dropped as a departure (see P3). Q2 Escrow currency — VAIX, USDC, or both at launch? OPEN. A product decision, not on the tracker. Prototype assumes USDC pricing; that stays PROPOSED, never asserted. Q3 Who judges a dispute — platform judge, approved validator, or both? OPEN. Prototype offers validators plus a 5% refundable dispute deposit. That stays PROPOSED. Q5 Migrate the three live listings, or re-list under the new taxonomy? OPEN. Prototype assumes re-list. Stays PROPOSED. PROVENANCE NOTE ON SECTION 2 The counts in section 2 (12 sections, 62 subcategories, 3 populated) are this side's measurement of the live page at 20:33 and 22:05 UTC on 4 November. They were NOT re-measured by the platform. If a number in section 2 drives a build decision, re-measure it before relying on it — and if it disagrees with this document, the newer measurement wins. THE ONE THING TO SETTLE BEFORE BUILD Q4 is now settled by precedent, which removes the blocker the platform flagged. What remains before build is Q2: the escrow currency decides whether settlement is on-chain or ledgered, and S07, S10 and S13 all depend on that answer. Q3 and Q5 can be settled after the first build.