AI Orderability · The structured outcome an agent can act on · canonical text v1.2
AIO-10060 defines the structured orderability outcome: whether a specified product may be ordered for a specified client category in a specified market, under a named immutable rule revision, on evidence the outcome names element by element. The producing node signs the outcome under the record contract; the receipt of the read is signed separately. An outcome carries one clearance signal from the ACM-68000 vocabulary and the scope, conditions, exclusions tested, assessments and documents required and evidence gaps around it. It speaks about a product and a category, never an individual; it is not permission, not a venue and not an order. Missing evidence is reported as a gap, never as a finding. AIO makes the orderability question answerable in a form an agent can act on and a reader can verify.
AIO-10060 (AI Orderability) defines the structured outcome an artificial-intelligence (AI) agent can act on: whether a specified product may be ordered for a specified client category in a specified market, under a named rule revision, on evidence the outcome names. Its central object is the orderability outcome. The outcome answers one question, in four parts: which product, which client category, which market, which revision. It answers nothing else.
AI Orderability is the only expansion of AIO. The word is orderability, not suitability and not advice: an outcome speaks about a product and a category of client under a market's rules, never about an individual.
Every outcome published under AIO-10060 makes the same four promises.
Scope. The outcome names its product by the product's own record, its client category by the market's own classification, its market by the deployed market value, and its rule by an immutable ACM-68000 (Agent Clearance Manifest) revision. An outcome with an unnamed part is not an outcome.
Basis. Every element of the outcome — each condition, each exclusion tested, each assessment or document required — references the chapter field instance or product-record field it rests on. An element without a basis is not written.
Signal. The outcome carries one clearance signal from the ACM-68000 vocabulary and adds no signal of its own. The structure around the signal is AIO's; the meaning of the signal is ACM's.
Gaps. Where the evidence does not reach a conclusion, the outcome says so, lists the evidence it lacked and the pages it checked, and stops. A not-determinable outcome carries no signal: the signal field is absent and evidence_gaps[] is not empty. A gap is reported as a gap. It is never closed by assumption, and no signal is invented to stand for it.
The outcome. AIO owns the shape of the answer to the orderability question: its four-part scope, its basis references, its conditions, its exclusions tested, its assessments and documents required, its evidence gaps and its single ACM signal. No other standard defines that object.
The orderability section of the chapter. AIO owns the catalogue of fields a market chapter must carry for outcomes to be produced in that market (the Appendix C catalogue of SM-ECO-10060): product scope, client categories, target market, negative target market, distribution conditions, required assessments, product documentation, manufacturer and distributor roles, review triggers, evidence requirements, exceptions, the orderability profile reference, and manufacturer evidence accepted — for each required item, whether the regime names the manufacturer's target market statement as the evidence a distributor may rely on, cited to the provision (Appendix C 0.2). The chapter holds the values; AIO defines what they mean.
The client category. AIO owns the rule that the client is always a category from the market's own classification with source-backed qualification criteria, never an individual, and that the same product may carry different outcomes for different categories in the same market.
The conditions. AIO owns the representation of a conditional outcome: each condition names the rule element it comes from, the party it falls on and the evidence that would discharge it. A condition without an owner or a discharge is a gap, not a condition.
The review. AIO owns the rule that an outcome names the review triggers and periodic review conditions the rules impose, so that a reader knows when an outcome must be produced again. An outcome never names its own expiry from memory.
A target market statement is the manufacturer's statement of who a product is for and who it is not for, filed against the product's International Securities Identification Number (ISIN). It is one of the items the orderability section already names as required — the target market, the negative target market, the product scope statement, the product documentation and the required assessments — supplied by the party the regime places it on, the manufacturer. AIO owns its shape; the door that files and serves it is not a standard.
One statement per ISIN per manufacturer per version. A statement is immutable once filed; a change is a new version with a supersedes link; earlier versions stay published for the outcomes that cite them.
| Field | Meaning |
|---|---|
subject | the ISIN; resolved through the apex index to the record and its home node |
manufacturer | the manufacturer's Legal Entity Identifier (LEI) and name as on the LEI record |
version · filed_at · supersedes | integer version, filing time (UTC), the version it replaces |
markets | the markets the statement speaks for, each by its chapter; a statement may name one or many |
positive_target_market | per market, in the regime's own category words: the client categories; knowledge and experience; ability to bear loss; risk tolerance; objectives and needs — the European MiFID Template (EMT) field groups, carried as the manufacturer states them |
negative_target_market | per market, the categories and profiles the product is not for, in the regime's words |
distribution_strategy | execution-only · with appropriateness · advised · portfolio management — as the regime names them |
product_scope_statement | the manufacturer's statement of what the product is, by instrument class, mapped to the scope bridge term |
documentation | the product documents the regime requires (key information document, prospectus, factsheet) — URL, document date, hash at filing |
assessments | the assessments the manufacturer states it performed (product approval, scenario analysis, charging structure review) — named, dated, not attached |
source | where the statement came from: an EMT file (its version and hash) or a direct filing |
sig · kid | the manufacturer's signature over the canonical statement and the key id it was made with (the signature rule below) |
node_sig | the home node's signature over the stored statement, under its record key, as for any record |
Nothing inferred. A statement carries what the manufacturer filed, in the manufacturer's words. Its shape, the manufacturer's identity and the signature are validated; its content is the manufacturer's representation and is served as such, never judged.
The manufacturer's signature. Every statement carries the manufacturer's signature over its canonical form and the key id it was made with, made in one of two ways: under a filer identity bound to the manufacturer's LEI, issued after the manufacturer has shown control of the issuer domain on the product's record, with the filer id inside the signed payload; or under a key the manufacturer holds and publishes at its own domain's /.well-known/jwks.json. Either signature verifies offline against a published key, without asking the operator. A statement whose signature does not verify is not stored.
The node's signature. The home node of the ISIN stores the statement and signs it again under its record key (node_sig), following the ECO-10060 content contract. A statement for a subject listed on two nodes is stored at each, each under its own key; nothing is joined across borders.
A filing against a subject whose record the manufacturer's LEI does not issue is refused. A filing never overwrites; it supersedes.
A condition on an outcome is discharged by a target market statement only where the chapter's orderability section field manufacturer evidence accepted records, for the required item the condition concerns, that the regime names the manufacturer's statement as the evidence that discharges it, cited to the provision. Otherwise the condition stays firm-held: where a statement is on file it is shown on the outcome as present, not as discharging.
A statement never clears or blocks. It discharges conditions on an outcome that is already ACM-200; the clearance signal, and the rule that blocking is scope only, are unchanged.
An outcome that read a statement names the statement version, the manufacturer's key id and the filing receipt id, so the trace runs receipt → outcome → statement version → manufacturer signature → source file where there is one.
Review trigger: a new statement version for the subject. review_triggers[] carries it on every outcome that read a statement or could have.
The producing node reads the statement from its own store at outcome time, never from the manufacturer's site.
The status words. For each required item the chapter lists on the distributor, an outcome carries one status, read from the asked market's field manufacturer evidence accepted and the statement on file at the subject's home node: "discharged by manufacturer statement v<N>, filed <date>, key <kid>" with the statement's filing receipt id, where the field records the item as accepted; "present, firm-held" where it records the item as PARTIAL; "firm-held" with the field's own status word where it records the item as silent, not accepted or not found; "firm-held, no statement" on every item where no statement is on file.
The PARTIAL rule. Where the field records an item as PARTIAL, the outcome carries both quotes side by side: the regulator's sentence or sentences as the field holds them, and the statement's own value for the item. Nothing is reconciled between them; the firm holds the item.
The no-signal-change rule. A statement never changes the clearance signal (ACM-200, ACM-403, ACM-404, ACM-451) or the absence of one: the discharge is carried beside the signal, never into it. A subject listed in more than one market: the statement on file at its home node applies in every market it is listed; the field of the market being asked decides each status.
Names, types and meaning only. Proposals for review, not populated outcomes or a declaration of deployed field support.
| Field | Type | Meaning |
|---|---|---|
schema_version | string | Outcome schema version |
outcome_id | string | Stable identity of this outcome |
subject | reference | Product record version the outcome speaks about |
subject_type | string | Product or instrument category of the subject |
market | string | Deployed receipt-market value |
client_category | reference | Client classification from the chapter's client_categories[] |
rule_version | string | Immutable ACM-68000 revision applied |
section_ref | reference | Exact chapter orderability-section version read |
signal | string | One ACM-68000 clearance signal; no other vocabulary |
conditions[] | array of object | Rule element, party it falls on, evidence that discharges it — which may be a target market statement version where the chapter accepts it (§7) — basis reference |
exclusions_tested[] | array of object | Negative target-market and distribution exclusions tested, with result and basis |
assessments_required[] | array of object | Assessments the rules require before an order, with trigger and party |
documents_required[] | array of object | Product, risk and target-market documents required, with basis |
evidence_gaps[] | array of object | Evidence the outcome lacked, pages checked, reason |
review_triggers[] | array of object | Events and periods after which the outcome must be produced again, including a new target market statement version (§7) |
statement_ref | reference | The target market statement version read — subject, manufacturer LEI, version, kid and filing receipt id — where one is on file; absent otherwise |
as_of | date | Date for which the outcome speaks |
produced_at | datetime (UTC) | Time this outcome was produced |
node | string | Producing node, inside the signed payload |
proof | object | ECO signature profile; no new signing scheme |
Every basis reference names a field instance in the SM-ECO-10060 7.2 shape — the chapter section's own field with its source_url, source_date and read_at — or a field of the product record. The outcome copies no value out of its basis; it points at it.
| Signal | What the outcome says |
|---|---|
ACM-200 | The rules as evidenced permit the product for the client category in the market, subject to any conditions[] listed |
ACM-403 | The rules as evidenced restrict or halt the product for the client category in the market; the restricting element is in the basis |
ACM-404 | The product, category or required register entry is not on the register the rules name; pages checked are listed |
ACM-451 | The rules require the reader to read a named filing or document before any conclusion; the filing is referenced |
The signal's meaning is ACM-68000's and is not restated here. AIO adds the scope, the conditions, the exclusions, the gaps and the review triggers around it. An outcome that reaches no conclusion carries none of the four: its signal field is absent, its evidence_gaps[] names what was lacking and the pages checked, and a surface renders it as not determinable. The four signals are the whole vocabulary; there is no fifth.
The orderability door: getorderability.ai — https://mcp.getorderability.ai/mcp, the same router as mcp.getissuer.ai, routing get_orderability by subject to the node that holds it.
Outcomes are produced on each market node's own door by the tool get_orderability(subject, client_category) — for Canada https://mcp.ca-cm-kg.ai/mcp; the roster mcp.getissuer.ai/nodes.json names every node's door. The apex mcp.getissuer.ai/mcp routes the same call by subject to the node that holds it.
The market is the door's own; the client category is one the market's chapter names in client_categories[]; the rule is the market's current ACM-68000 register revision. Each outcome is signed by the producing node (kid allooloo-eco-2026-10) and each read is receipted at mcp.rco-records.ai, the node as writer.