METHODOLOGY · THE DECISION OPERATING SYSTEM
Every enterprise already has a decision operating system. Most of them are accidental. Ours is engineered.
The Decision Operating System (DOS) is the methodology we use to build decision intelligence as an enduring enterprise capability. It composes five layers — people, process, policy, data, and value tracking — into a single coherent system. The platform runs inside the DOS. The DOS runs inside the enterprise. The enterprise runs better.
The premise
Every consequential decision in an enterprise already runs through some operating system. Someone owns it (or no one does). Some process produces it (or several do, in tension). Some policy governs it (or no one wrote the policy down). Some data feeds it (or whatever the planner trusted that morning). Some value is tracked (or assumed).
In most enterprises, this system is accidental. It evolved one cycle, one reorganization, one tool deployment at a time. Nobody designed it. Nobody owns it as a whole. And because nobody owns it as a whole, nobody can improve it as a whole. Programs ship, programs slip, and the underlying operating system keeps doing what it always did — at the same level of quality.
The Decision Operating System replaces the accidental with the engineered. Every layer is named. Every layer has an owner. Every layer has artifacts that survive personnel changes. Every layer composes with the others. The result is an enterprise that can defend its decisions the way it defends its books.
The five layers — the DOS canvas
Five layers, composed as one system. Each layer has named owners, named artifacts, and named cadences.
| Layer | What it owns | Named owner | Cadence |
|---|---|---|---|
| People | Decision rights, escalation paths, role designs around the new operating model. | Decision COE lead, with the COO/CSCO/CFO sponsor. | Quarterly review, annual redesign. |
| Process | The decision cycle: what gets decided when, by whom, with what inputs, against what objective. | Functional decision owners, chartered by the COE. | Continuous (live in the platform); reviewed quarterly. |
| Policy | Versioned decision policies that govern what the platform auto-commits and what routes to a human. | COE chairs; functions defend. | Quarterly policy review with full audit trail. |
| Data | The semantically rich, audited, governed decision data layer that feeds the platform. | Data product owner (typically inside the COE). | Continuous audit; monthly hygiene review. |
| Value tracking | The Decision Value Statement and the methodology that produces it. | COE publishes; CFO co-signs. | Monthly publication; quarterly board readout. |
A decision operating system that has all five layers running, with named owners and audit-grade artifacts, is what we mean by a “decision-driven enterprise.” It is also what every transformation deck claims to deliver and what almost none of them actually produce. The difference is structural, not motivational.
First principle: decisions are the unit of analysis
Not functions. Not processes. Not dashboards. Decisions.
Every other methodology in enterprise transformation organizes work around functions (the supply chain workstream, the finance workstream), processes (S&OP, MRP, order-to-cash), or technology (the ERP implementation, the planning tool deployment). Each of those framings produces work. None of them produces a decision system, because the decision is never the named unit.
The DOS inverts the lens. The first artifact we produce on every engagement is a Decision Inventory — a structured catalog of every consequential decision in the operating cycle. Each entry contains: the decision (named, scoped, exemplified), the current owner (or the fact that no one owns it), the current process (or the fact that several conflicting ones run in parallel), the current data inputs (and their quality), the current policy (usually unwritten), and the current value attribution (usually absent).
Once the Decision Inventory exists, everything else organizes around it. The roadmap sequences improvements to specific decisions. The pilot scopes one decision. The implementation builds policies for specific decisions. The COE governs the portfolio of decisions. The value statement reports lift per decision.
The unit matters. Most transformation programs fail because they never agreed on the unit.
The artifact stack
A decision operating system, like any operating system, is held together by its artifacts. The artifacts are what survive turnover, what get audited, and what allow a new principal — ours or the customer’s — to pick up the work without ramp-up. The DOS specifies eight named artifacts. Every engagement produces them.
| Artifact | Layer | What it contains |
|---|---|---|
| Decision Inventory | Process | The map of every consequential decision in scope. Named, scoped, owned. |
| Decision Audit | People / Process | Where each decision currently breaks, and what the leakage is worth. |
| Maturity Score | People / Process / Data | Decision-system maturity across the five layers. Calibrated against the destination, not the peer group. |
| Decision Policy Library | Policy | Versioned, signed-off policies governing auto-commit vs. human-routing for every supported decision. |
| Decision Data Product | Data | The semantically rich, audited, governed data layer feeding the platform. Documented, traceable, owned. |
| Adoption Atlas | People | Day-in-the-life designs for every decision-making role. UX prototypes, enablement materials, role-specific runbooks. |
| Traceability Matrix | All layers | Requirement → policy → configuration → test → live decision. End to end. |
| Decision Value Statement | Value tracking | Monthly P&L-style report of lift per decision, attributed to policies, against baseline. CFO co-signed. |
Value tracking: the EVW–PVA framework
Decisions, like financial transactions, deserve their own accounting standard. Ours has two metrics.
Most transformation programs fail their value defense not because the value did not arrive, but because the methodology for measuring it was never defensible to begin with. We use a two-metric framework that every Decision Value Statement is built around. Both metrics are first-class entries in the artifact stack.
EVW — Expected Value of Waiting
EVW measures the dollarized cost of delaying a decision by one decision cycle. It answers: if this decision waits another week, another month, or another quarter, what does it cost in margin, working capital, service, and resilience. EVW is what makes the case for continuous decision emission, rather than periodic. It is also what justifies the move from the planning era to the intelligence era — because in a single-future, monthly-cycle world, EVW is invisible.
Operationally: every consequential decision in the Decision Inventory carries an EVW estimate. The COE refreshes EVW estimates quarterly. The Decision Value Statement reports realized EVW capture — the dollarized value of decisions that the platform emitted continuously, which the old cycle would have deferred to the next monthly meeting.
PVA — Policy Value Add
PVA measures the dollarized lift of a policy-driven decision compared to a heuristic-driven decision on the same problem. It is computed as: EVA of the platform’s policy solve, minus EVA of the heuristic the enterprise would otherwise have used (typically a planner override, a fixed safety stock rule, or a service-level target). PVA is the cleanest single metric for “what is the platform actually doing for us, on this specific decision.”
Operationally: every decision in the platform’s production scope carries a PVA estimate, reported monthly. PVA aggregated across the decision portfolio is the headline lift number in the Decision Value Statement. PVA per decision is what the COE uses to identify policies that need retuning, scopes that need expansion, and policies that should be retired.
EVW and PVA, used together and reported monthly, are how the DOS makes decision intelligence defensible. The CFO can read the statement. The board can defend it. Six quarters in, no one is asking “what happened to the lift we were promised.”
Governance cadence
A decision operating system needs cadence the way a financial close needs cadence. Without a cadence, governance becomes ad hoc, policies drift, and the system decays. The DOS specifies four governance cadences. They are non-negotiable; we will not run a Decision COE without them.
- 01·
Weekly · Decision Council
A 30-minute standing meeting chaired by the COE lead. Reviews exceptions, escalations, and any policy-bound decisions that auto-routed to humans in the prior week. Functional decision owners attend. Decisions are recorded; the platform learns from them.
- 02·
Monthly · Decision Value Statement publication
The COE publishes the Decision Value Statement to the CFO and the executive sponsor.
EVWcapture andPVAper decision are reported. Variance commentary is mandatory. The statement is archived as part of the audit trail. - 03·
Quarterly · Policy Review
Every active decision policy is reviewed on a one-quarter rotation (so each policy gets a full review at least annually). Functions defend their policies. Changes are versioned, signed, and dated. The Decision Policy Library is updated; the prior version is preserved.
- 04·
Annually · Operating-Model Review
The five layers are re-examined as a whole. The decision portfolio expands or contracts. The Maturity Score is re-baselined. The roadmap for the next year is set. The executive sponsor signs off. The board sees the summary.
Data discipline
A data lake is not a decision data product. The DOS treats them as different artifacts.
Decision intelligence is bounded by the quality of the signal that feeds it. The DOS treats the data layer as a first-class artifact — the Decision Data Product — and it is governed with the same discipline as the Policy Library and the Value Statement. We never inherit a data lake and call it the decision layer. We build the middle layer between the lake and the platform, and we own it.
- 01·
Canonical semantic layer
Every entity the platform reasons over — product, location, customer, supplier, time bucket, decision — has a single canonical definition, versioned, with a named owner. Synonyms across source systems are reconciled in the semantic layer, not in the platform.
- 02·
AI-assisted continuous audit
Anomaly detection, semantic drift detection, and master data hygiene run continuously. Issues are routed to named owners with named SLAs. The Decision COE chairs escalations. We do not rely on planners to catch data problems.
- 03·
Traceability to source
Every value the platform consumes is traceable back to its source system, its transformation steps, and its audit history. When a decision is questioned six months in, the data lineage is one query away.
- 04·
Master data hygiene as a permanent practice
Master data is treated as an asset the enterprise maintains, not a project the enterprise completes. The Decision Data Product has a maintenance budget, a maintenance owner, and a maintenance cadence.
Adoption discipline
Adoption is operating-model design, not training. The DOS treats it that way.
Adoption is the single most common reason transformation programs underdeliver. The DOS treats adoption as an operating-model discipline embedded from day one of every engagement — never as a workstream tacked on near go-live. The Adoption Atlas is the named artifact; the discipline below is how it gets produced.
- 01·
Day-in-the-life designs before configuration
For every decision-making role, we design the day on the new system before we configure anything. Which screen first on Monday morning. Which exception queue before lunch. Which review cadence Friday afternoon. The designs are co-built with the people who will use them.
- 02·
UX prototypes by week six
Planners see and break a prototype by week six of implementation, not at user acceptance testing. We iterate the prototype five more times before the real system exists. By the time the real system arrives, the users have shaped it.
- 03·
Co-testing throughout sprints
End users sit in sprint reviews. They break things. They request changes. UAT becomes a checkpoint, not a discovery.
- 04·
Enablement materials built during the build
Runbooks, day-in-the-life guides, exception-handling playbooks — all written during the build by the people doing the build. Not handed off to a documentation team after.
- 05·
Adoption metrics as first-class telemetry
Active use, override rate, exception clearance time, time-to-decision per role — all tracked in the platform from go-live forward. The Decision COE reviews adoption metrics monthly alongside the Value Statement.
Traceability discipline
When a decision goes wrong six months in, you should be one query away from why.
Traceability is what separates a decision intelligence platform from a black box. The DOS requires every consequential decision to be traceable, end to end, from the business requirement that produced the policy to the live decision the policy enforced. The Traceability Matrix is the named artifact. We will not implement a platform without it.
What gets traced
- Business requirement → decision policy clause. Every clause of every policy traces to a named business requirement, signed by a named owner.
- Decision policy → configuration artifact. Every policy clause maps to specific platform configuration. Versioned. Auditable.
- Configuration → test case. Every configuration element has a test case. Every test case has a pass/fail history.
- Test case → live decision. Every live decision the platform emits is tagged with the policy and configuration version that produced it.
- Live decision → outcome. Every realized outcome is reconciled to the decision that produced it. The platform learns. The COE governs the learning.
Five links in the chain. Each one is a named artifact. Each one is auditable. This is what makes the platform defensible to a CFO, a board, an auditor, or a regulator. It is also what most implementations cannot do — which is why most implementations cannot defend their own value.
COE handover discipline
The end state is not “GitaCloud runs your decision system.” The end state is “your COE does, and we sharpen quarterly.”
A methodology that creates dependency on the firm that designed it is not a methodology — it is an annuity scheme dressed up as advisory. The DOS is explicitly designed to be handed over. The COE handover discipline specifies how.
- 01·
Design the COE during Implement
The COE is designed during the implementation phase, not after go-live. The role chart, the cadence, the artifacts, the budget — all locked while the build is still in flight. The COE lead is named and seated by week eight of the implementation.
- 02·
Stand it up at go-live
The COE is live on day one of production. It chairs the first Decision Council the week after cutover. The first Decision Value Statement publishes 30 days later. Cadences do not start “once things settle.” They start at go-live.
- 03·
Run alongside for two quarters
For the first two quarters after go-live, GitaCloud principals run the COE alongside the customer’s leads — chairing some meetings, observing others, transferring playbooks, debriefing every cycle. The customer’s COE lead is the apprentice; the principal is the journeyman.
- 04·
Hand over by quarter three
By the third quarter, the customer’s COE lead chairs every cadence. The customer’s team produces the Value Statement. GitaCloud attends as observer.
- 05·
Sharpening cadence, not staffing cadence
From quarter four forward, GitaCloud is a quarterly augmentation partner. We come in to sharpen — annual operating-model review, policy library audit, new-decision scoping, value methodology review. We do not come in to operate. The capability has compounded inside the enterprise. That is the point.
AI-augmentation discipline
AI is augmentation, not autonomy. Every AI-generated artifact in the DOS carries a named human owner.
The DOS uses AI extensively — for data audit, for semantic mapping, for anomaly detection, for variability calibration, for SAGE-style decision narratives. But the methodology treats AI as augmentation, not autonomy, and the distinction is operational, not philosophical.
- 01·
AI proposes; humans dispose
AI surfaces candidate policy clauses, candidate data corrections, candidate variability calibrations, candidate decision rationales. A named human owner reviews, signs off, and is accountable for the resulting artifact. The signature is the line.
- 02·
Every AI-generated artifact is traceable
When AI contributes to an artifact — a policy clause, a data correction, a value attribution — the contribution is logged, versioned, and visible in the Traceability Matrix. The audit trail tells you what the AI proposed and what the human accepted.
- 03·
Models are governed
Calibration models for variability, scoring models for anomaly detection, language models for decision narratives — all are inventoried, version-controlled, and reviewed on the same quarterly cadence as decision policies. Model drift is a first-class risk; the COE owns mitigation.
- 04·
Augmentation is measured
The DOS tracks how much human effort the AI-augmented workflow saves — time-to-policy, time-to-data-correction, time-to-anomaly-resolution. The savings become part of the Decision Value Statement. AI value is reported alongside platform value, not blurred into it.
The anti-patterns we refuse
A methodology is defined as much by what it refuses as by what it ships.
The following anti-patterns recur across the industry. The DOS structurally refuses each one. We will not take engagements that require them.
| Anti-pattern | What it is | Why we refuse |
|---|---|---|
| Lift and shift the existing process | Replicate the old operating model on the new platform; “optimize later.” | Castrates the platform. The old process is a fossil of the old technology’s constraints. Always. |
| Two-week training at the end | Adoption treated as a training course delivered after the build. | The most expensive line item in enterprise software, measured in foregone lift. We retired it. |
| Sample data through sprint N | Configure against sample data; integrate real data near UAT. | Surprises in cutover. Re-design at UAT. Slip. We invert the sequence. |
| Industry benchmarks as value baseline | Dollarize the value case against industry averages, not customer data. | Indefensible to a sharp CFO. We baseline against your own books only. |
| Workstream-level value dollarization | Value case rolled up at the workstream level — “Demand transformation: $40M.” | Unfalsifiable. Doubles or halves with equal credibility. We dollarize per decision. |
| POC mistaken for pilot | Sandbox demonstration on sample data, called a pilot. | Proves the demo. Does not prove the P&L. We run only value pilots. |
| Offshore subcontracted delivery | Principal designs; juniors build offshore. | Translation gap between design and delivery; the customer carries the risk. We do not subcontract. |
| Value tracking in a parallel BI tool | Decision Value Statement built in BI, owned by program manager, abandoned by quarter three. | Always decays. We instrument value tracking inside the platform, owned by the COE. |
| COE as a project artifact | Stand-up the COE in the plan; never operationalize it. | Capability decays in two quarters. We treat the COE as a permanent organizational unit. |
| Methodology slides without artifacts | A poster with five circles; no named artifacts behind it. | The methodology is the artifact stack. Without it, there is no methodology — only branding. |
How the DOS relates to the platform
The Decision Operating System is platform-aware but not platform-bound. It is designed to compose with any decision intelligence platform that meets a small set of architectural requirements: continuous decision emission, probabilistic substrate, first-class policy objects, traceable lineage, learning from outcomes. VYAN meets all of them and was, in fact, built with the DOS in mind — the two were designed in conversation. Other platforms may meet some or all; we evaluate honestly, engagement by engagement.
What the DOS guarantees, regardless of platform: the five layers, the eight artifacts, the four cadences, and the two-metric value framework. What the platform guarantees: the continuous, probabilistic, learning substrate that makes the DOS deliver lift instead of activity. Neither is enough alone. Together, they are the only configuration we have seen produce decision-driven enterprises in the field.
THE SIBLING SITE
The platform is VYAN. The methodology is the DOS.
If you want to see how a platform is architected to compose with the DOS — the AIR pillars, the Decision Twin, the SAGE companion, the policy primitives — vyan.ai is the deep technical site. The DOS and VYAN were designed to work as one. Most engagements run on both.