1. Purpose, Applicability, and Conventions¶

1.1 Purpose¶

The Enterprise Decision Infrastructure Standard (short form: DI-Std™, retained for schema continuity) defines a fixed vocabulary, a causal measurement model, an object ontology, and a conformant method of assessment for organizational decision capability. It exists so that the structural conditions governing whether installed intelligence converts into realized capability can be named, measured, compared, and audited - across organizations, and within one organization over time.

1.2 Applicability - the AI-Enabled Legacy Organization¶

The prevailing narrative offers a binary: legacy organizations - stable, governed, slow to absorb intelligence - and AI-native organizations, built around AI from the ground up. For the enterprises that run the physical economy, the binary is a category error. They will not, and should not, rebuild themselves wholesale into AI-native form; their stability and governance are not defects to be removed but assets to be preserved. Standing still is not survivable either.

This standard is written for the third form - the most common one. The AI-Enabled Legacy Organization retains the stability and governance of an incumbent, applies AI-native design principles only to the capabilities that create competitive advantage, and runs different operating models for different decisions based on business risk and value. This is not a transition state. It is a stable architecture in its own right - and it requires a way to decide which decisions get the AI-native treatment, and to design, run, and audit those decisions differently from the rest. That requires a standard. This is the standard.

Nothing in this document requires, or recommends, that an incumbent organization become AI-native in form (§4.0).

1.3 Conventions¶

• Normative sections define requirements and carry conformance weight (§2-§10, Appendix A). Informative sections aid understanding (§11-§13, Appendix B).

• The key words shall, should, and may express requirement, recommendation, and permission respectively.

• Three vocabulary registers govern this document: the Core Equation governs accounting terms (§2.2); the Language Covenant governs condition terms (§3); the Decision Ontology governs object terms (§6). Defined terms are capitalized at first normative use.

• Citation of provisions. A provision of this standard is cited as DI-Std v1.0 §6.3, naming the version and the section. A design principle is cited by number as Principle 07, or as DI-Std v1.0 P07 where a compact form is needed. A finding that invokes a principle shall cite it in one of these forms (§9.1). Where a citation omits the version, the current version at the date of citation is understood.

1.4 How to use this standard¶

This standard serves four kinds of reader, and each enters at a different point.

A leader assessing their own organization should begin with the Core Equation (§2.2) and the causal model (§3.1) to establish the vocabulary, then read the maturity model (§8) to locate their organization's current level. The diagnostic path runs through the six dimensions of §5.2; a conformant instrument (§9.1) will produce an Execution Friction Index and a maturity position. The first useful output is not a score but a finding: which conditions are load-bearing, and in what sequence they must be addressed (§5.3).

A practitioner running a diagnosis should read §3 through §6 in order. The covenant (§3) fixes the language, the principles (§4) supply the law, the measurement model (§5) defines the scoring contract, and the ontology (§6) specifies what must be instantiated for each decision loop. Conformance requirements for assessment, instantiation, and redesign are set out in §9.1 and must be satisfied for work to be described as DI-Std conformant.

A team designing or redesigning decisions should work from the ontology (§6) and the decision loop (§7). Classify loops by reversibility and value, assign operating models per §6.3, and satisfy the instantiation requirements of §6.5. Principle 10 governs sequence: decisions and incentives are repaired before data and tools, and §6.5 makes this a condition of conformant redesign rather than a recommendation.

An implementer building tools should read §5.4, §9, §10, and Appendix A. The schema files are authoritative; the standard's text governs their interpretation. Machine-enforceable constraints appear in the object model - notably that the Decide stage may not be executed by a machine outside a defined bound (Principle 06, §6.1, §7.3).

Two reading notes apply to everyone. Normative sections (§2-§10, Appendix A) carry conformance weight; informative sections (§11-§13, Appendix B) aid understanding but impose no requirement. And this standard measures conditions, not people: a finding names a structural state, never an individual's performance. Assessments conducted or reported otherwise are not conformant with the intent of this document.

1.5 Status and governance (informative)¶

This standard is independently authored. Version 1.0 has not been ratified by a standards body, and no such body is claimed. It is published openly so that it can be used, cited, criticized, and implemented on its merits.

Nothing in this document depends on the authority of its author. The vocabulary is fixed so that it can be applied consistently (§3), the principles are stated so that findings can cite them (§4), the measurement model is specified so that any instrument may implement it (§5, §9.1), and the schemas are published under a permissive licence so that implementations need no permission. A standard earns its standing through use, not through endorsement.

Governance beyond a single author - a review process, an adopter register, or an independent maintainer - is a matter for later versions (§13), and will be adopted if and when the standard's use warrants it. Until then, revisions are made by the author, deliberately and infrequently: covenant terms are frozen for the life of a major version (§3.0), and each change is recorded in the version history.

Correspondence, implementation reports, and criticism are welcomed at victoria.hou@di-std.org. The evidentiary standing of this version is stated separately in §6.7.

2. Problem Statement and the Core Equation¶

2.1 The problem this standard addresses¶

The market for enterprise intelligence has concentrated on the supply side: models, platforms, compute, and talent. Supply is no longer the binding constraint. In large, established organizations, intelligence is now abundant and absorption is scarce.

Adoption is not absorption. An organization can deploy intelligence widely - licenses issued, copilots installed, pilots celebrated - while its ability to convert that intelligence into decisions, its decisions into execution, and its execution into enterprise value remains unchanged. The gap between what an organization has installed and what it can realize is structural. It does not close with additional deployment. In most incumbents, additional deployment widens it.

This standard exists because that gap has a shape, and anything with a shape can be measured. The purpose of DI-Std™ is to give the structural conditions that govern absorption a fixed vocabulary, a causal model, and a conformant method of assessment - so that two organizations, or one organization at two points in time, can be compared in terms that do not move.

2.2 The Core Equation¶

Realized Capability = Installed Capability − Structural Lag − Execution Friction

The Execution Friction Index is a measure of the friction condition; it is not a quantity in the Core Equation and shall not be used in arithmetic with Installed or Realized Capability (§2.2 Measurement Note).

The equation is the normative centre of this standard. Its four terms are defined as follows:

• Installed Capability - the intelligence, tooling, data, and talent an organization possesses. The terms are not expressed in a common unit and the equation is not evaluated numerically. Its function is to fix what is being measured and what suppresses it; the operational measures are defined in §5.

• Structural Lag - the capability an organization forfeits before any decision is attempted, because its operating design was built for an environment that no longer exists. Lag is a stock: the accumulated mismatch between designed structure and current requirement. It is present at rest.

• Execution Friction - the capability an organization loses in motion: the structural drag between a sound decision and an action that lands (§3.3). Friction is a flow: it is incurred each time the organization attempts to convert.

• Realized Capability - the remainder. The portion of Installed Capability that converts into decided decisions, executed execution, and enterprise value. Realized Capability is what performance actually reflects.

An organization’s intelligence shall be measured by Realized Capability, not Installed Capability (Principle 05). Assessments that report deployment counts, license utilization, or pilot volume measure the first term of the equation and are silent about the last.

The two subtrahends are distinct on purpose, because they demand distinct remedies. Structural Lag requires redesign; Execution Friction requires conversion repair. An organization that treats lag as friction will retrain its people to push against a wall. An organization that treats friction as lag will rebuild a structure whose conversion path was the actual break. Misdiagnosis between the two subtrahends is itself a measurable failure mode, and one this standard exists to prevent.

2.3 Why measurement must be structural¶

Execution Friction is felt everywhere and owned nowhere. Executives experience it as slowness, rework, stalled initiatives, and decisions that dissolve between meetings. Because the experience is diffuse, organizations habitually attribute it to people - capability gaps, change resistance, culture - and respond with training, communication, and replacement. The response fails reliably, because the load is generated upstream of the people who carry it.

DI-Std™ therefore measures conditions, not sentiments. The standard scores the structural conditions under which decisions are made - where authority sits, whether consequences return to deciders, whether governance enables judgment or substitutes for it, whether the human-AI boundary is explicit - and treats felt friction as the validating symptom of those conditions, not as the thing itself (§3.1).

Two of the measured conditions behave as root causes. Decision structure and incentive structure are load-bearing: where either is unsound, corrections applied downstream - to data, workflow, governance, or capacity - do not hold (Principle 10). The measurement model in §5 flags them accordingly: root-cause status governs diagnosis and the sequence of remediation, not the arithmetic of the index (§5.3, §5.6).

2.4 Measurement Note (normative)¶

The Core Equation is a structural accounting identity, not a numerical formula in this version of the standard. Its purpose in DI-Std™ v1.0 is to establish the causal relationship between Installed Capability, Structural Lag, Execution Friction, and Realized Capability, and to distinguish capability present from capability ultimately realized.

The four terms are not assumed in v1.0 to share a common unit, and the equation shall therefore not be evaluated through direct arithmetic subtraction. Version 1.0 operationalizes Execution Friction through the measurement model of §5 and establishes the assessment basis for Structural Lag in §5.5; Installed Capability and Realized Capability remain defined constructs without a measurement architecture in this version. No index published under this standard, including the Execution Friction Index, shall be represented as a quantity in the Core Equation.

A common measurement architecture for Installed and Realized Capability, together with the method for quantifying capability conversion between them, is reserved for a future major version (§13). That version will specify the required unit of analysis, evidence standards conformance suite, measurement instruments, calculation rules, and the conditions under which capability - conversion measures may be compared.

2.5 Scope of claims¶

DI-Std™ claims that the structural conditions it defines are measurable, comparable, and causally ordered. It does not claim to predict enterprise performance, and it is not a technology-readiness index. An organization may score well and fail for reasons outside decision structure; the standard’s claim is narrower and therefore durable: where the measured conditions are unsound, installed intelligence will not convert, regardless of its quality.

3. Normative Lexicon - the Language Covenant, v1.0¶

3.0 Covenant¶

This section fixes the eight terms of the Decision Infrastructure lexicon. The terms are frozen for the life of version 1. A term may be added, altered, or retired only at a major version, and only if it constitutes a load-bearing node in the causal model of §3.1. Terms that describe, illustrate, or dramatize - however useful - do not enter the covenant.

The covenant governs the condition vocabulary of this standard. The four terms of the Core Equation (§2.2) are defined normatively where the equation is stated; they are accounting terms, not conditions, and are governed there.

Wherever a DI-Std™ assessment, instrument, or derived work uses one of these terms, it shall carry the meaning defined here.

3.1 The causal model¶

The lexicon is not a glossary. It is a causal system, read as one sentence:

In incumbents adopting AI, structural conditions determine the state of an organization’s Decision Infrastructure, which manifests as observable Execution Friction against a background of accumulated Structural Lag; Adaptive Renewal governs whether that state is improving or decaying.

Three structural choices in this model are deliberate. Execution Friction is a symptom, not a scored input: it is what executives feel, and its correlation with the scored conditions is what makes the standard persuasive rather than circular. Structural Lag is a stock where friction is a flow: the two are assessed by different methods and remedied by different work (§2.2). Adaptive Renewal is a trajectory, not a snapshot: it makes every assessment temporal, which is the property flat maturity checklists cannot capture.

3.2 Decision Infrastructure¶

Definition (normative). The organizational container that determines whether intelligence becomes decisions, decisions become execution, and execution becomes enterprise value. It comprises the allocation of decision rights, the architecture of accountability and consequence, the explicit human-AI division of labor, and the mechanisms by which the system renews itself.

Position in the causal model. The composite state. Every other term in the covenant either conditions it, evidences it, or modifies it over time.

What it is not.

• Not the IT estate, the data platform, or any technology layer.

• Not governance volume. An organization can be heavily governed and infrastructurally hollow.

• Not culture. Infrastructure is designed and inspectable; culture is emergent.

Observable indicators.

• A decision of consequence can be traced to a named owner, a defined input set, and a recorded commitment.

• When an AI system’s recommendation is overridden, the override is captured and routes somewhere.

• New intelligence changes decisions within a defined interval, rather than joining a queue.

3.3 Execution Friction¶

Definition (normative). The structural drag between a sound decision and an action that actually lands: unclear ownership, absent capacity, sequencing that fights work already in motion. Friction is load generated by organizational design, borne by the people inside it, and incurred as a flow - each time the organization attempts to convert intelligence into action.

Position in the causal model. The symptom and validating output of the model. Felt by executives; measured separately from the scored conditions (§3.1). Second subtrahend of the Core Equation.

What it is not.

• Not incompetence. Friction persists through hiring cycles and reorganizations that change the people.

• Not resistance. Resistance opposes a decision; friction consumes one that nobody opposes.

• Not Structural Lag. Lag is what the design already forfeits at rest; friction is what conversion loses in motion (§2.2).

• Not a synonym for slowness. Some slowness is deliberate infrastructure (Principle 07).

Observable indicators.

• Decisions re-litigated after commitment, without new information.

• Approved initiatives that stall in handoff, not in approval.

• Workarounds and shadow processes that outperform the sanctioned path.

3.4 Alignment Drag¶

Definition (normative). The cost incurred when a decision must cross functions, KPIs, and regions before anyone can act: coordination that dilutes the decision and delays the action, without any party being wrong.

Position in the causal model. Scored condition (reverse-scored: more drag, lower state).

What it is not.

• Not disagreement. Drag occurs among parties who agree.

• Not a communication problem. More communication is frequently its accelerant.

Observable indicators.

• Decisions that require assembling the same cross-functional group repeatedly to stay decided.

• KPI structures under which a decision that is right for the enterprise is locally penalized (Principle 09 boundary).

• Regional or functional translation layers that each hold partial veto.

3.5 Governance Substitution¶

Definition (normative). The condition in which committees, reviews, and sign-offs stand in for judgment instead of enabling it: control masquerading as decision-making. Approval activity rises while decision ownership falls.

Position in the causal model. Scored condition (reverse-scored). Law form: Principle 04 - approval is a cost; judgment is the control.

What it is not.

• Not governance itself. Governance that assigns judgment to a name enables; governance that distributes judgment across a committee substitutes.

• Not risk management. Substitution frequently increases risk by ensuring no one owns it.

Observable indicators.

• Decisions with many approvers and no identifiable decider.

• Review gates that can stop a decision but cannot improve one.

• A governance calendar that paces decisions regardless of signal.

3.6 Decision Exposure¶

Definition (normative). The condition in which the organization is unprotected because no one owns a decision end-to-end - most acutely where output quality is probabilistic and machine recommendations enter the flow of work.

Position in the causal model. Scored condition. The gap that AI adoption does not create but reliably reveals.

What it is not.

• Not a staffing gap. Exposure persists at full headcount.

• Not the same failure as friction: friction slows a decision someone owns; exposure means no one owns it at all.

Observable indicators.

• Decisions identifiable only as “the process” or “the committee” when traced.

• AI-assisted outcomes for which accountability is asserted by no role and disclaimed by all.

• Escalations that travel laterally, seeking an owner rather than a resolution.

3.7 Human-AI Operating Model¶

Definition (normative). The explicit division of labor between human and machine: what AI may recommend, what humans must judge, where escalation is mandatory, and who remains accountable. Law form: Principle 06 - machines may recommend; only a named owner commits.

Position in the causal model. Scored condition. The boundary carries the safety property; where it is implicit, the default posture is whichever behavior feels personally safest.

What it is not.

• Not a tooling choice or deployment architecture.

• Not a compliance document. A model that exists on paper but not in the flow of decisions scores as absent.

Observable indicators.

• For each AI-augmented decision class, authority (execute / recommend / escalate) is written down and known.

• Overrides are captured as signal and route to recalibration (of the model or of the boundary).

• Autonomy expands and contracts by defined conditions, not by incident and anecdote.

3.8 Adaptive Renewal¶

Definition (normative). The system’s capacity to learn, self-correct, and rebuild capability - to escape yesterday’s operating logic without external shock. Renewal is measured as trajectory: the direction and rate of change in the scored conditions.

Position in the causal model. Trajectory modifier. Applied over the composite state, not summed into it (§3.1).

What it is not.

• Not change volume. Perpetual reorganization can be renewal’s opposite: motion substituting for learning.

• Not resilience. Resilience returns a system to its prior state; renewal revises the state.

Observable indicators.

• Post-decision reviews that change the decision system, not only the decision.

• Retired committees, sunset processes, deleted gates - evidence the system can subtract.

• Repeat assessments that move, in either direction, for reasons the organization can name.

3.9 AI Adoption in Incumbents¶

Definition (normative). The problem domain of this standard: why scaled, resource-rich organizations find intelligence hardest to absorb. The Incumbents’ Paradox - the assets that made scale an advantage (structure, process, control) are the same assets that now generate lag and friction.

Position in the causal model. Context. Frames every assessment; never scored.

What it is not.

• Not an industry segment. Incumbency is an operating condition, not a sector.

• Not a maturity insult. The paradox is a property of accumulated success, not of failure.

Observable indicators.

• Applies wherever the organization being assessed predates the intelligence being adopted.

3.10 Adjacent instruments and equation terms¶

HACT™, CORE™, the Structural Lag Index, AI Absorption Capacity, and DC-08 (Capability Through Consequence) are prior and adjacent instruments of the same practice. They are not covenant terms. Where this standard touches their territory - accountability architecture, absorption measurement, human-AI teaming - the covenant term governs, and the instrument is cited in §12 (Lineage) as provenance.

Structural Lag, now a term of the Core Equation, is defined normatively in §2.2 and assessed under §5.5. The Structural Lag Index - the prior instrument of the same name - remains a lineage citation; its modernization into a DI-Std™-conformant instrument is roadmap material (§13).

4. Design Principles¶

4.0 Standing and applicability¶

The ten principles below are normative. They are the law layer of this standard: horizontal rules that hold across every layer of the Decision Ontology (§6), every level of the maturity model (§8), and every stage of the decision loop (§7).

These are the principles of AI-native organization design - the design grammar. The AI-Enabled Legacy Organization (§1) applies this grammar selectively, to the capabilities where competitive advantage lives. The principles define how to build; the applicability statement of §1 defines where. Nothing in this section requires, or recommends, that an incumbent organization become AI-native in form.

Each principle carries its anchor in this standard. An assessment finding that cites a principle shall cite it by number.

4.1 The Ten Principles¶

01 Organizations are designed for decisions, not processes.

组织为决策，而不是流程设计。

02 Decision rights follow consequence-bearing capacity, not knowledge location.

决策权跟随后果承载能力，而非知识所在。

03 Knowledge belongs to the system. Accountability belongs to a name.

知识属于系统，责任必须落实到具体的人。。

04 Approval is a cost. Judgment is the control.

审批是一种成本，判断力才是真正的控制。。

05 Intelligence is measured by realized capability, not installed capability.

衡量智能的标准，不是已安装的能力，而是已经实现的能力。

06 Machines may recommend. Only owners commit.

机器可以提出建议，唯有责任人能够作出承诺。

07 Reversible decisions deserve speed. Irreversible decisions deserve infrastructure.

可逆的决策，值得快速推进；不可逆的决策，值得为其建立基础设施。。

08 A decision without a deadline is a decision not to decide.

没有截止期限的决策，本质上就是选择不做决定。

09 Consequences must return to the decider. Where they do not, theatre grows.

决策的后果必须回到决策者身上。否则，表演就会滋长。

10 Fix decisions and incentives before data and tools. The reversed order will not hold.

先修正决策机制与激励机制，再处理数据与工具。顺序一旦颠倒，改变就无法持久。

4.2 Coverage map¶

The ten principles are non-overlapping by construction. Each governs one law domain and anchors to one part of the standard:

Principle 08 defines a deadline as a latency bound on a decision, set by signal and exposure - not as calendar pacing. Read with §7, it is the counterpart of moving from calendar to signal, not its contradiction.

5. The Measurement Model¶

5.1 Two subtrahends, two measurements¶

The Core Equation names two distinct losses, and this standard measures them by two distinct methods:

• Execution Friction (flow) is measured by instrument: structured assessment of the conditions under which the organization converts decisions into action, producing a friction profile and index (§5.2-§5.4).

• Structural Lag (stock) is measured by review: a design-against-requirement comparison that establishes how much capability the current structure forfeits at rest (§5.5).

An assessment that conflates the two shall not be represented as DI-Std™ conformant. The distinction is not academic: it determines whether the remedial agenda is redesign or conversion repair (§2.2).

5.2 Conditions and dimensions - one system, two views¶

The covenant (§3) defines conditions: what is structurally true of the organization. The assessment instrument interviews through six dimensions: where friction is felt in the flow of work. The two are views of one system, related as follows:

The counts differ by design. Some dimensions detect a condition directly; others are collection surfaces for evidence about conditions that manifest across several of them. Data, Workflow, and Capacity are surfaces of this kind - no condition is named for them, because none is structurally distinct at the condition level. Incentive is the exception in the other direction: it detects consequence return (Principle 09, and the Consequence Return Time property of §6.2), which the covenant carries as a measured property rather than as a named condition. A dimension is a place to look; a condition is a thing that is true.

5.3 The causal load model¶

Decision and Incentive are load-bearing: they are the two dimensions through which every other dimension’s remediation must pass (Principle 10). The measurement model encodes this as follows:

• Where either load-bearing dimension scores at or above the root threshold specified in the current DI-Std v1.0 parameter set, the assessment shall flag it as a root condition, and the reported diagnosis shall state that downstream remediation - data, workflow, governance, capacity - will not hold until the root clears.

• Root-cause status affects diagnosis and sequencing. It does not inflate the index arithmetically in v1.0; the flag is an interpretation layer, not a weight.

5.4 Scoring contract¶

A conformant friction assessment satisfies the following contract:

• Items are scored on a 0-4 severity scale, anchored per item, across the six dimensions of §5.2.

• Dimension scores normalize to 0-100. The Execution Friction Index (EFI) aggregates dimension scores to a single 0-100 flow measure.

• EFI bands - Frictionless, Flowing, Strained, Blocked - each carry an expected maturity correlate (L3 → L0 respectively). The correlate is not a criterion: maturity level is determined by the criteria of §8.1 alone. Where the level held and the band's correlate diverge, the divergence shall be recorded as a finding.

• Every assessment emits a record conforming to the vh.di-std.assessment-record schema (§9), regardless of the instrument that produced it.

• Adaptive Renewal is not scored at a single assessment; it is derived from the delta between successive conformant assessments (§8.2). A first assessment reports renewalTrend as first-assessment.

The Decision Infrastructure Index (DII) - the composite condition-level index - is deferred to v1.1 by design. Version 1.0 establishes the measure; the index is published when the benchmark pool can give it comparative meaning. The yardstick precedes the score.

5.5 Assessing Structural Lag (v1.0 method)¶

Version 1.0 assesses Structural Lag by structured review rather than by index. The review establishes, for the same six dimensions of §5.2, the gap between the operating design as built and the requirement set the organization now faces. The output is a lag register: a named list of standing mismatches, each with the capability it forfeits and the redesign it implies.

A quantitative lag index, and the modernization of the prior Structural Lag Index instrument into DI-Std™ conformance, are roadmap items (§13). The stock is named in v1.0; it is scored in a later version, for the same reason the DII waits: a stock index without comparative data is a number in costume.

5.6 The scoring kernel¶

The scoring contract of §5.4 fixes what is measured. This section fixes how it is computed, so that two conformant instruments given identical input produce identical output. Without this, an Execution Friction Index is not a shared unit and the benchmark cannot compare anything.

Structure and parameters are separated. The kernel structure - normalization, aggregation, band assignment, root flagging, the missing-data rule and the rounding rule - is normative and fixed for the life of version 1. The kernel parameters - band thresholds, the root threshold, and the minimum instrument requirements - are conventions adopted at v1.0 for determinism. They are not derived from benchmark data, and their calibration is roadmap material (§13). Parameters are published separately and versioned separately so that calibration does not disturb the structure.

Normalization. Items are scored on the anchored 0-4 severity scale of §5.4, higher being worse. A dimension score is the arithmetic mean of its scored items, normalized to 0-100 by dividing by the scale maximum.

Aggregation. The Execution Friction Index is the weighted mean of the six dimension scores. Weights are equal at v1.0: root-cause status affects diagnosis and sequencing, never the arithmetic (§5.3). The mean is computed on full-precision dimension values and rounded once at emission; it is not computed from already-rounded dimension scores.

Bands. The EFI is assigned to one of four bands by the published thresholds, lower bound inclusive, upper bound exclusive, with the final band inclusive at 100. Band assignment uses the rounded EFI.

Root flagging. A load-bearing dimension - Decision or Incentive - scoring at or above the root threshold is flagged as a root condition. The flag is an interpretation layer and shall not alter the index.

Missing data. Unscored items are omitted from the dimension mean and never imputed. A dimension with fewer than two scored items is not scored, and an assessment in which any dimension is unscored shall not emit an EFI. Every conformant record declares item coverage per dimension.

Rounding. Rounding is half-up. Dimension scores and the EFI are rounded to one decimal place at emission; all intermediate arithmetic is performed at full precision.

Minimum instrument requirements. A conformant instrument carries at least three items per dimension and at least eighteen in total, and each item carries written behavioural anchors for at least levels 0, 2 and 4. Levels 1 and 3 are interpolations between adjacent anchors. An instrument with fewer items, or with unanchored levels, is not conformant however it computes.

A reference implementation of the kernel, its v1.0 parameter values, and a conformance suite are published alongside this standard. An instrument is kernel-conformant when it produces output identical to the reference kernel for identical input.

6. The Decision Ontology¶

6.0 Standing¶

Enterprise software has already proven the value of modelling an organization as a system of typed objects. Palantir’s ontology takes business entities as its objects - trucks, orders, customers - and models how the business runs. Operational ontologies of this kind model data, logic, and action under a permissions layer. It tends to answer: “How do we computationally represent and operationalize a decision?”

The Decision Ontology takes decisions as its objects and models how the organization decides. It is closer to: “What must structurally exist for this decision to work inside an organization?” That is the entire difference, and it is decisive: the decision layer is the one layer the computational & operational ontology leaves untouched - undefined, unmeasured, un-auditable. This section defines it.

Distinction between Palantir Ontology and Decision Ontology:

The ontology is built in four layers. Layer 1 defines the objects (the vocabulary). Layer 2 defines their measurable properties (the physics). Layer 3 assigns differentiated operating models (the differentiation). Layer 4 pools instantiated ontologies into the benchmark (the compounding asset, governed by §9-§10). Layers 1-3 are normative and open; Layer 4 is closed by design.

Vocabulary registers, completed: the Core Equation governs accounting terms (§2.2); the covenant governs condition terms (§3); this section governs object terms - Decision Loop, Stage, Owner, Signal, Consequence, Operating Model, Consequence Return Time. Wherever a conformant artifact uses an object term, it shall carry the meaning defined here.

6.1 Layer 1 - the object model¶

Decision Loop - the atomic object. A recurring commitment the organization must make. A loop carries the seven stages of §7 - Sense → Remember → Recommend → Decide → Override/Learn → Act within bounds → Simulate - exactly one Owner, a reversibility class (I / II / III), and an operating model assigned under §6.3.

Stage. A segment of a loop, executed by an agent: Human, Machine, or Hybrid. Constraint (normative): the agent of the Decide stage shall be Human, or Hybrid with a named human. Machines may occupy any other stage; Decide is reserved (Principle 06).

Owner - the party bearing the consequence. Attributes: role (anonymized in any pooled record), authority basis, incentive alignment. Constraint (normative): exactly one Owner per loop. Zero owners constitutes a Decision Exposure defect (§3.6). Multiple owners constitutes an Accountability Diffusion defect.

Signal. An input to the Recommend stage, carrying source, latency, trust level, and agent.

Consequence. The outcome and its return path. Consequences are captured at the Override/Learn stage; attribute returns To names the Owner the consequence reaches, and a null return path flags the loop as consequence-open - the condition under which theatre grows (Principle 09).

Autonomy Bound. The explicit, falsifiable condition under which the system may act without human review. A bound is a specific, testable statement, attributed to the owner who set it and dated - not a general level of confidence in a model. Every M1 loop shall carry one: under M1 the machine commits, and defining the bound is the owner's advance act of deciding (§6.3, Principle 06). A bound carries the date it was last tested in simulation before being widened (Principle 07).

Override. A divergence between a machine recommendation and the human decision, captured at the Override/Learn stage. An override records one of three reasons - the model was wrong, the context was incomplete, or the decider was wrong - and the destination to which it was routed: model recalibration, boundary revision, coaching, or no action. The classification is load-bearing: treating every override as evidence that the model needs adjusting tunes the system toward the preferences of deciders who were, in the case captured, simply wrong. An override captured and routed nowhere is not a closed loop.

Relationships. Relationship edges connect loops to loops, and nothing else. Two types are defined: triggers, where one loop's Act within bounds becomes another's Sense; and dependsOn, where one loop cannot complete without another. Through these two edges, individual loops compose into the decision graph - the queryable object graph that is the organization's true operating structure, of which the organization chart is only a projection.

Three relations that appear to belong here do not, because they are already expressed structurally: ownership is carried by the loop's single owner attribute, consequence return by the Consequence object's returnsTo, and signal consumption by the Signal object's loop reference. Modelling these as edges would allow an instantiation to assert an ownership that contradicts the loop's own owner field. They are held in one place each, deliberately..

Loop granularity (normative). What counts as one Decision Loop, against what is merely a step inside one, is settled by a three-part test: does it have its own Decide moment, its own Owner, and its own Consequence? All three - a loop. Fewer - a stage or an execution decomposition within a loop. A carrier-switch process whose evaluation, cross-functional alignment, confirmation, and downstream order revisions span six working steps is one loop: evaluation and alignment live inside Sense-Recommend, confirmation is the Decide moment, and every step after it is decomposition within Act within bounds. Complexity lives inside stages; loops stay countable.

Participants (attribute). Each instantiated stage carries a participant count and a set of anonymized role types (§10). Participants make coordination cost countable: the sum of stage-level touches per cycle is the direct observable of Alignment Drag (§3.4), and stages that combine high participation with machine-holdable work are the primary candidates for AI leverage (§5.2, Data and Capacity dimensions).

Defect taxonomy: Decision Exposure (zero owners) and Accountability Diffusion (multiple owners) are defect findings local to this section. Defects are findings, not conditions; they do not enter the covenant.

6.2 Layer 2 - the measurement physics¶

Every Decision Loop carries six measurable properties. These are the audit fields - the reason the ontology is scoreable, not merely descriptive:

Observed values and designed values are recorded separately. The six properties above are observations: what the loop does. A conformant instantiation also records what the loop is designed to do - a latency bound on the Sense-to-Decide interval, and a target Consequence Return Time. The two are never conflated and never inferred from one another. A loop with no stated latency bound is a decision not to decide (Principle 08); an operating-model assignment without a stated CRT target is not conformant (§6.5). The gap between the designed and the observed value is the measurement the redesign is aimed at; without both figures there is no gap to measure

Two organization-level metrics derive directly from the instantiated ontology. The Execution Friction Index aggregates as defined in §5.4. The Consequence Closure Rate - the percentage of loops with finite CRT - is treated in v1.0 as the primary structural indicator in this standard of whether capability or theatre is growing (Principle 09; DC-08 lineage, §12).

Measurement altitudes, reconciled: the ontology measures at loop level (the six properties above); the instrument interviews at dimension level (§5.2); the covenant states findings at condition level (§3). Loop properties are the micro-evidence, dimensions the collection plan, conditions the law. One system, three altitudes - a conformant assessment can traverse all three and shall not contradict itself across them.

Where loop-level evidence and dimension-level scoring diverge, the assessment shall report the divergence rather than resolve it silently; loop-level evidence is the more specific and shall be cited in the finding.

6.3 Layer 3 - operating models¶

An AI-Enabled Legacy Organization does not run one operating model. It classifies each decision loop by reversibility × value and assigns one of four models.

For the purpose of operating-model assignment, classes I and II are reversible and class III is irreversible. The distinction between I and II does not change the assignment; it governs how much conversion repair a loop can absorb before recovery costs exceed the value at stake.

Materiality is declared, not assumed. Decision value is organization-relative: a sum that is trivial in one enterprise is existential in another. A conformant assessment therefore declares one materiality threshold for its scope - a value, a unit, and the basis on which it is measured - and applies it consistently to every loop assessed. A loop whose value at stake meets or exceeds the threshold carries decisionValueClass High; below it, Low. The same declared threshold determines which loops and which domains are material for the purposes of the maturity model (§8.1). An assessment that reports a maturity level without a declared threshold is not conformant, because the phrase material loop would carry no fixed meaning.

This layer converts the thesis of §1 into an audit test. An AI-Enabled Legacy Organization is defined, precisely, as one that has classified its decision loops and assigned differentiated operating models - rather than applying one governance model uniformly (the legacy failure) or attempting to make every loop AI-native (the transformation fantasy). An organization either holds this classification, or it does not.

6.4 Layer 4 - the benchmark¶

Each conformant assessment instantiates one organization’s decision ontology as structured data (§9). Anonymized and pooled under the two-store architecture (§10), these instances form a cross-organization benchmark of decision quality - an object of a kind that does not currently exist. The schema is open and spreads the vocabulary; the benchmark is closed and compounds. Nothing further in this section is normative; the benchmark’s governance lives entirely in §9-§10.

6.5 Instantiation requirements¶

A conformant instantiation of the ontology satisfies the following, independent of who performs it:

• Every loop in scope carries all six properties of §6.2, an Owner per §6.1, and an operating-model assignment per §6.3.

• No operating-model assignment is valid without a named (if anonymized) Owner and a stated CRT target.

• No redesign recommendation may target a downstream dimension while a root-cause friction (§5.3) in the same loop remains unresolved. This enforces Principle 10 at the point of delivery.

• Every M1 loop carries a stated autonomy bound attributed to its owner (§6.1).

• Every loop carries both its observed properties and its designed targets (§6.2).

6.6 Falsifiability¶

This standard states its own refutation condition. If, across the accumulated benchmark, decision-loop CRT and operating-model fit show no relationship with realized AI value, the standard is wrong. The benchmark exists to test this claim, not only to sell against it.

The Execution Friction Index (EFI) and the conditions are derived from the same interview. Independently validating the relationship between them requires comparing EFI against external implementation metrics - such as cycle time, measured decision delay, and project implementation rate. This forms part of the benchmark-pool work described in §13.

6.7 Evidentiary status of this version¶

A standard should state what stands behind its claims, plainly. At version 1.0, the evidentiary standing of DI-Std™ is as follows:

• Structural reasoning. The causal model (§3.1), the ten principles (§4), and the ontology (§6) are derived from two decades of direct observation of decision systems inside large multinational organizations, and from the theoretical inversion stated in §12. They are reasoned, not yet statistically validated.

• Synthetic demonstration. The reference simulation (§11) applies the full standard to a rigorously constructed synthetic organization. It is labelled as synthetic wherever it appears. Its purpose is instruction, not proof.

• Anonymized structural patterns. Illustrative failures cited in this standard and its companion works are real observed organizational patterns, de-identified beyond attribution. No client data, past or present, appears in this document.

• Empirical validation. Accrues through the benchmark (§6.4, §10) as conformant assessments pool, and through permissioned client cases published in later versions and in the companion volume (§12). Version 1.0 is the instrument that generates this evidence; it does not claim to already possess it.

This ordering - instrument first, evidence accruing - is the ordering of every measurement standard at its first version. A yardstick is not validated by the lengths it has already measured; it is validated by being fit to measure. Readers are invited to hold this standard to its own falsifiability condition (§6.6) as the benchmark fills.

7. The Decision Loop - Reference Process Model¶

7.0 Standing¶

The loop defines how a single decision should travel. It is the stage vocabulary every Decision Loop object carries (§6.1) and the frame within which the latency bound of Principle 08 is set. A deadline, in this standard, is a latency bound on the Sense → Decide interval, set by signal and exposure - not calendar pacing. Read this way, the loop is the counterpart of moving from calendar to signal, not its contradiction.

7.1 The seven stages¶

The loop closes: Simulate feeds Sense and Remember, and the Consequence object (§6.1) returns to the Owner through Override/Learn regardless of where in the cycle the outcome lands. A loop whose consequences never complete this return is consequence-open, whatever its process diagram claims (Principle 09).

7.2 Stages under the four operating models¶

The operating model assigned in §6.3 determines which stages machines may hold:

7.3 Conformance¶

• A conformant loop instance names its stages using the vocabulary of §7.1 and records, at minimum: the agent of each stage, the Sense → Decide latency, and the override capture of stage 5.

• A loop classified Class III without an instantiated Simulate stage is a recordable defect: the instance is valid, the defect shall be declared, and the assessment shall carry a corresponding finding under Principle 07.

• A loop in which the Decide stage is executed by a machine outside a pre-defined M1 bound is a recordable defect: the defect shall be declared, and the assessment shall carry a corresponding finding under Principle 06, regardless of outcome quality.

8. The Maturity Model¶

8.0 Standing¶

Maturity in this standard is a statement about structure, not sentiment: what the organization can trace, measure, and differentiate. Four levels. Each level presumes every criterion of the levels below it; an organization holds a level only while all lower criteria continue to hold. Organization-level maturity shall be reported as the level held by its material decision domains - not by its best domain.

Throughout this section, material means at or above the materiality threshold declared for the assessment scope (§6.3).

8.1 The four levels¶

Maturity level is determined by the criteria alone. The instrument reading is an expected correlate, not a criterion; a divergence between them is itself a finding.

8.2 Reading maturity with trajectory¶

A maturity level is a position; Adaptive Renewal (§3.8) is its derivative. A conformant report states both: the level held, and the direction and rate of movement since the prior assessment. Two organizations at L1 - one instrumenting its first domain, one whose census is quietly rotting - are different cases, and the report shall distinguish them.

9. Conformance and Assessment Records¶

9.1 Conformance classes¶

This standard defines five conformance classes. Each is verifiable from artifacts alone:

• Conformant assessment record - validates against the schemas of Appendix A; satisfies the scoring contract of §5.4; and is internally consistent across the three measurement altitudes of §6.2.

• Conformant instrument - interviews through the six dimensions of §5.2 with anchored 0-4 items, implements the causal load flag of §5.3, and emits a conformant assessment record.

• Conformant instantiation - satisfies §6.5: complete properties, single owner, and operating-model assignment for every loop in scope.

• Conformant redesign - satisfies §6.5 and §7.3: no downstream recommendation over an unresolved root cause; findings cited by principle number.

• Kernel-conformant instrument - satisfies the conformant-instrument class and, in addition, produces output identical to the reference kernel of §5.6 for identical input, verified against the published conformance suite.

9.2 Records and schemas¶

Every conformant activity emits structured data. Three schemas govern (Appendix A): di-std.objects.v1.json - the object model of §6.1 and §7.1; di-std.assessment.v1.json - the full assessment instance, including dimension scores, EFI, maturity level, root-cause flags, and the lag register of §5.5; and vh.di-std.assessment-record - the interchange record instruments emit. Records are versioned; a record names the schema version it conforms to.

9.3 Declaration¶

An organization or practitioner may self-declare conformance for a named artifact, provided the artifact and its records are retained for the life of the standard version cited and producible on request to any party relying on the declaration. The phrase “DI-Std™ conformant” shall be applied to artifacts, not to organizations. Certification of practitioners and instruments is out of scope for this version (§13).

10. Privacy and Data Architecture¶

The benchmark exists only because the two-store architecture makes it safe to feed. The architecture is non-negotiable and normative:

• Store A - client data. Identifiable. Owned by the client. Never pooled, never used beyond the engagement that produced it. Deletion on request.

• Store B - the benchmark pool. Anonymized decision-ontology instances only: no client identifiers, no personal names, no free-text fields that could carry either. Owner roles appear as anonymized role types.

• Transfer is one-way. A record enters Store B only after anonymization; nothing in Store B links back to Store A. Where a client declines pooling, the assessment proceeds unaffected - pooling is never a condition of service.

These rules bind every conformant instrument and every derived work. An instrument that pools identifiable data is not conformant, whatever else it implements.

11. Reference Implementations (informative)¶

Two instruments implement this standard at the date of publication; the reference implementations are the author's; they are not privileged - any conformant instrument is equally valid.

They are references, not requirements; any instrument satisfying §9.1 is equally conformant.

• The Execution Friction Scorecard™ - a 36-item structured self-assessment across the six dimensions of §5.2, 0-4 anchored severity, live dimension scores and EFI, causal load flagging per §5.3, and export of a vh.di-std.assessment-record.

• The Absorption Bench™ - a simulation instrument that stress-tests a proposed loop redesign through four lenses (champion, frontline operator, governance and risk, skeptic) before commitment; its output attaches to the assessment instance as forward evidence for the Simulate stage (§7.1).

Access to the reference implementations is provided at the standard’s site; the instruments are gated, the standard is not.

12. Lineage (informative)¶

This standard consolidates a body of prior instruments developed in the same practice. The lineage is stated so that provenance is auditable:

The theoretical claim underlying Principle 02 - that under intelligence abundance, decision rights follow consequence-bearing capacity rather than knowledge location - extends the knowledge-collocation argument of Jensen and Meckling (1992) to conditions they did not face: where intelligence is abundant, the cost of transferring knowledge - their binding constraint - collapses, leaving consequence-bearing capacity as the operative criterion for allocating decision rights. The full argument is made in Enterprise Decision Infrastructure (forthcoming 2027), of which this standard is the normative companion.

13. Roadmap (informative)¶

This standard changes deliberately or not at all. Version 1.1, planned for the first quarter of 2027, is scoped to what benchmark data can then support:

• Publication of the Decision Infrastructure Index (DII), once the benchmark pool gives the composite comparative meaning (§5.4).

• A quantitative Structural Lag scale, superseding the review method of §5.5, and the modernization of the Structural Lag Index instrument into conformance.

• Calibration of the causal load threshold (§5.3) against observed benchmark distributions.

• Beyond version 1.1, a common measurement architecture for Installed Capability and Realized Capability - the unit of analysis, evidence standards, instruments, calculation rules, and comparability conditions for capability conversion - is reserved for the next major version. Covenant terms do not change before a major version (§3.0), and the Core Equation's terms will not be given arithmetic meaning before that architecture exists.

Certification of practitioners and instruments, and sector overlays, are candidates for later versions.

Future versions may introduce decision-instance telemetry to independently observe recommendation-to-action friction and to provide external validation evidence for the conditions measured by EFI. Such telemetry is outside the normative scope of v1.0. Candidate approaches may include time amplification, excess intervention, decision observability, and friction-attributable value effects.

Appendix A - Schemas (normative)¶

The following accompany this standard and are normative at the versions named:

• di-std.objects.v1.json - object model (§6.1, §6.2, §6.3, §7.1, §7.3)

• di-std.assessment.v1.json - assessment instance (§5, §6, §8)

• vh.di-std.assessment-record.v1.json - instrument interchange record (§9.2)

• di-std.parameters.v1.json - parameter document schema (§5.6)

• di-std.parameters.v1.values.json - v1.0 parameter values (§5.6)

• di-std-kernel.v1.js - reference scoring kernel (§5.6)

• di-std.conformance-suite.v1.json - conformance test suite, 33 reference instances (§9.1)

• run-conformance.js - conformance runner (informative)

The files are published alongside this document at the standard's site and are licensed under the Apache License 2.0. Where the text of this standard and a schema file differ, the schema file governs for machine validation and the text governs for interpretation.

Appendix B - Bilingual Term Table (informative)¶

Translations follow the author’s published bilingual usage where it exists; remaining renderings are proposed for the author’s confirmation before the Chinese edition is issued. The English text governs.

The standard is open; the benchmark derived from it is proprietary.

© 2026 Victoria Hou. All rights reserved except as licensed below.