The DAP Standard

Dartmouth Advisory Partners classification standard

Version 2026.2

Version:          2026.2
Status:           published for review
Published:        28 August 2026, for review
Document code:    DAP-STD-2026.2
Supersedes:       2026.1 (additive, no code moves, no forward map required)
Owner:            Dartmouth Advisory Partners, Toronto, Canada
Schema licence:   DAP Standard Public Licence 1.0 (LICENCE-schema.md)
Corpus licence:   DAP Standard Corpus Licence 1.0 (LICENCE-corpus.md), separate
Machine artifact: dap-standard-2026.2-taxonomy.json
Canonical URL:    https://dap.solutions/standard

Copyright and marks

Copyright (c) 2026 Dartmouth Advisory Partners. All rights reserved except as granted under the DAP Standard Public Licence 1.0.

DAP Standard and Dartmouth Advisory Partners are trademarks of Dartmouth Advisory Partners. The marks are reserved and are not licensed under the DAP Standard Public Licence. You may cite the Standard by name. You may state that your work conforms to it. You may not use the marks to brand your own product or to imply endorsement. See section 7 of the licence.

Licence in brief

The schema is free to use, including commercially, including by competitors, with attribution. You may implement it, extend it privately in the reserved X- namespace, and build products on it without royalty or permission. You may not publish a modified version of it as a standard under any name. The classification records produced using the Standard, the DAP Standard Corpus, are a separate asset under a separate licence and no rights in them are granted here. Full terms: LICENCE-schema.md.

How to cite

DAP Standard 2026.2. Dartmouth Advisory Partners. https://dap.solutions/standard

Classified under the DAP Standard 2026.2.

In machine-readable output, record the version in the std_version field of the ingestion record. That satisfies the attribution condition.

Authorship record

Authored by Dartmouth Advisory Partners, Toronto, Canada. First published 28 August 2026, for review. Designed from first principles as original intellectual property. Coverage of traditional economic activity was checked for completeness against public-domain government activity concepts only. No proprietary commercial classification system was used as a source, structure, or mapping reference at any point in its design. The design rationale, the six named assumptions the design rests on, and the governance process are set out in Parts 1 and 7.

Not investment advice

The DAP Standard is a classification system. A classification is a description of what an entity is, produced by applying the Standard to facts as understood at the time of assignment. It is not investment advice, not a recommendation, not a valuation, and not a statement about the merit, risk, or suitability of any entity. Classifications change as facts change and as the Standard is revised. See sections 9 and 10 of the licence.

---

Revision history

Version	Class	Summary
2026.1	Initial release	First publication. Six orthogonal layers, seven entity types, 16 domains, 63 sectors, 222 segments, Modules A to D, 19 worked examples, five named assumptions.
2026.2	Minor, additive	Changeset 01, compute derivatives, with Changeset 02 (assumption A6 break clause) folded in before publication. Adds entity type E-DERIV; segment K.04.05, traded compute capacity; Module E, derivative and reference-contract framework; rule C.6, derivative placement; the reserved leaf Z.00.00; theme T-COMPUTEMKT; risk tags R-BASIS, R-CCP, R-BENCHREF; a derivative geography rule at D.2; ingestion field deriv_attrs; named assumption A6. Refines the definition of M.07.02. Adds worked examples 20 to 22. Corrects the 2026.1 header, which read "adopted, living" against a standard that had not been reviewed, tested, or signed off, to "published for review", and adds section 7.5 to state that plainly.

Shape of 2026.2. 16 domains, 63 sectors, 223 segments, 8 entity types, 41 asset forms, 18 themes, 25 risk, governance and policy tags, Modules A to E, 22 worked examples, 6 named assumptions.

Continuity. No code issued in 2026.1 has moved, retired, or changed meaning. No forward map is required. Every classification made under 2026.1 remains valid and readable under 2026.2. Entity type is the pre-classification switch and not one of the six layers, so the addition of an eighth type changes no layer definition.

Trigger for changeset 01. On 11 August 2026, CME Group and Silicon Data announced two cash-settled Compute futures contracts, Silicon Data H100 Rental Index Futures and Silicon Data B200 Rental Index Futures, for listing under NYMEX rules on 5 October 2026, pending regulatory review. Attempting the classification under 2026.1 exposed two structural gaps: no entity type for a derivative contract, despite four derivative forms existing on Layer 3 since publication; and no Layer 2 leaf for compute as a traded commodity unit, so the label fell back to K.04.00, sector unresolved. Both are closed here.

---

0. How to read this standard

The DAP Standard classifies any economic entity along six independent layers. A full classification is a vector, not a single code. Reading a classification means reading all six layers together.

Layer 1  Primary economic domain      one letter        K
Layer 2  Sector . segment             letter.NN.NN      K.02.03
Layer 3  Asset form                   F-prefixed code   F-MOD-OPEN
Layer 4  Geography                    ISO-2 or bloc     US, XN
Layer 5  Secondary themes             multi-select      [T-AICOMPUTE, T-OPENWEIGHT]
Layer 6  Risk, governance, policy     multi-select      [R-EXPORTCTRL, G-STEWARD]

The single required field is Layer 2 (the economic path). Every other layer is populated where it applies and left null where it does not. A short-dated Canadian treasury bill has no model-openness tag; an open-weight model has no coupon. The standard is designed so that emptiness is meaningful, not a defect.

The rest of this document is the definition of each layer, the full coded hierarchy, the special modules that govern the hardest cases (model weights, tokens, multi-label conflicts, geography, derivatives), the coding and versioning grammar, worked examples, and the governance rules that keep the standard alive.

---

Part 1. Executive philosophy and design rationale

1.1 Why a new standard is required in 2026

The classification systems that institutional capital relies on were built for a world of companies and the securities they issue. That world still exists and the DAP Standard covers it in full. But it is now a proper subset of the economy that asset owners actually hold exposure to.

Three shifts break the old frame:

The unit of value is no longer only the firm. A frontier model is an asset with its own economics, its own scarcity, its own decay curve, and its own transfer characteristics, largely independent of the company that trained it. A protocol accrues fees to a token held by parties who are not shareholders of any company. A dataset generates a licensing stream. Classifying only the issuing company and stopping there discards most of what a modern portfolio is exposed to.

Function has decoupled from legal form. The same economic exposure, say senior claims on a stream of real estate rent, now arrives as a private fund interest, a listed security, or an on-chain tokenised claim, with materially different custody, settlement, and governance properties. A system organised only around legal wrappers misfiles the exposure. A system organised only around economic function loses the wrapper detail that drives risk. The DAP Standard separates the two into distinct layers so neither is lost.

The consumer of classification changed. Classification used to be read by analysts. It is now read first by machines. Overture, DAP's multi-agent portfolio intelligence platform, reasons over holdings, drafts policy, and tests mandates against exposure. It needs a classification that is deterministic, versioned, and expressible as data, with definitions precise enough that two agents, or an agent and a human, reach the same label from the same facts.

No public-domain government standard covers model weights, autonomous agents, tokenised real-world claims, or on-chain protocol economics. No such standard was built for machine reasoning over a living, versioned scheme. The DAP Standard is built for exactly that, from first principles, as original intellectual property.

1.2 Intellectual foundation

The standard rests on four ideas.

Value origination, not industry membership. The primary spine (Layer 1 and Layer 2) places an entity by the mechanism through which it originates or captures value, the question "where does the economic value come from," rather than by an industry label attached to a firm. This lets a model developer, a protocol, a bank, and a mine sit on one coherent spine, because each answers the same question.

Orthogonal layers. Economic function, legal and asset form, geography, theme, and risk are genuinely independent properties. Collapsing them into one code, the historical practice, forces false choices (is a tokenised treasury bond "fixed income" or "digital assets"? it is both, on different layers). The DAP Standard keeps them orthogonal so the answer is complete rather than forced.

Emptiness is information. Because layers are orthogonal and optional, the pattern of which layers are populated is itself a signal. An entity with a rich Layer 6 risk profile and a null Layer 3 form is a policy object, not a security. Overture reads these patterns directly.

Continuity over cleanliness. A living taxonomy will be wrong in ways not yet visible. The standard is versioned so that categories can be split, merged, and retired without breaking historical series, because every code ever issued maps forward. A clean scheme that cannot evolve is worse than a slightly redundant one that can.

1.3 Named assumptions this design rests on

Per DAP practice, the significant design choices carry explicit assumptions, so that a future failure traces to a broken assumption rather than to a rebuild.

• A1. Function is more stable than wrapper. We assume an entity's economic function changes more slowly than the legal or technical form it is delivered in. If this reverses (forms becoming more durable than functions), the primary spine should move to Layer 3 and the current spine demote to an attribute. What would break it: a regime where wrappers are permanent and functions are routinely re-pointed underneath them.
• A2. Model weights are durable, transferable assets. We assume frontier and open-weight models are held, valued, licensed, and transferred as assets distinct from their creators. If models become non-transferable in practice (pure hosted services with no assignable rights), the model-asset form collapses into a service revenue line under Layer 2 domain K and Module A is demoted.
• A3. On-chain settlement persists as a distinct property. We assume that whether a claim settles on a public ledger remains economically material (custody, finality, counterparty). If on-chain and off-chain settlement converge to indistinguishable risk, Layer 3's digital forms merge with their traditional analogues.
• A4. Machine and human readers must agree. We assume the standard's primary value is that an Overture agent and a DAP analyst reach the same classification. Every ambiguity is resolved by an explicit rule (Module C) rather than left to judgement. What would break it: definitions loose enough that inter-rater agreement falls, at which point the offending nodes are split or re-defined.
• A5. Public-domain-only lineage. We assume the standard must remain free of any proprietary commercial scheme's structure or naming, to be freely usable and defensible as DAP IP. Coverage completeness is checked only against public government concepts (activity families in the spirit of ISIC, NAICS, SIC), never against commercial taxonomies.
• A6. Compute is becoming a commodity with an independent, referenceable price. We assume standardised accelerator capacity trades as a fungible unit whose price is observable independently of any single provider's contract terms, and that the unit is durable enough to carry its own leaf. The leaf rests on the unit, not on any one venue, contract, or administrator. If this reverses, K.04.05 is retired with a forward map to K.04.01 and T-COMPUTEMKT retires with a forward map to T-AICOMPUTE. What would break it: the disappearance of every independently published capacity price and every venue trading a fungible unit, or a return to capacity sold only inside bundled, bespoke, non-transferable supply agreements. The withdrawal, non-approval, or illiquidity of any single listed contract does not break it; such an event is recorded against the affected contracts in deriv_attrs and in the review log, and the leaf stands. A6 is weaker than A1 to A5 and should be read that way: K.04.05 was added on published daily benchmarks, spot venues, and announced listings rather than on a deep observed market, which is a deliberate and stated risk.

1.4 How the standard serves multi-agent intelligence and living policy

Overture agents consume the standard as a versioned schema (the companion JSON). Three properties matter for that consumption.

• Deterministic labels. A mandate that says "no more than 5 percent in pre-revenue frontier compute" is only enforceable if "frontier compute" resolves to specific Layer 2 codes and "pre-revenue" resolves to a specific Layer 5 or 6 tag. The standard supplies those resolutions.
• Policy expressed against layers. Investment policy statements, concentration limits, and exclusion lists are written as predicates over the six layers. Because the layers are orthogonal, a policy can say "exclude Layer 6 R-EXPORTCTRL regardless of Layer 2" without rewriting the whole rule for each affected sector. This is the bridge to DAP's living policy architecture: the classification is the substrate that policy rules are compiled against.
• Versioned continuity for backtests. Because retired codes map forward, a policy tested against five years of history reads a stable series even as the taxonomy evolves underneath it.

---

Part 2. Overall architecture

2.1 Entity types

Before an entity is classified, it is typed. The entity type governs which layers are mandatory and which special module applies. Eight types:

Code	Entity type	Definition	Spine anchored on
E-ISSUER	Company or issuer	An operating or holding organisation that produces goods, services, or claims.	Primary economic activity
E-SEC	Security	A financial claim issued by an entity (equity, debt, unit).	Function of the claim, form on Layer 3
E-TOKEN	Digital token or protocol	An on-chain asset or the protocol that issues and governs it.	Primary economic function and value accrual (Module B)
E-MODEL	Model asset or weights	A trained model treated as an asset, distinct from its creator.	Model function, attributes via Module A
E-FUND	Fund or vehicle	A pooled or structured vehicle holding other entities.	Strategy and underlying, form on Layer 3
E-REAL	Real asset	A physical or resource asset (property, infrastructure, commodity unit).	Asset function and resource type
E-HYBRID	Hybrid instrument	An instrument that bridges traditional and digital settlement or rights.	Underlying function, with both forms recorded
E-DERIV	Derivative contract	A bilateral or cleared contract whose value is determined by reference to an underlying asset, rate, index, price, or event, and which is not itself an issued claim on an entity.	The activity that produces or supplies the referenced underlying (Module C.6), attributes via Module E

Entity type is recorded but is not one of the six classification layers. It is the pre-classification switch that decides how the layers are filled.

E-DERIV was added in 2026.2. Because entity type is not a layer, adding a type changes no layer definition and re-points no existing classification. The four derivative forms on Layer 3 (F-DERIV-OPT, F-DERIV-FUT, F-DERIV-SWAP, F-DERIV-PERP) shipped in 2026.1 without a type to use them; E-DERIV closes that.

2.2 The six layers

Layer 1, primary economic domain. One of sixteen top-level domains, each a broad mechanism of value origination. A single letter (A to R, skipping I and O to avoid confusion with digits). Exactly one domain per entity.

Layer 2, sector and segment. Within a domain, a two-level hierarchy: sector (two digits) and segment (two digits), the segment being the leaf. Written Domain.Sector.Segment, e.g. M.03.02. Exactly one leaf per entity. This is the only mandatory layer.

Layer 3, asset form and instrument type. The legal or technical wrapper through which exposure is held. A controlled vocabulary of F- codes. Populated for securities, tokens, funds, real assets, models, and hybrids; null for a bare operating company with no traded claim in view.

Layer 4, geography. Where the entity is domiciled, operates, or, for borderless on-chain entities, is jurisdictionally situated. ISO 3166 alpha-2 country codes (public domain), DAP region and bloc codes, and the reserved code XN for jurisdictionless on-chain entities.

Layer 5, secondary attributes and themes. Multi-select T- tags for cross-cutting exposures that are real but are not the primary spine: a decarbonisation theme, an AI-compute dependency, a tokenisation-enablement role. Any number, including zero.

Layer 6, risk, governance and policy tags. Multi-select tags splitting into risk (R-), governance (G-), and policy (P-) families. These carry the properties that mandates and living policy rules test against: custody model, centralisation, regulatory regime, export-control exposure, model-safety tier, and so on.

2.3 Why six and why orthogonal

Each layer answers a different question that a portfolio must answer separately:

• Layer 1 and 2: what does it do economically?
• Layer 3: how do I hold it, and how does it settle?
• Layer 4: whose rules and whose economy?
• Layer 5: what themes does it also touch?
• Layer 6: what could go wrong, who governs it, what policy bites?

Because these are separate questions, they are separate layers. The design cost is that a full classification is longer than a single legacy code. The design benefit is that no question is answered by force-fitting it into the wrong slot, and that policy can address any one question in isolation.

---

Part 3. The full hierarchical taxonomy

3.0 The domain spine (Layer 1)

Sixteen domains, ordered roughly from physical substrate through abstraction to the sovereign frame that contains them. The letters I and O are skipped throughout the standard to avoid confusion with the digits 1 and 0.

Domain	Name	Value-origination mechanism
A	Primary resources and extraction	Drawing value directly from land, sea, and subsurface
B	Materials and industrial transformation	Converting raw inputs into processed materials and goods
C	Built environment and real assets	Creating and holding fixed structures and property
D	Networks and movement	Moving people, goods, and signals across space
E	Energy systems and power	Generating, storing, and delivering usable energy
F	Consumer provisioning	Supplying goods and services to households
G	Health and life systems	Maintaining and restoring human health
H	Bioeconomy and synthetic systems	Engineering biology as a production technology
J	Software and digital services	Producing non-AI software and digital service value
K	Artificial intelligence and cognitive systems	Producing machine cognition and its direct inputs
L	Data and information assets	Originating and licensing information as an asset
M	Capital, risk and financial intermediation	Allocating capital and transferring risk
N	Digital asset and protocol economy	Accruing value to on-chain protocols and tokens
P	Environmental and planetary markets	Pricing and trading environmental outcomes
Q	Frontier, space and orbital	Operating beyond the terrestrial surface
R	Public, civic and sovereign	Providing public goods and sovereign functions

The domains are exhaustive at the top level by construction: any economic entity originates value through at least one of these mechanisms. Where more than one applies, Module C (multi-label rules) selects the primary and records the rest as Layer 5 themes.

Z is not a domain. The leaf Z.00.00 is reserved as the unresolved-domain marker for E-DERIV entities referencing a cross-domain basket with no dominant value-origination mechanism (rule C.6.4). It is never used for any other entity type and never carries a sector or segment.

---

Domain A. Primary resources and extraction

Value drawn directly from natural endowment before material transformation.

A.01 Agriculture and cultivated systems

Code	Segment	Definition
A.01.01	Row and field crops	Cultivation of grains, oilseeds, and field crops for food, feed, or industrial use.
A.01.02	Permanent and specialty crops	Orchards, vineyards, and perennial specialty cultivation.
A.01.03	Controlled-environment agriculture	Indoor, vertical, and greenhouse cultivation with managed inputs.
A.01.04	Livestock and animal production	Raising animals for meat, dairy, fibre, or breeding.
A.01.05	Aquaculture	Farmed production of fish, shellfish, and aquatic organisms.
A.01.06	Agricultural inputs and services	Seed, crop protection, fertiliser distribution, and field services not classified as manufacturing.

A.02 Forestry and land

Code	Segment	Definition
A.02.01	Timberland and managed forestry	Ownership and harvest of standing timber and managed forest.
A.02.02	Non-timber land resources	Grazing, conservation, and undeveloped land held for resource value.

A.03 Fishing and marine harvest

Code	Segment	Definition
A.03.01	Wild-capture fishing	Harvest of wild aquatic species.
A.03.02	Marine resource harvest	Harvest of non-fish marine resources (kelp, minerals from seawater).

A.04 Metals and mining

Code	Segment	Definition
A.04.01	Precious metals	Extraction of gold, silver, and platinum-group metals.
A.04.02	Base and industrial metals	Extraction of copper, aluminium ore, zinc, nickel, and similar.
A.04.03	Battery and transition metals	Extraction of lithium, cobalt, and metals concentrated in energy-transition demand.
A.04.04	Rare earth and critical minerals	Extraction of rare-earth elements and minerals designated strategically critical.
A.04.05	Bulk and steelmaking inputs	Iron ore, coking coal, and bulk mineral inputs to primary industry.

A.05 Hydrocarbon extraction

Code	Segment	Definition
A.05.01	Crude oil extraction	Upstream production of crude petroleum.
A.05.02	Natural gas extraction	Upstream production of natural gas and associated liquids.
A.05.03	Unconventional and heavy resources	Oil sands, shale, and heavy hydrocarbon production.

A.06 Water as a primary resource

Code	Segment	Definition
A.06.01	Freshwater rights and supply	Ownership and supply of raw freshwater and abstraction rights.
A.06.02	Desalination and water production	Production of usable water from saline or impaired sources.

---

Domain B. Materials and industrial transformation

Conversion of raw inputs into processed materials, components, and finished goods.

B.01 Basic and advanced materials

Code	Segment	Definition
B.01.01	Commodity chemicals	Bulk chemical production (petrochemicals, industrial gases, base polymers).
B.01.02	Specialty and fine chemicals	Formulated and application-specific chemical products.
B.01.03	Metals refining and processing	Smelting, refining, and primary shaping of metals.
B.01.04	Construction materials	Cement, aggregates, glass, and structural materials.
B.01.05	Advanced and engineered materials	Composites, semiconductor-grade materials, and engineered substrates.

B.02 Manufactured goods

Code	Segment	Definition
B.02.01	Industrial machinery and equipment	Capital equipment and machinery for production and construction.
B.02.02	Electrical and electronic components	Components and assemblies below the level of finished electronics.
B.02.03	Transportation equipment	Vehicles, aircraft, rail stock, and marine vessels as manufactured goods.
B.02.04	Consumer durable manufacturing	Manufacture of appliances, furnishings, and durable consumer goods.
B.02.05	Defence and aerospace systems	Manufacture of defence platforms, munitions, and aerospace systems.

B.03 Semiconductor and hardware fabrication

Code	Segment	Definition
B.03.01	Logic and memory fabrication	Foundry and integrated fabrication of logic and memory devices.
B.03.02	AI accelerator design and supply	Design and supply of processors specialised for AI training and inference.
B.03.03	Semiconductor capital equipment	Lithography, deposition, and metrology equipment for fabrication.
B.03.04	Advanced packaging and interconnect	High-density packaging, chiplet integration, and interconnect.

B.04 Robotics and automation hardware

Code	Segment	Definition
B.04.01	Industrial and warehouse robotics	Fixed and mobile robots for production and logistics.
B.04.02	Humanoid and general-purpose robotics	General-purpose robotic platforms intended for varied physical tasks.
B.04.03	Autonomous mobility hardware	Sensing and actuation hardware for autonomous vehicles and drones.

---

Domain C. Built environment and real assets

Creation, ownership, and operation of fixed structures and land improvements.

C.01 Real estate ownership

Code	Segment	Definition
C.01.01	Residential property	Ownership of housing held for rent or appreciation.
C.01.02	Commercial and office property	Ownership of office and mixed commercial property.
C.01.03	Industrial and logistics property	Warehouses, distribution, and industrial real estate.
C.01.04	Retail and hospitality property	Retail centres, hotels, and hospitality real estate.
C.01.05	Digital infrastructure real estate	Data-centre and compute-facility property held as real assets.
C.01.06	Specialised and social real estate	Healthcare, education, and specialised-use property.

C.02 Construction and development

Code	Segment	Definition
C.02.01	Building construction	Vertical construction of residential and commercial structures.
C.02.02	Infrastructure construction	Heavy civil construction of transport, water, and energy works.
C.02.03	Real estate development	Origination and entitlement of new real estate projects.

C.03 Real estate services

Code	Segment	Definition
C.03.01	Property management and operation	Operation and servicing of real estate on behalf of owners.
C.03.02	Brokerage and transaction services	Intermediation of real estate transactions and leasing.

---

Domain D. Networks and movement

Moving people, goods, and signals across space, and the fixed networks that carry them.

D.01 Transport and logistics

Code	Segment	Definition
D.01.01	Freight and cargo transport	Movement of goods by road, rail, sea, or air.
D.01.02	Passenger transport	Movement of people by scheduled or on-demand carriers.
D.01.03	Logistics and fulfilment	Warehousing, sortation, and last-mile fulfilment networks.
D.01.04	Transport infrastructure operation	Operation of ports, airports, toll roads, and terminals as concessions.

D.02 Communications networks

Code	Segment	Definition
D.02.01	Fixed and mobile connectivity	Operation of wireline and wireless communications networks.
D.02.02	Satellite and non-terrestrial connectivity	Communications carried by satellite and high-altitude platforms.
D.02.03	Network infrastructure and towers	Passive network infrastructure, towers, and fibre held as assets.

D.03 Compute and data-transport fabric

Code	Segment	Definition
D.03.01	Data-centre operation	Operation of facilities that house compute and storage at scale.
D.03.02	Interconnection and content delivery	Exchange points, peering, and content-delivery networks.

---

Domain E. Energy systems and power

Generation, storage, conversion, and delivery of usable energy, including the energy layer that supplies AI compute.

E.01 Power generation

Code	Segment	Definition
E.01.01	Renewable generation	Electricity from solar, wind, hydro, and other renewable sources.
E.01.02	Nuclear generation	Electricity from fission, including small modular reactors.
E.01.03	Fossil generation	Electricity from coal, gas, and oil combustion.
E.01.04	Emerging generation	Fusion, enhanced geothermal, and pre-commercial generation.

E.02 Energy delivery and storage

Code	Segment	Definition
E.02.01	Transmission and distribution	Operation of grid infrastructure delivering power to load.
E.02.02	Grid-scale storage	Stationary storage balancing supply and demand on the grid.
E.02.03	Fuels distribution and retail	Distribution and retail of refined fuels and gas to end users.

E.03 Energy for compute

Code	Segment	Definition
E.03.01	Dedicated compute power supply	Generation and supply contracted specifically to power data centres and AI compute.
E.03.02	Behind-the-meter and co-located energy	On-site generation and storage co-located with compute load.

E.04 Energy transition inputs

Code	Segment	Definition
E.04.01	Battery and cell manufacturing	Manufacture of energy-storage cells and packs.
E.04.02	Hydrogen and alternative carriers	Production and handling of hydrogen and alternative energy carriers.
E.04.03	Electrification equipment	Charging, power electronics, and equipment enabling electrification.

---

Domain F. Consumer provisioning

Supplying goods and services to households and individuals.

F.01 Consumer goods

Code	Segment	Definition
F.01.01	Food and beverage products	Manufactured food and beverage products for consumption.
F.01.02	Household and personal products	Non-durable household, personal-care, and cosmetic products.
F.01.03	Apparel and lifestyle goods	Clothing, footwear, and lifestyle consumer goods.
F.01.04	Consumer electronics products	Finished consumer electronic devices sold to households.

F.02 Consumer services and retail

Code	Segment	Definition
F.02.01	Physical retail	Sale of goods through physical outlets.
F.02.02	Digital commerce	Sale of goods and services through online marketplaces and storefronts.
F.02.03	Food service and hospitality	Restaurants, lodging, and hospitality services.
F.02.04	Leisure and experiences	Travel, entertainment venues, and experiential services.

F.03 Consumer media and content

Code	Segment	Definition
F.03.01	Content production and rights	Creation and ownership of film, music, and media rights.
F.03.02	Streaming and distribution	Distribution of content to consumers through subscription or ad models.
F.03.03	Interactive entertainment	Games and interactive experiences sold or operated for consumers.

---

Domain G. Health and life systems

Maintaining and restoring human health. Biological engineering as a production technology sits in Domain H; this domain covers care, therapeutics, and devices.

G.01 Therapeutics

Code	Segment	Definition
G.01.01	Small-molecule pharmaceuticals	Discovery and manufacture of small-molecule drugs.
G.01.02	Biologics and large molecules	Antibody, protein, and other large-molecule therapeutics.
G.01.03	Cell and gene therapies	Therapies based on engineered cells or genetic modification.
G.01.04	Vaccines and immunotherapies	Preventive and immune-directed therapeutics.
G.01.05	AI-native drug discovery	Therapeutic discovery where machine models are the primary discovery engine.

G.02 Devices and diagnostics

Code	Segment	Definition
G.02.01	Medical devices	Instruments and implants used in diagnosis and treatment.
G.02.02	Diagnostics and testing	Laboratory and point-of-care diagnostic products and services.
G.02.03	Digital health and monitoring	Software and connected devices for health monitoring and management.

G.03 Care delivery and health services

Code	Segment	Definition
G.03.01	Provider and hospital services	Delivery of clinical care through providers and facilities.
G.03.02	Health payers and benefits	Financing and administration of health coverage.
G.03.03	Pharmacy and distribution	Distribution and dispensing of therapeutics.

---

Domain H. Bioeconomy and synthetic systems

Engineering biology as a general production technology, and the extension of healthy human lifespan as a distinct economic objective. Separated from Domain G because the value-origination mechanism is manufacturing and platform technology, not care.

H.01 Synthetic biology platforms

Code	Segment	Definition
H.01.01	Organism and strain engineering	Design and engineering of organisms for production purposes.
H.01.02	Bio-manufacturing and fermentation	Production of materials, chemicals, and proteins through engineered biology.
H.01.03	Cell-free and enzymatic systems	Production using isolated biological machinery outside living cells.
H.01.04	Biological design tools	Software and instruments that design and simulate biological systems.

H.02 Agricultural and environmental biology

Code	Segment	Definition
H.02.01	Engineered agricultural inputs	Biologically engineered seeds, traits, and crop inputs.
H.02.02	Alternative and cultivated foods	Fermented, cultivated, and engineered protein and food products.
H.02.03	Environmental and remediation biology	Engineered organisms for remediation, carbon, and environmental services.

H.03 Longevity and human enhancement

Code	Segment	Definition
H.03.01	Longevity therapeutics	Interventions targeting ageing biology to extend healthy lifespan.
H.03.02	Regenerative and repair systems	Tissue regeneration, organ engineering, and biological repair.
H.03.03	Human performance and enhancement	Interventions to extend or augment healthy human capability.

---

Domain J. Software and digital services

Producing software and digital service value where machine cognition is not the primary product. AI-native production sits in Domain K; this domain is the large body of conventional and applied software.

J.01 Application software

Code	Segment	Definition
J.01.01	Enterprise application software	Software operating core business functions (resource planning, workflow).
J.01.02	Vertical and industry software	Software specialised to a single industry's operations.
J.01.03	Consumer and prosumer software	Software sold or operated directly for individuals and small teams.
J.01.04	Developer and infrastructure software	Tools and platforms used to build and operate other software.

J.02 Digital platforms

Code	Segment	Definition
J.02.01	Marketplace and network platforms	Platforms whose value is the network connecting participants.
J.02.02	Social and communication platforms	Platforms for interpersonal communication and social interaction.
J.02.03	Search and discovery platforms	Platforms organising information and directing attention.

J.03 Digital services

Code	Segment	Definition
J.03.01	Cloud and hosting services	General-purpose compute, storage, and hosting sold as a service.
J.03.02	Cybersecurity services and software	Protection of systems, networks, and data as product and service.
J.03.03	IT and professional digital services	Implementation, integration, and managed digital services.
J.03.04	Fintech and embedded software services	Software delivering financial function embedded in non-financial products.

---

Domain K. Artificial intelligence and cognitive systems

Producing machine cognition and its direct inputs. This domain classifies the operating entities and services of the AI economy. Model weights as standalone assets are classified here on Layer 2 and characterised in full by Module A. Autonomous agents that act as economic entities are classified here and characterised by the agent attributes in Module A.4.

K.01 Frontier and foundation model development

Code	Segment	Definition
K.01.01	Frontier general model development	Development of the most capable general-purpose models at the compute frontier.
K.01.02	Applied and domain foundation models	Development of foundation models specialised to a domain (code, biology, finance).
K.01.03	Open-weight model development	Development of models released with openly available weights (see Module A openness regime).
K.01.04	Small and edge model development	Development of compact models optimised for on-device or low-cost inference.

K.02 Model assets and weights

The asset itself, distinct from its developer. Classified here; fully attributed by Module A. | Code | Segment | Definition | |---|---|---| | K.02.01 | Closed frontier model weights | Weights of a frontier model held under closed or gated licence as an asset. | | K.02.02 | Open-weight model assets | Publicly released model weights available for local deployment and modification. | | K.02.03 | Fine-tuned and derivative model assets | Model assets derived by adapting a base model to a task or domain. | | K.02.04 | Model rights and royalty claims | Financial claims on the economics of a model without holding the weights. |

K.03 AI agents and agentic systems

Code	Segment	Definition
K.03.01	Task and workflow agents	Agents that execute bounded tasks or workflows under human oversight.
K.03.02	Autonomous economic agents	Agents that hold resources, transact, and pursue objectives with limited human intervention.
K.03.03	Multi-agent systems and orchestration	Systems coordinating multiple agents toward a composite objective (the class Overture belongs to).
K.03.04	Agent infrastructure and tooling	Frameworks, memory, tool-use, and identity infrastructure for agents.

K.04 AI compute and training infrastructure

Code	Segment	Definition
K.04.01	Training compute provision	Provision of large-scale compute for model training.
K.04.02	Inference and serving infrastructure	Provision of compute and systems for model inference at scale.
K.04.03	AI cloud and model-hosting platforms	Platforms that host and serve third-party models as a service.
K.04.04	Compute brokerage and marketplaces	Intermediation and marketplace matching of compute supply and demand.
K.04.05	Traded compute capacity	Standardised accelerator or compute capacity treated as a fungible commodity unit rather than as a named provider's service. Covers spot and forward capacity sold by the unit, published rental price benchmarks as the good being referenced, and cleared or bilateral contracts settling against them. The boundary is the unit: K.04.01 to K.04.04 classify parties who sell compute, K.04.05 classifies compute sold as a unit independent of who supplied it. An entity that publishes a benchmark is classified by its own activity at M.07.02, not here.

K.05 AI data and evaluation inputs

Code	Segment	Definition
K.05.01	Synthetic data generation	Production of machine-generated data for training and evaluation.
K.05.02	Human data and annotation	Sourcing and labelling of human-generated training data.
K.05.03	Model evaluation and benchmarking	Measurement of model capability, reliability, and comparative performance.
K.05.04	AI safety, alignment and assurance	Research, tooling, and services directed at model safety, alignment, and assurance.

K.06 Applied AI products

Code	Segment	Definition
K.06.01	Horizontal AI applications	AI products serving general cross-industry tasks (assistants, generation).
K.06.02	Vertical AI applications	AI products specialised to a single industry's work.
K.06.03	Embodied and physical AI	AI systems whose primary output is control of physical machines and robots.

---

Domain L. Data and information assets

Originating, holding, and licensing information as an economic asset in its own right. Where a company merely uses data internally, it is classified by its economic activity elsewhere; this domain is for entities whose value originates in data as a held or licensed asset.

L.01 Data assets

Code	Segment	Definition
L.01.01	Proprietary primary datasets	Original datasets held as assets and licensed or monetised.
L.01.02	Aggregated and reference data	Curated aggregations and reference data sold to institutions.
L.01.03	Real-time and sensor data feeds	Continuously generated data streams sold as subscriptions or feeds.
L.01.04	Rights-cleared training corpora	Data assembled and rights-cleared specifically for model training.

L.02 Data infrastructure and markets

Code	Segment	Definition
L.02.01	Data marketplaces and exchanges	Venues intermediating the sale and licensing of data assets.
L.02.02	Data trusts and stewardship vehicles	Vehicles holding data on behalf of contributors under defined governance.
L.02.03	Data provenance and rights infrastructure	Systems tracking origin, consent, and licence status of data.

L.03 Information and analytics services

Code	Segment	Definition
L.03.01	Market and financial information	Provision of financial market data and analytics as a service.
L.03.02	Sector and alternative information	Specialised and alternative information products for decision-making.
L.03.03	Identity and verification data	Data services establishing identity, credentials, and verification.

---

Domain N. Digital asset and protocol economy

Value that accrues to on-chain protocols and the tokens they issue. Entity type is almost always E-TOKEN; the token classification framework (Module B) supplies the economic-rights and tradability detail that sits behind the Layer 2 leaf. A token that is a tokenised claim on an off-chain asset is a hybrid: it is classified by its underlying economic function elsewhere and carries the tokenised form on Layer 3, with the on-chain properties recorded here as themes. The distinction is set out in Module B.4.

N.01 Settlement and smart-contract platforms

Code	Segment	Definition
N.01.01	Base-layer settlement networks	Layer-1 networks providing base settlement and security for on-chain activity.
N.01.02	Scaling and execution layers	Layer-2 and execution networks extending a base layer's throughput.
N.01.03	Interoperability and bridging protocols	Protocols moving value and messages between networks.
N.01.04	Application-specific chains	Networks purpose-built for a single application or protocol.

N.02 Decentralised finance primitives

Code	Segment	Definition
N.02.01	Decentralised exchange and market-making	Protocols providing on-chain trading and automated liquidity.
N.02.02	On-chain lending and credit	Protocols intermediating on-chain borrowing and lending.
N.02.03	On-chain derivatives and structured products	Protocols issuing derivatives and structured exposure on-chain.
N.02.04	Staking, restaking and yield primitives	Protocols coordinating staked capital and derived yield.
N.02.05	On-chain asset management	Protocols allocating pooled on-chain capital under encoded strategy.

N.03 Digital money and stable value

Code	Segment	Definition
N.03.01	Fiat-backed stablecoins	Tokens redeemable for fiat and backed by reserve assets.
N.03.02	Crypto-collateralised stable tokens	Stable-value tokens collateralised by on-chain assets.
N.03.03	Algorithmic and hybrid stable tokens	Stable-value tokens relying wholly or partly on algorithmic mechanisms.
N.03.04	Tokenised deposits and e-money	On-chain representations of regulated bank deposits or e-money.

N.04 Decentralised physical infrastructure (DePIN)

Code	Segment	Definition
N.04.01	Compute and storage networks	Protocols coordinating distributed compute and storage against token incentives.
N.04.02	Connectivity and wireless networks	Protocols coordinating distributed wireless and connectivity capacity.
N.04.03	Energy and sensor networks	Protocols coordinating distributed energy resources or sensing.
N.04.04	Mobility and mapping networks	Protocols coordinating distributed mobility data and mapping.

N.05 Protocol governance and coordination

Code	Segment	Definition
N.05.01	Governance tokens	Tokens whose primary function is protocol governance rights.
N.05.02	Utility and access tokens	Tokens whose primary function is access to protocol services.
N.05.03	Autonomous organisation treasuries	On-chain treasuries governed by encoded collective decision-making.
N.05.04	Culture and community tokens with economic function	Social and culture tokens tagged by their explicit economic function, not by sentiment.

N.06 On-chain identity and provenance

Code	Segment	Definition
N.06.01	Identity and attestation protocols	Protocols issuing and verifying on-chain identity and attestations.
N.06.02	Non-fungible asset standards	Protocols and standards for unique on-chain assets and their provenance.

---

Domain M. Capital, risk and financial intermediation

Allocating capital and transferring risk. Domain M classifies entities whose own activity is financial. Individual securities are not usually classified in M: a bond or share is classified by looking through to the issuer's economic activity (Module C.3), with the instrument recorded on Layer 3. M is for the intermediaries, the markets, and the pooled vehicles themselves.

M.01 Banking and deposit intermediation

Code	Segment	Definition
M.01.01	Commercial and retail banking	Deposit-taking and lending to households and businesses.
M.01.02	Corporate and institutional banking	Banking services to large corporates and institutions.
M.01.03	On-chain and digital-native banking	Deposit and credit intermediation delivered natively on-chain or through digital rails.

M.02 Insurance and risk transfer

Code	Segment	Definition
M.02.01	Life and health insurance	Underwriting of life, health, and longevity risk.
M.02.02	Property and casualty insurance	Underwriting of property, liability, and casualty risk.
M.02.03	Reinsurance and retrocession	Transfer of insured risk between carriers.
M.02.04	Alternative and parametric risk transfer	Risk transfer through capital-market and parametric structures.

M.03 Asset management and allocation

Vehicles are typed E-FUND with their form on Layer 3; this sector classifies the strategy. | Code | Segment | Definition | |---|---|---| | M.03.01 | Public-market asset management | Management of listed equity and fixed-income strategies. | | M.03.02 | Private equity and buyout | Acquisition and management of private operating companies for control returns. | | M.03.03 | Venture and growth capital | Investment in early and growth-stage private companies. | | M.03.04 | Private credit and direct lending | Non-bank lending strategies held in managed vehicles. | | M.03.05 | Hedge and absolute-return strategies | Trading strategies pursuing returns largely independent of market direction. | | M.03.06 | Real asset and infrastructure strategies | Managed strategies in real estate, infrastructure, and natural resources. | | M.03.07 | Digital asset investment strategies | Managed strategies allocating to tokens, protocols, and digital assets. | | M.03.08 | Multi-asset and allocation vehicles | Vehicles allocating across asset classes on behalf of owners. |

M.04 Capital markets and market operation

Code	Segment	Definition
M.04.01	Exchanges and trading venues	Operation of venues matching buyers and sellers.
M.04.02	Clearing, settlement and custody	Post-trade infrastructure holding and settling assets.
M.04.03	Brokerage and dealing	Intermediation and market-making in financial instruments.
M.04.04	Investment banking and advisory	Origination, underwriting, and advisory services.

M.05 Money, currency and foreign exchange

Code	Segment	Definition
M.05.01	Fiat currency and FX markets	National currencies as exposures and the markets trading them.
M.05.02	Central-bank digital currency	Sovereign digital money issued and settled digitally.
M.05.03	Money-market and cash instruments	Short-dated instruments held as cash equivalents.

M.06 Credit and specialty finance

Code	Segment	Definition
M.06.01	Structured and securitised credit	Credit repackaged into structured and securitised instruments.
M.06.02	Consumer and commercial finance	Non-bank financing of consumers and businesses.
M.06.03	Trade and receivables finance	Financing of trade flows and receivables.

M.07 Financial infrastructure and payments

Code	Segment	Definition
M.07.01	Payments and transfer networks	Networks moving money between parties.
M.07.02	Data, index and benchmark provision	Provision of indices, benchmarks, and reference data, including physical-market and capacity-market price assessments that serve as settlement references for traded contracts. Classified here by the act of administering the reference, irrespective of what the reference prices.
M.07.03	Regulatory and compliance infrastructure	Systems delivering compliance, reporting, and regulatory function.

---

Domain P. Environmental and planetary markets

Pricing and trading environmental outcomes as economic goods. Distinct from Domain E (which produces energy) and Domain A (which extracts resources): Domain P is where the environmental outcome itself is the traded asset.

P.01 Carbon and emissions markets

Code	Segment	Definition
P.01.01	Compliance carbon allowances	Emissions allowances issued under regulated cap-and-trade regimes.
P.01.02	Voluntary carbon credits	Credits representing verified emissions reduction or removal, traded voluntarily.
P.01.03	Carbon removal and sequestration	Assets representing durable removal of carbon from the atmosphere.
P.01.04	Carbon market infrastructure	Registries, verification, and market operation for carbon assets.

P.02 Natural capital and ecosystem markets

Code	Segment	Definition
P.02.01	Biodiversity and habitat credits	Assets representing measured biodiversity or habitat outcomes.
P.02.02	Water quality and watershed credits	Assets representing measured water and watershed outcomes.
P.02.03	Natural capital asset holdings	Ownership of natural systems held for their measured ecosystem value.

P.03 Environmental services and adaptation

Code	Segment	Definition
P.03.01	Measurement, reporting and verification	Services measuring and verifying environmental outcomes.
P.03.02	Climate adaptation and resilience assets	Assets whose value derives from providing resilience to climate change.

---

Domain Q. Frontier, space and orbital

Operating beyond the terrestrial surface, and adjacent frontier domains where material. Included as a first-class domain because the exposures are structurally distinct and increasingly held by institutions.

Q.01 Launch and access

Code	Segment	Definition
Q.01.01	Launch services	Transport of payloads to orbit and beyond.
Q.01.02	In-space transport and logistics	Movement and servicing of assets once in space.

Q.02 Orbital assets and services

Code	Segment	Definition
Q.02.01	Earth observation and sensing	Orbital assets producing observation and sensing data.
Q.02.02	Space-based connectivity	Orbital assets providing communications and connectivity.
Q.02.03	Position, navigation and timing	Assets providing positioning and timing services.

Q.03 Extraterrestrial resources and infrastructure

Code	Segment	Definition
Q.03.01	In-space manufacturing	Production of goods in the space environment.
Q.03.02	Resource prospecting and extraction	Prospecting and extraction of extraterrestrial resources.
Q.03.03	Orbital and surface infrastructure	Stations, habitats, and fixed infrastructure beyond Earth.

---

Domain R. Public, civic and sovereign

Providing public goods and performing sovereign functions, and the claims those functions issue. Sovereign and sub-sovereign debt is classified here as issuer, with the instrument on Layer 3.

R.01 Sovereign and sub-sovereign entities

Code	Segment	Definition
R.01.01	Sovereign governments	National governments as issuers and economic actors.
R.01.02	Sub-sovereign and municipal entities	Regional, provincial, and municipal governments.
R.01.03	Supranational and multilateral bodies	Multilateral institutions and supranational issuers.
R.01.04	Sovereign wealth and public investment vehicles	State-owned investment and reserve-management vehicles.

R.02 Public services and infrastructure

Code	Segment	Definition
R.02.01	Public utilities and services	Government-operated utilities and essential services.
R.02.02	Public digital and identity infrastructure	State digital infrastructure, identity, and public technology systems.
R.02.03	Defence and security functions	Sovereign defence and security provision.

R.03 Civic and non-profit

Code	Segment	Definition
R.03.01	Foundations and endowments	Mission-driven asset-holding institutions.
R.03.02	Non-governmental and civic organisations	Organisations providing civic and public-benefit functions.

---

3.7 Layer 3, asset form and instrument type

The wrapper through which exposure is held. Controlled vocabulary, F- prefixed, grouped by family. An entity may in principle carry more than one form (a convertible is both debt and equity-linked); record the primary form and note the secondary in the ingestion record.

Equity forms | Code | Form | Definition | |---|---|---| | F-EQ-PUB-COM | Public common equity | Listed common shares. | | F-EQ-PUB-PREF | Public preferred equity | Listed preferred shares with priority features. | | F-EQ-PRIV | Private equity interest | Unlisted direct equity in an operating company. | | F-EQ-LP | Fund partnership interest | Limited-partner interest in a pooled vehicle. | | F-EQ-FOUND | Founder or restricted equity | Founder, restricted, or vesting equity. |

Debt and credit forms | Code | Form | Definition | |---|---|---| | F-DEBT-SR | Senior debt | Senior-ranking debt claim, secured or unsecured. | | F-DEBT-SUB | Subordinated debt | Debt ranking below senior claims. | | F-DEBT-CONV | Convertible instrument | Debt convertible into equity on defined terms. | | F-DEBT-SOV | Sovereign or sub-sovereign debt | Debt issued by a government or its subdivisions. | | F-DEBT-STRUCT | Structured or securitised debt | Debt repackaged from underlying pools. | | F-DEBT-PRIV | Private credit instrument | Directly originated non-bank loan or note. |

Fund and vehicle forms | Code | Form | Definition | |---|---|---| | F-FUND-OE | Open-end fund | Continuously issued and redeemed pooled fund. | | F-FUND-CE | Closed-end fund | Fixed-capital listed fund. | | F-FUND-ETP | Exchange-traded product | Listed vehicle tracking an underlying exposure. | | F-FUND-LP | Private fund | Limited-partnership or drawdown fund vehicle. | | F-FUND-SMA | Separately managed account | Segregated managed mandate. | | F-FUND-DAO | On-chain fund or treasury | Pooled capital governed and held on-chain. |

Real asset forms | Code | Form | Definition | |---|---|---| | F-REAL-DIRECT | Direct real property | Directly held real estate or land. | | F-REAL-CONCESS | Infrastructure concession | Right to operate an infrastructure asset for a term. | | F-REAL-COMMOD-PHYS | Physical commodity | Physically held commodity units. | | F-REAL-RESRIGHT | Resource or extraction right | Right to extract a natural resource. |

Digital token forms | Code | Form | Definition | |---|---|---| | F-TOK-NATIVE | Native network coin | Native asset securing or paying for a base network. | | F-TOK-GOV | Governance token | Token conferring protocol governance rights. | | F-TOK-UTIL | Utility or access token | Token granting access to protocol services. | | F-TOK-STABLE | Stable-value token | Token designed to hold a stable reference value. | | F-TOK-SEC | Security token | Token that is a regulated security by its rights. | | F-TOK-RECEIPT | Receipt or position token | Token representing a deposited position or claim (LP, staking, restaking receipt). | | F-TOK-NFA | Non-fungible asset | Unique on-chain asset with individual provenance. |

Model and data asset forms | Code | Form | Definition | |---|---|---| | F-MOD-CLOSED | Closed model licence | Right to use a model whose weights are not disclosed. | | F-MOD-OPEN | Open-weight model asset | Held or deployed model with openly available weights. | | F-MOD-CLAIM | Model royalty or rights claim | Financial claim on a model's economics without the weights. | | F-DATA-LIC | Data licence | Right to use a defined dataset under licence. | | F-DATA-UNIT | Data trust unit | Interest in a data-holding vehicle. |

Derivative, hybrid and money forms | Code | Form | Definition | |---|---|---| | F-DERIV-OPT | Option | Right without obligation to transact an underlying. | | F-DERIV-FUT | Future or forward | Obligation to transact an underlying at a future date. | | F-DERIV-SWAP | Swap | Exchange of cash-flow streams. | | F-DERIV-PERP | Perpetual contract | On-chain perpetual derivative with no expiry. | | F-HYB-TOKRWA | Tokenised real-world asset | On-chain token representing an off-chain asset or claim. | | F-HYB-WRAP | Wrapped or bridged asset | Representation of an asset issued on a different network or rail. | | F-MON-FIAT | Fiat money | National currency held as money. | | F-MON-CBDC | Central-bank digital currency | Sovereign digital money. |

3.8 Layer 4, geography (summary)

Full rules are in Module D. In brief:

• Country: ISO 3166 alpha-2 (public domain), e.g. CA, US, SG.
• Region: DAP region codes, e.g. RG-NAM, RG-EUR, RG-APAC, RG-LATAM, RG-MEA.
• Bloc: DAP economic-bloc codes for policy-relevant groupings, e.g. BL-EU, BL-EEA, BL-USMCA, BL-ASEAN, BL-GCC.
• Jurisdictionless: XN for borderless on-chain entities with no meaningful legal domicile.
• Multi-jurisdiction: XM where operations are genuinely distributed with no dominant jurisdiction; the distribution is recorded in the ingestion record.

3.9 Layer 5, secondary attributes and themes

Multi-select T- tags for real cross-cutting exposures that are not the primary spine. Zero or more per entity. Non-exhaustive; new themes are added by minor version.

Code	Theme	Definition
T-AICOMPUTE	AI compute dependency	Value materially depends on access to AI compute.
T-AIEXPOSED	AI capability exposure	Economics materially exposed to advancing AI capability, positively or negatively.
T-OPENWEIGHT	Open-weight ecosystem	Participates in or depends on open-weight model ecosystems.
T-AGENTIC	Agentic operation	Involves autonomous agents acting economically.
T-TOKENISATION	Tokenisation enablement	Enables or depends on the tokenisation of assets.
T-ONCHAIN	On-chain settlement	Settles or operates on a public ledger.
T-DECARB	Decarbonisation	Exposure to reducing emissions intensity.
T-TRANSITION	Energy transition	Exposure to the shift in the energy system.
T-LONGEVITY	Longevity	Exposure to extending healthy human lifespan.
T-BIOENG	Biological engineering	Exposure to engineered-biology production methods.
T-DATASSET	Data as asset	Value materially derives from data held as an asset.
T-CRITMIN	Critical minerals	Exposure to strategically critical minerals.
T-STRATEGIC	Strategic or sovereignty	Subject to sovereignty, security, or strategic-autonomy concern.
T-AUTODISPLACE	Automation displacement	Materially exposed to labour displacement by automation.
T-NETWORK	Network effect	Value driven by network effects among participants.
T-FRONTIERPHYS	Physical frontier	Exposure to space, orbital, or other physical frontier.
T-REALYIELD	Real-world yield	Produces yield sourced from off-chain economic activity.
T-COMPUTEMKT	Compute market exposure	Value depends on the traded price of compute capacity, as distinct from dependence on access to compute. A hyperscaler carries T-AICOMPUTE; a compute futures position carries T-COMPUTEMKT; an entity that both consumes and trades capacity carries both.

3.10 Layer 6, risk, governance and policy tags

Multi-select tags in three families. These are the properties that mandates and living policy rules test against.

Risk (R-) | Code | Tag | Definition | |---|---|---| | R-CUSTODY-SELF | Self-custody risk | Holder bears direct custody of a bearer-like asset. | | R-CUSTODY-3P | Third-party custody | Asset held through a custodian with counterparty exposure. | | R-SMARTCONTRACT | Smart-contract risk | Exposure to failure of on-chain code. | | R-ORACLE-BRIDGE | Oracle or bridge risk | Exposure to failure of price oracles or cross-chain bridges. | | R-DEPEG | Stability or peg risk | Exposure to loss of a designed stable value. | | R-LIQUIDITY | Liquidity risk | Exposure to inability to transact at a fair price. | | R-CONCENTRATION | Concentration risk | Exposure concentrated in a single name, chain, or venue. | | R-MODELSAFETY | Model-safety risk | Exposure to unsafe or misaligned model behaviour. | | R-EXPORTCTRL | Export-control exposure | Subject to export controls on compute, models, or technology. | | R-PREREV | Pre-revenue | No established revenue; value is expectational. | | R-BASIS | Basis risk | The instrument settles against a reference that may diverge from the holder's actual exposure, so the hedge is imperfect by construction. | | R-CCP | Central counterparty exposure | Performance depends on a clearing house and its default waterfall. Distinct from R-CUSTODY-3P, which is custody of a held asset rather than novation of a contract. | | R-BENCHREF | Benchmark reference risk | Value depends on a settlement reference published by a single administrator, exposing the holder to methodology change, panel thinness, and administrator failure. |

Governance (G-) | Code | Tag | Definition | |---|---|---| | G-CENTRAL | Centralised control | Controlled by an identifiable central party. | | G-DECENTRAL | Decentralised governance | Governed by distributed on-chain or community process. | | G-FOUNDATION | Foundation-stewarded | Stewarded by a foundation or non-profit structure. | | G-STEWARD | Active stewardship object | Held with active stewardship or engagement rights. | | G-UPGRADEABLE | Upgradeable or mutable | Underlying code or terms can be changed by a controlling process. |

Policy (P-) | Code | Tag | Definition | |---|---|---| | P-REG-SEC | Securities-regulated | Treated as a regulated security in its primary jurisdiction. | | P-REG-BANK | Banking-regulated | Subject to banking or deposit regulation. | | P-REG-COMMOD | Commodity-regulated | Regulated as a commodity or commodity derivative. | | P-REG-UNCLEAR | Regulatory status unsettled | Regulatory classification is genuinely unresolved. | | P-SANCTION | Sanctions-sensitive | Exposed to sanctions regimes. | | P-ESG-EXCL | Common exclusion candidate | Commonly subject to exclusion under institutional policy. | | P-TAXSPECIAL | Special tax treatment | Subject to distinct tax treatment relevant to holding. |

---

Part 4. Special classification modules

Module A. Model weights and frontier models as assets

A trained model can be an asset in its own right, held, valued, licensed, and transferred independently of the entity that created it (named assumption A2). When it is, it is typed E-MODEL, placed on Layer 2 in domain K (usually K.02.xx), given a Layer 3 model form, and characterised by the attribute set below. The attributes are recorded as structured fields, not folded into the Layer 2 code, so that the code stays stable while the characterisation stays rich.

A.1 Model attribute set

Attribute	Values	Definition
Openness regime	closed, gated, open-weight, open-full	Degree of access: closed (no weights, API only), gated (weights under restricted licence), open-weight (weights public, licence may restrict use), open-full (weights and training pipeline open).
Primary modality	text, vision, audio, multimodal, action, bio, other	Dominant input-output modality. action denotes models whose primary output is control of tools or effectors.
Scale class	S, M, L, XL, frontier	Relative compute and parameter scale, from small (S) to the capability frontier. Scale class is relative and re-based each major version.
Licensing	proprietary, restricted-open, permissive-open, bespoke	Terms governing use, redistribution, and commercial exploitation.
Training-data profile	licensed, public, synthetic-heavy, proprietary, mixed, undisclosed	Dominant character of the training corpus.
Inference economics	hosted-metered, hosted-subscription, local-deployable, hybrid	How inference is delivered and paid for.
Agentic capability	A0, A1, A2, A3	Autonomy tier, defined below.
Provenance	issuing entity, base-model lineage	The developer and, for derivatives, the base model adapted from.

A.2 Agentic capability tiers

A deliberately coarse, four-point scale, because finer distinctions are not yet stable enough for deterministic labelling (named assumption A4).

• A0 Non-agentic. Produces outputs on request; takes no actions.
• A1 Tool-using. Invokes tools and returns results within a single bounded task under human oversight.
• A2 Workflow-autonomous. Plans and executes multi-step workflows with intermittent human checkpoints.
• A3 Economically autonomous. Holds resources, transacts, and pursues objectives over time with only exception-based human intervention.

A.3 Why the model is classified separately from its developer

The developer is an E-ISSUER classified by its economic activity (typically K.01.xx). The model is an E-MODEL classified at K.02.xx. This separation matters because the two carry different exposures: a developer's equity is exposed to the firm's whole book and cost base, while a specific model asset is exposed to its own openness regime, licence, and decay. A portfolio can hold one without the other (an open-weight model deployed locally, with no equity in its developer), and the standard must express that.

A.4 Autonomous agents

An agent that acts as an economic entity (holds resources, transacts) is typed E-MODEL where the agent is essentially a deployed model, or E-ISSUER where the agent is an operating service. It is placed at K.03.xx and carries the agentic-capability tier from A.2, plus the T-AGENTIC theme and, where it transacts on-chain, the T-ONCHAIN theme and relevant Layer 6 custody and smart-contract risk tags.

---

Module B. Token classification framework

Tokens are typed E-TOKEN and, before a Layer 2 leaf is assigned, are resolved along the four axes below. The axes determine both the correct Layer 2 placement and the Layer 3 form.

B.1 Economic rights matrix

The primary question is what the token entitles the holder to. A token may carry more than one right; the dominant right drives classification, the others become themes.

Right class	The holder is entitled to	Typical Layer 2 pull	Typical form
Cash-flow	A share of protocol fees or revenue	N.02 or the underlying activity	F-TOK-SEC or F-TOK-GOV
Governance	A vote over protocol parameters and treasury	N.05.01	F-TOK-GOV
Access or utility	Use of a service, compute, or resource	N.05.02 or the DePIN sector	F-TOK-UTIL
Collateral or security	A role securing a network or position	N.01 or N.02.04	F-TOK-NATIVE or F-TOK-RECEIPT
Unit of account	Stable redemption for a reference value	N.03	F-TOK-STABLE
Claim on external asset	Redemption for an off-chain asset or cash flow	Underlying activity (look-through)	F-HYB-TOKRWA
None (speculative or social)	No defined economic right	N.05.04 with explicit function tag	F-TOK-UTIL or F-TOK-NFA

B.2 Tradability and transferability spectrum

Recorded as an attribute, because it drives liquidity and custody risk independently of economic function.

• free Freely transferable and traded on open venues.
• permissioned Transferable only among allow-listed parties.
• restricted Transferable subject to lock-ups, vesting, or regulatory gating.
• soulbound Non-transferable by design (identity, credential, attestation).
• redeem-only Not traded; only created and redeemed against an underlying.

B.3 Primary economic function versus secondary attributes

A token's Layer 2 placement follows its dominant economic function from B.1, decided by the multi-label rules in Module C. Its other roles, its network, its DePIN category, its cultural context, are recorded as Layer 5 themes. This is what keeps a governance token that also earns fees from being double-counted: it is placed once, by its dominant right, and its other properties are tags.

B.4 On-chain native versus claim-based

The single most important token distinction for an institutional holder.

• On-chain native. The token is the asset. Its value originates in the protocol itself. It is classified in domain N by its function (B.1), typed E-TOKEN.
• Claim-based (tokenised real-world asset). The token is a representation of an off-chain asset or cash flow. Its value originates off-chain. It is classified by looking through to the underlying economic activity (a tokenised treasury bill is placed at M.05.03 or the sovereign issuer at R.01.01, not in domain N), typed E-HYBRID, carrying form F-HYB-TOKRWA on Layer 3 and the themes T-ONCHAIN and T-TOKENISATION, with on-chain risks recorded on Layer 6.

The test: if the public ledger vanished, would the economic value survive? If yes, it is claim-based and classified by the underlying. If no, it is on-chain native and classified in domain N.

---

Module C. Multi-label assignment rules

The rules that make classification deterministic (named assumption A4). Applied in order; the first that resolves the case wins.

C.1 The primary-spine rule (Layer 2)

Exactly one Layer 2 leaf per entity. Select it by dominant value origination: the single mechanism that accounts for the largest share of the entity's economic value or, where value is expectational, the largest share of the investment thesis.

• Operating companies (E-ISSUER). Dominant value origination is the primary revenue-generating activity. Where revenue is split, use the largest segment; where a company is defined by a strategic pivot not yet in revenue, classify by the activity the market is pricing and tag the legacy activity as a theme.
• Securities (E-SEC). Look through to the issuer. A bond or share is placed at the issuer's Layer 2 leaf, with the instrument on Layer 3. Exception: where the security's risk is genuinely detached from the issuer (a fully collateralised structured note), classify by the collateral's activity.
• Tokens (E-TOKEN). Dominant economic right from Module B.1.
• Models and agents (E-MODEL). Placed in domain K by function; developer classified separately.
• Funds (E-FUND). Placed by strategy in M.03, with the dominant underlying exposure recorded as a theme; where a fund is single-strategy and single-sector, the underlying sector may also be recorded for look-through.

C.2 The 60 percent guideline

Where value origination is quantifiable and no single activity reaches 60 percent, the entity is classified at the sector level (leaving the segment as .00) and the competing activities are recorded as Layer 5 themes. This prevents false precision. The .00 segment is reserved throughout for "sector, segment unresolved."

C.3 The look-through rule

For any entity that is a claim on another entity's activity (securities, tokenised RWAs, single-name derivatives, single-underlying funds), classify by the underlying activity, not by the fact of intermediation. Intermediation is captured on Layer 3 (form) and, where the intermediary itself is the investment, in domain M. This is the rule that stops everything financial from collapsing into "financials."

C.4 Theme assignment (Layer 5)

Every real exposure that is not the primary spine becomes a theme. Themes are generous by design: a company can carry many. The discipline is on Layer 2 (exactly one leaf), not on Layer 5. An open-weight model developer that runs its own compute and settles payments on-chain is placed once at K.01.03 and carries T-AICOMPUTE, T-OPENWEIGHT, and T-ONCHAIN.

C.5 Tie-breakers

Where two activities are genuinely equal: prefer the activity that (1) is more specific to the entity's identity, then (2) carries the greater risk exposure, then (3) sorts first by domain letter. The tie-breaker is deterministic so that two agents reach the same answer.

C.6 Derivative placement

Applied to entities typed E-DERIV, in order. The first branch that resolves the case wins.

1. Single-name underlying. Place at the underlying entity's Layer 2 leaf. C.3 applies unchanged.
2. Single-good underlying. Place at the leaf of the activity that produces or supplies the referenced good. A crude oil future is placed at A.05.01. A compute rental index future is placed at K.04.05.
3. Sector-spanning index. Where the referenced index spans segments within one sector, place at the sector with the segment unresolved (.00). Where it spans sectors within one domain, place at the domain with both unresolved.
4. Cross-domain basket. Where no single domain accounts for the dominant referenced exposure, place at Z.00.00, reserved for diversified derivative exposure with no dominant value-origination mechanism. The constituent distribution is recorded in deriv_attrs. Valid for E-DERIV only.
5. Rate, volatility, or event underlying. Where no produced good is referenced, place in domain M by the market the reference belongs to: M.05.01 for currencies, M.05.03 for short rates, M.04.01 where the reference is an exchange product with no other home.

Intermediation is never the classification. The venue, the clearing arrangement, and the settlement method are recorded on Layer 3 and in deriv_attrs, never on Layer 2. C.6 is C.3 extended to contracts that have no issuer to look through to.

---

Module D. Geography layer

D.1 What geography records

Geography answers "whose rules and whose economy." It is recorded at up to three grains: country, region, bloc. For most entities a single country suffices; region and bloc are derived from country by a fixed public mapping and populated automatically.

D.2 Assignment rules

• Operating companies. Primary geography is the country of principal economic activity, which is usually but not always the country of domicile. Where domicile and activity diverge materially (a holding company domiciled for tax in one country, operating in another), record activity as primary and domicile as secondary.
• Securities. Geography follows the issuer.
• Real assets. Geography is the physical location of the asset.
• Sovereign entities. Geography is the sovereign itself.
• Tokens and protocols. Most on-chain-native tokens have no meaningful legal domicile and take XN (jurisdictionless). Where a protocol is clearly operated and controlled from an identifiable jurisdiction, record that jurisdiction and add the governance tag G-CENTRAL. Where control is genuinely distributed, use XM (multi-jurisdiction) and record the distribution in the ingestion record.
• Claim-based tokens (RWAs). Geography follows the underlying off-chain asset, not the chain.
• Derivatives. Where the underlying has a geography, geography follows the underlying: a single-name derivative takes the issuer's country. Where the underlying is a global or distributed good with no dominant location, geography is the jurisdiction whose rules govern the contract, which for a listed contract is the exchange's jurisdiction, with the underlying's distribution recorded in deriv_attrs. The location of the physical capacity behind a capacity index is not a term of the contract and does not set geography.

D.3 Region and bloc codes

Region codes (RG-) partition the world into DAP regions; bloc codes (BL-) capture policy-relevant groupings that cut across regions. Blocs are multi-select because a country can belong to several. Both are DAP-defined vocabularies mapped from ISO country codes, so that the only externally sourced element is the public-domain ISO country list.

---

Module E. Derivative and reference-contract framework

A derivative is typed E-DERIV, placed on Layer 2 by Module C.6, given a Layer 3 derivative form, and characterised by the attribute set below. As with Modules A and B, the attributes are structured fields rather than code positions, so the code stays stable while the characterisation stays rich.

E.1 Derivative attribute set

Attribute	Values	Definition
Underlying class	entity, commodity, index, rate, basket, event	What the contract references. Drives the Module C.6 branch.
Settlement	cash, physical, mixed	Whether the underlying is delivered.
Venue and clearing	listed-cleared, otc-cleared, otc-bilateral	Where it trades and whether a central counterparty stands between the parties.
Reference administrator	entity, plus its own classification	Who publishes the settlement reference. Null for physically delivered contracts.
Term structure	dated, perpetual, rolling	Expiry behaviour. perpetual pairs with form F-DERIV-PERP.
Position sign	long, short	Recorded because a short position in a cost input is a hedge and a long is an exposure. The same contract reads differently in the two directions, and policy rules must be able to test the difference.
Notional basis	unit and multiplier	The physical or notional quantity one contract represents.

E.2 Placement

Layer 2 placement follows Module C.6. Layer 3 carries the derivative form. The venue, the clearing arrangement, and the settlement method are attributes, never the classification. Geography follows the derivative rule in Module D.2.

E.3 Why derivatives are typed separately

A derivative is not an issued claim. No issuer's balance sheet stands behind it, so the E-SEC look-through to an issuer does not apply. Its performance depends on the venue, the clearing house, and the integrity of a settlement reference, which are exposures no other entity type carries and which Layer 6 now records as R-CCP and R-BENCHREF. A portfolio can hold the exposure with no position in anything issued, and the standard must express that, on the same reasoning that separates a model asset from its developer in Module A.3.

E.4 The hedge direction problem

A cost-input derivative held short is a hedge; held long it is an exposure to the same cost rising. The classification vector is identical in both cases, because classification describes what an entity is rather than why it is held. Position sign is therefore an attribute, not a layer. Living policy rules that need to distinguish a hedge from a position read deriv_attrs.position_sign alongside the vector, not instead of it.

---

Part 5. Coding system, versioning and implementation

5.1 The DAP classification code (DCC)

A full classification is a vector across the six layers. The canonical string form:

K.01.03 | form:F-MOD-OPEN | geo:US | themes:[T-OPENWEIGHT,T-AICOMPUTE] | risk:[R-EXPORTCTRL,R-PREREV]

The grammar, chosen to be legible to humans and trivially parseable by machines, and deliberately unlike any numeric-only commercial scheme:

• Layer 2 leaf: Domain.Sector.Segment, one letter and two two-digit fields, e.g. K.01.03. The letter carries the domain so the code is self-describing at a glance. .00 in either position means "unresolved at that level."
• Reserved leaf: Z.00.00 denotes cross-domain diversified derivative exposure with no dominant value-origination mechanism (rule C.6.4). Z sits outside the A to R domain range and does not collide with the Layer 4 codes XN and XM, which are in a separate namespace.
• Layer 3 form: form: then one F- code.
• Layer 4 geography: geo: then ISO-2, RG-, BL-, XN, or XM.
• Layer 5 themes: themes: then a bracketed list of T- codes, or [].
• Layer 6 tags: risk: then a bracketed list of R-, G-, P- codes, or [].

Only the Layer 2 leaf is mandatory. Layers left null are omitted from the string but explicit as null in the data record.

5.2 Versioning convention

The standard versions as YYYY.MAJOR.MINOR, e.g. 2026.1 is the first release of the 2026 line; 2026.2 a minor revision; 2027.1 the next annual major.

• Major (annual, or on structural change): may add or restructure domains and sectors, and may change layer definitions. Every retired or moved code ships with a forward-mapping entry so historical classifications resolve into the new version. Major versions never silently repurpose an existing code.
• Minor (as needed): adds segments, themes, forms, and Layer 6 tags, and refines definitions without moving existing codes. Minor versions are purely additive to the code space.
• Continuity guarantee: a code, once issued, is never reassigned to a different meaning. It can be retired (with a forward map) but not reused. This is what lets a five-year backtest read a stable series (named assumption A4, and the living-taxonomy principle).

5.3 Suggested data fields for Overture ingestion

Each classified entity is stored as a record with at least these fields. The full JSON schema ships as the companion artifact dap-standard-2026.2-taxonomy.json.

Field	Type	Notes
entity_id	string	Stable internal identifier.
entity_type	enum	One of the eight E- types.
l2_leaf	string	The mandatory Layer 2 code.
l2_confidence	enum	high / medium / low, for agent-assigned labels.
form	string or null	Layer 3 F- code.
form_secondary	string or null	Where an instrument carries two forms.
geo_country	ISO-2 or null
geo_region	string or null	Derived from country.
geo_bloc	array	Derived; may be empty.
themes	array	Layer 5 T- codes.
risk_tags	array	Layer 6 R-, G-, P- codes.
model_attrs	object or null	Module A attribute set, for E-MODEL.
token_attrs	object or null	Module B axes, for E-TOKEN.
deriv_attrs	object or null	Module E attribute set, for E-DERIV.
std_version	string	The DAP Standard version used, e.g. 2026.2.
assigned_by	enum	human / agent / agent-reviewed.
provenance	object	Source facts and the rule path that produced the label.

The provenance field is required, not optional: it records which facts and which Module C rule produced the classification, so that a label is auditable and a disagreement is traceable to a fact or a rule rather than to opinion.

5.4 Mapping from public-domain standards only

Where an entity already carries a public-domain government activity code (in the spirit of ISIC, NAICS, or SIC), that code may be used as an input hint to the Layer 2 assignment, never as the assignment itself. The mapping is one-directional and advisory: a government activity family suggests a candidate domain and sector, which a classifier then confirms or overrides using the DAP definitions. No proprietary commercial classification is used as a mapping source, by design (named assumption A5). Government codes cover only traditional activity; the modern domains (K, L, N, and the model and token modules) have no government antecedent and are assigned directly from the DAP definitions.

---

Part 6. Worked examples

Each example shows the entity, its type, and its classification vector, with a one-line rationale. Names marked (hypothetical) are illustrative constructs; real entities are classified on public facts.

1. A Canadian chartered bank. Type E-ISSUER. M.01.01 | form:F-EQ-PUB-COM | geo:CA | themes:[] | risk:[G-CENTRAL,P-REG-BANK] Dominant value origination is retail and commercial banking; the listed shares are the form.

2. A copper miner's senior bond. Type E-SEC. A.04.02 | form:F-DEBT-SR | geo:CL | themes:[T-CRITMIN,T-TRANSITION] | risk:[R-CUSTODY-3P] Look-through rule (C.3): the bond is placed at the issuer's mining activity, not in financials. Transition-metal demand and criticality are themes.

3. A frontier model developer, closed. Type E-ISSUER. K.01.01 | form:F-EQ-PRIV | geo:US | themes:[T-AICOMPUTE,T-AIEXPOSED] | risk:[R-PREREV,R-EXPORTCTRL,G-CENTRAL] The company, not the model. Compute dependency and export-control exposure are the salient tags.

4. Closed frontier model weights held under licence. Type E-MODEL. K.02.01 | form:F-MOD-CLOSED | geo:US | themes:[T-AIEXPOSED,T-AGENTIC] | risk:[R-MODELSAFETY,R-EXPORTCTRL] Module A: openness closed, modality multimodal, scale frontier, licensing proprietary, inference hosted-metered, agentic A2. Classified independently of its developer (example 3).

5. An open-weight model asset deployed locally. Type E-MODEL. K.02.02 | form:F-MOD-OPEN | geo:XN | themes:[T-OPENWEIGHT,T-AIEXPOSED] | risk:[R-MODELSAFETY] Module A: openness open-weight, licensing restricted-open, inference local-deployable, agentic A1. Geography XN: once weights are public and deployed locally, no single jurisdiction owns the asset.

6. An autonomous treasury-management agent. Type E-MODEL. K.03.02 | form:F-MOD-OPEN | geo:XN | themes:[T-AGENTIC,T-ONCHAIN] | risk:[R-MODELSAFETY,R-SMARTCONTRACT,R-CUSTODY-SELF] Module A agentic tier A3: holds resources and transacts with exception-based oversight. On-chain action pulls smart-contract and self-custody risk.

7. A base-layer settlement network's native coin. Type E-TOKEN. N.01.01 | form:F-TOK-NATIVE | geo:XN | themes:[T-ONCHAIN,T-NETWORK] | risk:[R-SMARTCONTRACT,R-LIQUIDITY,G-DECENTRAL] Module B: right class is collateral/security (secures the network), tradability free, on-chain native. Value would not survive without the ledger, so it stays in domain N.

8. A fiat-backed stablecoin. Type E-TOKEN. N.03.01 | form:F-TOK-STABLE | geo:US | themes:[T-ONCHAIN] | risk:[R-DEPEG,R-CUSTODY-3P,G-CENTRAL,P-REG-UNCLEAR] Module B: unit-of-account right, tradability free. Issuer is identifiable and centralised, so a real jurisdiction and G-CENTRAL apply despite on-chain settlement.

9. A tokenised treasury bill. Type E-HYBRID. M.05.03 | form:F-HYB-TOKRWA | geo:US | themes:[T-ONCHAIN,T-TOKENISATION,T-REALYIELD] | risk:[R-SMARTCONTRACT,R-CUSTODY-3P,P-REG-SEC] The vanishing-ledger test (B.4): the treasury bill survives without the chain, so it is claim-based and classified by its underlying, not in domain N. The tokenisation is form and themes.

10. A DePIN distributed-compute network token. Type E-TOKEN. N.04.01 | form:F-TOK-UTIL | geo:XN | themes:[T-ONCHAIN,T-AICOMPUTE,T-NETWORK] | risk:[R-SMARTCONTRACT,R-LIQUIDITY,G-DECENTRAL] Module B: access/utility right (pays for and coordinates compute). Compute relevance is a theme, not the spine.

11. A governance token that also shares fees. Type E-TOKEN. N.05.01 | form:F-TOK-GOV | geo:XN | themes:[T-ONCHAIN,T-REALYIELD] | risk:[R-SMARTCONTRACT,G-DECENTRAL,P-REG-UNCLEAR] Two rights (governance and cash-flow). Module C.1 and B.3: the dominant right governs placement; the fee share becomes the T-REALYIELD theme rather than a second Layer 2 code.

12. A private-equity buyout fund. Type E-FUND. M.03.02 | form:F-FUND-LP | geo:US | themes:[] | risk:[R-LIQUIDITY,R-CONCENTRATION] Placed by strategy (buyout), not by the sector of any one portfolio company. Where the fund is concentrated in a single sector, that sector is recorded as a look-through theme in the ingestion record; a diversified buyout fund carries none.

13. A venture capital fund focused on AI infrastructure. Type E-FUND. M.03.03 | form:F-FUND-LP | geo:US | themes:[T-AICOMPUTE,T-AIEXPOSED] | risk:[R-LIQUIDITY,R-PREREV,R-CONCENTRATION] Strategy is venture; the AI-infrastructure focus is carried as themes so the fund is both findable as venture and as AI exposure.

14. A durable carbon-removal credit. Type E-REAL. P.01.03 | form:F-REAL-RESRIGHT | geo:IS | themes:[T-DECARB] | risk:[R-LIQUIDITY,P-REG-UNCLEAR] The environmental outcome is itself the traded asset, so domain P, not the removal facility's activity.

15. A dataset licence for a rights-cleared training corpus. Type E-ISSUER claim, form-led. L.01.04 | form:F-DATA-LIC | geo:US | themes:[T-DATASSET,T-AIEXPOSED] | risk:[P-REG-UNCLEAR] Value originates in the data asset itself, so domain L, with the licence as form.

16. A humanoid robotics manufacturer. Type E-ISSUER. B.04.02 | form:F-EQ-PUB-COM | geo:US | themes:[T-AIEXPOSED,T-AGENTIC,T-AUTODISPLACE] | risk:[R-PREREV,G-CENTRAL] Dominant value origination is manufacturing the platform (domain B); embodied AI and labour displacement are the themes that make it findable in an AI screen.

17. A tokenised-real-estate platform company. Type E-ISSUER. C.03.01 | form:F-EQ-PRIV | geo:AE | themes:[T-TOKENISATION,T-ONCHAIN] | risk:[R-SMARTCONTRACT,P-REG-UNCLEAR,G-CENTRAL] The platform's activity is real estate services; tokenisation is how it operates, recorded as themes. A specific property token issued on the platform is a separate E-HYBRID looked through to C.01.xx with form F-HYB-TOKRWA.

18. An inference-revenue note (hypothetical, invented category). Type E-HYBRID. K.02.04 | form:F-MOD-CLAIM | geo:XN | themes:[T-ONCHAIN,T-AIEXPOSED,T-REALYIELD] | risk:[R-SMARTCONTRACT,R-CONCENTRATION,P-REG-UNCLEAR] An on-chain note paying holders a share of a specific model's inference revenue. This asset class did not exist when older frameworks were written, and the standard classifies it with no new code: model rights claim (K.02.04, F-MOD-CLAIM), on-chain and real-world-yield themes, concentration and smart-contract risk. This is the extensibility test the standard is built to pass.

19. Overture itself. Type E-ISSUER (as a system). K.03.03 | form:null | geo:CA | themes:[T-AGENTIC,T-AIEXPOSED] | risk:[R-MODELSAFETY,G-STEWARD] The platform consuming this standard is a multi-agent orchestration system, and it classifies cleanly within the same scheme it reads. Form is null: it is a system, not a held claim.

20. A cleared compute rental index future. Type E-DERIV. (Added 2026.2.) K.04.05 | form:F-DERIV-FUT | geo:US | themes:[T-COMPUTEMKT,T-AICOMPUTE,T-AIEXPOSED] | risk:[R-BASIS,R-CCP,R-BENCHREF,R-LIQUIDITY] Module E: underlying commodity, settlement cash, venue listed-cleared, reference administrator the index publisher (example 21), term dated, notional one month of hourly rent for one accelerator unit. Rule C.6.2 places it at the activity supplying the referenced good rather than in domain M, so a compute hedge is findable in an AI-compute screen instead of disappearing into financials. Geography is the exchange's jurisdiction under D.2, not the distributed physical location of the accelerators. R-BENCHREF because a single administrator publishes the settlement reference; R-BASIS because a rental index will not track any one buyer's contracted rate.

21. The publisher of a compute rental benchmark. Type E-ISSUER. (Added 2026.2.) M.07.02 | form:F-EQ-PRIV | geo:US | themes:[T-AICOMPUTE,T-DATASSET,T-COMPUTEMKT] | risk:[R-CONCENTRATION,G-CENTRAL] The administrator of a settlement reference is classified by its own activity, benchmark provision, not by the good it prices. T-DATASSET because the benchmark is a licensed data asset in its own right. The pairing of examples 20 and 21 is the same separation Module A makes between a model and its developer: the contract and the party that prices it are different exposures, and a portfolio can hold either without the other.

22. A West Texas Intermediate crude oil future. Type E-DERIV. (Added 2026.2.) A.05.01 | form:F-DERIV-FUT | geo:US | themes:[] | risk:[R-CCP,R-LIQUIDITY] Included to demonstrate that C.6 is general rather than built for one instrument. A contract listed decades ago and a contract listing in October 2026 classify by the same rule, both at the activity that produces the referenced good. Module E: underlying commodity, settlement physical, venue listed-cleared, reference administrator null.

---

Part 7. Governance of the DAP Standard

7.1 Principles

• The standard is infrastructure, not a document. It is maintained as a versioned artifact with a machine-readable form, and every change is a versioned change with a forward map.
• Continuity is the first duty. No change may break the resolvability of a code ever issued. Retirement with a forward map is always available; silent repurposing never is (named assumption A4).
• Definitions before codes. A category exists when it has a precise, inter-rater-reliable definition, not when it has a name. A node that two classifiers cannot apply consistently is a defect to be split or redefined, regardless of how intuitive its name is.
• Public-domain lineage only. The standard's traditional coverage is checked against public government concepts; its modern coverage is original. No proprietary commercial scheme enters the lineage (named assumption A5).

7.2 Review cadence

• Minor review, quarterly. Additive changes: new segments, themes, forms, and Layer 6 tags, and definitional refinements that do not move existing codes. Ships as 2026.2, 2026.3, and so on.
• Major review, annual. Structural changes: new or restructured domains and sectors, layer-definition changes. Ships as 2027.1. Every structural change carries its forward map.
• Expedited review, on trigger. A genuinely new asset class that cannot be classified with existing codes triggers an out-of-cycle minor release. The inference-revenue note (example 18) is the kind of case the standard is designed to absorb without waiting, by using existing codes and themes; expedited release is reserved for cases where even that fails.

7.3 Rules for adding, splitting, retiring

• Adding. A new segment is added under an existing sector by minor version when a real exposure has no adequate leaf. It must ship with a definition and at least one worked example.
• Splitting. A leaf is split when classifiers reliably disagree on entities within it, or when a subset grows large enough to warrant its own definition. The original code is retired with a forward map to the split children; historical entities are re-pointed by the map, not silently moved.
• Merging. Two leaves merge when the distinction between them stops carrying economic meaning. The merged code is new; both originals retire with forward maps.
• Retiring. A leaf is retired when its economic activity ceases to be material. It is never deleted: it remains resolvable, marked retired, with a forward map to its successor or to its parent sector.

7.4 Ownership and change control

The standard is owned by Dartmouth Advisory Partners. Changes are proposed against the machine-readable schema, reviewed for continuity (does every retired code have a forward map?) and for definitional quality (can two classifiers apply the new node consistently?), and only then adopted into a numbered version. Overture consumes only adopted, numbered versions, never drafts, so that every classification an agent makes is traceable to a specific published version of the standard.

7.5 Current status

Version 2026.2 is published for review. It has not been adopted.

Adoption requires, and has not yet had: an independent review with its findings merged or rejected on the record; an inter-rater test demonstrating that two classifiers reach the same label from the same facts; a pilot against a real holdings universe; and sign-off by a named owner on a stated date.

Until those clear, the standard is a design, published so that it can be tested in the open. Comment, dispute, and correction are invited through the governance process in 7.1 to 7.4. Findings that survive review are merged into 2026.3.

The 2026.1 header read "adopted, living". Nothing had been adopted. That line was corrected in 2026.2 rather than carried forward, because a claim of adoption that cannot answer "adopted by whom, on what date, after what review?" fails in exactly the room where credibility matters most.

7.6 What changeset 01 demonstrated

Recorded because the governance process should keep its own evidence.

Worked examples 1 to 19 were chosen by the author of the taxonomy they test, which is circular by construction. The compute futures contracts behind changeset 01 are the first entity the author did not choose, and they exposed a structural inconsistency in a single pass: four derivative forms had shipped on Layer 3 with no entity type able to use them.

Two readings, both worth keeping. The unflattering one is that no amount of re-reading by the author was going to find it, and only an outside instrument did. The favourable one is that the gap was found, diagnosed, and closed additively, with no code moved and no historical classification invalidated, which is precisely what the versioning design exists to make possible.

Both readings point the same way: entities the standard did not choose are the only ones that prove coverage. Examples 20 and 22 belong in the inter-rater entity set for that reason.

Changeset 02, 27 August 2026. Assumption A6's break clause corrected so that the leaf K.04.05 rests on the observed compute unit rather than on any single exchange listing. No code moved or retired. Applied before publication of 2026.2.

---

End of DAP Standard 2026.2. Companion machine artifact: dap-standard-2026.2-taxonomy.json