Vantemio Market: agents and decision governance

Revision 2026-10-16 · Public technical specification · In development

1. Purpose and current status

This document describes the agent layer for Vantemio Market on Boson Protocol. It complements the Market specification and Core and Studio documentation. Market agents assess evidence and assist commerce workflows; Station remains responsible for admitting Studio production jobs.

Source checks establish implementation details; they do not establish a publicly available autonomous marketplace, mainnet readiness, an independent security audit or the quality of a particular model. Functional roles below describe the intended separation of responsibilities, not a claim that a separate production agent is deployed for every role.

2. Roles and authority

Models are replaceable behind the existing adapter boundary. A model name, confidence score or working endpoint does not establish task suitability. Qualification must cover the actual language, product category and decision task.

3. From evidence to an applied decision

The required flow is: identify the tenant and subject revision → collect permitted evidence → record policy/model versions → produce a structured recommendation → verify the evidence and applicable authority → apply or escalate the decision → record the actual outcome → allow review where applicable.

The current recommendation schema distinguishes approve, reject and needs_review. Governance records separately represent enforced, blocked or escalated. A validated record is not by itself proof that an authorized consumer applied a decision. A hash-shaped evidence reference is not proof that the referenced bytes were retrieved or assessed.

An acceptable decision record binds the subject and tenant, input and evidence hashes, recommendation, policy and model versions, decision time, authorized action, actual outcome and any preceding decision under appeal. Conflicting or incomplete evidence requires escalation rather than an invented success. The integration must reject cross-tenant, stale-subject and incompatible-policy substitutions.

4. Smart contracts and signing

AI inference, private material and detailed review remain off-chain. Contracts and protocol events provide the applicable transaction states and commitments. A recorded hash demonstrates a binding to bytes; it does not establish ownership, factual accuracy or artistic quality.

Boson's agent documentation separates transaction preparation, signing and broadcast. Vantemio must verify the exact action and authority at each applicable boundary. Boson signing pattern.

The inspected Vantemio testnet commerce guard checks actor/method permissions, chain and target, calldata, implementation binding, nonce, expiry and distinct registered signers; it rechecks authorization before broadcast. Those checks are specific source behavior. Multiple signatures do not by themselves prove independent organizational control, independent AI judgment or permission for a different action. Production authorization remains subject to separate release acceptance.

5. Moderation, appeals and purchase disputes

A listing restriction, an appeal against a moderation decision and a purchase dispute are different procedures. An appeal must identify the decision, contested evidence and requested correction. The required outcome records reasons, policy revision and whether restrictions are upheld, changed or reversed; earlier records remain available to authorized reviewers.

Boson defines separate exchange and dispute states. Exchange lifecycle, dispute lifecycle.

A support request or AI review does not suspend protocol deadlines or replace the designated participant/resolver. The active offer and deployed protocol determine available remedies. Agents must surface relevant deadlines and uncertainty. A customer must not be told that an appeal has automatically stopped settlement. Full appeal-to-enforcement integration is still an acceptance requirement.

6. Privacy and adversarial inputs

Product descriptions, uploaded files, retrieved pages and model output are untrusted data. Instructions inside them must not grant privileges, change policy, trigger signing or expose another buyer's files. Marker filtering is a supporting check, not a complete prompt-injection defense.

The integration requires tenant and order access checks, bounded retrieval, permitted providers and minimal disclosure. Keys, credentials, raw customer files and personal information must not enter public metadata or on-chain evidence. Hashes are integrity references, not a guarantee of anonymity. Private evidence must remain accessible only for its authorized purpose and retention period.

7. Failures, recovery and repeat execution

The required operation identity survives restarts. A timeout after dispatch is an unknown outcome until receipts, transaction state and the operation journal are reconciled. Reuse an accepted result rather than creating a second purchase, enforcement action, access grant or render. Boson also documents state reconciliation before retrying writes. Idempotency and retry.

Model unavailability, invalid structured output, conflicting reviewers and expired authorization need explicit outcomes. Recovery uses the original subject and operation identity; new policy or evidence creates a recorded revision. Commerce state, moderation state, delivery access and Studio job state must not be collapsed into one success flag.

8. Release acceptance

Acceptance requires an actual authorized consumer and a redacted record of its result: valid and rejected listings; changed seller evidence; a modified delivery package; foreign-tenant access; adversarial instructions; unsupported policy; model failure; conflicting review; expired authorization; interrupted dispatch; duplicate event; upheld appeal and reversal. Transaction tests must use the intended test environment and distinguish isolated verification from operational results.

The release record identifies source and policy revisions, deployed configuration, model/task qualification, observed outcomes and remaining limits. Security review, load capacity, mainnet deployment and legal approval are separate claims requiring their own evidence.

9. Commerce engine for customer-operated stores

Vantemio is developing its own marketplace and, alongside it, a reusable commerce engine with agents that customers can purchase or license to open and operate their own stores. Selling software for customer stores is a separate product direction from selling goods and services through Vantemio’s marketplace. The target is a repeatable software product with documented interfaces, installation, configuration and updates.

The product uses one shared commerce engine. Vantemio will operate its own separate store on that engine and supply the same software to other developers for their stores. These are deployments of the same engine, with separate store configuration, operators and data. Suitable official Boson and OpenZeppelin components may be reused or adapted through the existing interfaces, with version, licence and security checks. The product does not require rewriting established libraries from scratch.

The planned structure comprises a branded storefront; catalogue, offers and inventory; customer and seller accounts; orders and delivery; agent-assisted moderation, recommendations and appeals; payment and protocol adapters; and an operator console with access control and an operation history. These modules describe the target product composition. Availability is established for each accepted release, not inferred from this list. Agent roles and payment authority retain the boundaries described above.

A customer-operated store must separate its catalogue, orders, policies, credentials and private evidence from other stores. Shared hosting and a dedicated installation require their own isolation and recovery acceptance. Purchasing the engine does not enrol a store in Vantemio’s public catalogue, transfer customer content to other stores, or authorise agents to sign payments. Connections to the public marketplace are separately configured and authorised.

Planned monetisation covers commercial software licences, deployment and integration, updates and support. A hosted service can be offered as a separate delivery package after acceptance. Licence scope, branding rights, included modules, support and update terms, hosting costs and any transaction fees must be stated in the applicable offer. No licence price, subscription rate or marketplace fee is fixed by this document. A licence to Vantemio software does not automatically grant rights to third-party models, components or content.

Customer payments for Vantemio software and store-engine licences, goods and services in its marketplace or stores using the engine, and donations are exclusively in cryptocurrency. The product scope includes no fiat payment processing or built-in fiat-conversion or cash-out service. Any external exchange or withdrawal to fiat is the user’s independent action outside Vantemio. The applicable offer identifies supported networks and tokens, the amount and fees, the recipient and payment-confirmation conditions.

Before offering a package for sale, acceptance must demonstrate a store from installation to catalogue, permitted order, delivery, agent decision and review, update, backup and recovery. Release documentation identifies supported modules, dependencies, data handling, customer responsibilities and known limits. The own marketplace and the distributable store engine remain in development; this direction does not announce a ready-to-buy package or production payment access.

10. Revision evidence and related documents

The implementation basis inspected on 16 October 2026 includes governance validation and the testnet commerce guard. Source SHA-256: ai-governance.mjs — 8f365f2e69b5905345ba10d20e028402605e1c811ca0998653f2a964a295553b; commerce-policy.mjs — ca394da54bc9dd2b92a250c23a132a797021d5f0cfb9c03fbb3615333baa1ed5. These identify inspected bytes, not a deployed release or a completed audit.

Market · Technical documentation · Whitepaper · Roadmap · Privacy · Terms