TL;DR:
- AI reasons about data; Decision Intelligence reasons about decisions
- Decisions are narratives: chains of Decision Records that cross departments
- Departments and Roles govern what data, context, and actions are accessible
- Decision Context connects systems of record to the decision at hand
- One reasoning engine tailors itself through Scope Questions tied to each Role
- The architecture is delivered via a Decision Room, built for your role
Understanding the Architecture
Before diving into each component, it helps to see the full picture. The diagram below shows how Spheresmith’s Decision Intelligence system is organised. At the top sits the Sphere, which is the domain of concern. Within it, Departments house one or more Roles, and each Role carries a library of Scope Questions.
Those Scope Questions drive the domain ontology, which is a structured map of verified knowledge that tells the system which concepts, relationships, and data sources are relevant to that Role. When a Scope Question is activated, the system draws on the Decision Context, which includes the relevant systems of record, ontologies, Decision Templates, and enterprise-specific criteria, and produces a Decision Record.
That Decision Record has four layers: a Scope Question or Use-Case, a Decision Artifact, Workflows, and a Monitoring Artifact. When a Workflow triggers action in another department, a new Decision Record is created there.
The chain of Decision Records that results is what Spheresmith calls a Decision Narrative.
1. The Decision Intelligence Problem
1.1 Why Data-Centric AI Fails at Decisions
Most contemporary AI systems reason about data, not about decisions. They operate within task boundaries, optimise local objectives, and treat decisions as terminal outputs rather than as commitments embedded in longer trajectories. A system can reason correctly about data and still produce a bad decision. This is a failure of architecture, not a failure of intelligence.
The gap manifests in several structural failure modes. Decision Context is implicit rather than represented. Assumptions are embedded in data or prompts but rarely surfaced or stress-tested. Reasoning traces do not constitute true audit trails. Systems are fragile under regime shifts. Most critically, current AI systems are intent-blind: they optimise task completion without understanding the decision intent that gives those tasks meaning. And because most real-world decisions are intermediate commitments, not endpoints, optimizing them in isolation leads to fragmentation and incoherence, even when each step appears locally correct.
1.2 Decisions as Narratives, Not Transactions
What must be modelled and reasoned over is a Decision Narrative: a structured chain of Decision Records that gets created as a decision crosses organizational boundaries. When a CFO makes a resource decision that requires the CMO to act, a new Decision Record is created in the CMO’s department. The CFO does not need to know how the CMO executes, and the CMO does not need to know the CFO’s full context. Each department works within its own Decision Record. The chain of those records, connected by the Workflows that triggered them, is the Decision Narrative.
This is what makes Decision Intelligence a systems problem. Decisions require explicit representations of intent, assumptions, Roles, and state that persist across departmental boundaries and across time. A decision made today shapes what is possible tomorrow, and the system must carry that context forward.
1.3 Spheres, Departments, Roles, and How Decisions Are Structured
At the highest level sits the Sphere or Domain: the broad area of concern such as Sales, Finance, ITSM, or Security. Each Sphere carries a domain ontology that defines the verified concepts and rules the system reasons with, plus connectors to relevant systems of record, standard decision templates, and organization-specific conventions.
Within a Sphere sits the Department: a functional unit within the organization that owns a set of Decision Records and the Workflows that govern them. A single Department can contain multiple Roles.
Beneath the Department sits the Role: the character of the decision made architecturally explicit. Roles define who is acting within a Department and what they are permitted to do. A Role determines the organizational space, the reporting relationships, and the rights and permissions that govern what data can be accessed and what actions can be taken.
Each Role carries a library of Scope Questions: the specific questions that Role is expected to answer. A Sales organization, for example, contains Roles from Account Executive through Sales Manager to Sales VP, each with a different scope of responsibility and a different set of questions about the same underlying data. The Scope Questions are what produce differentiated Decision Records from a shared system of record.
Together, Sphere, Department, and Role establish the outer boundary of any Decision Narrative. They determine what knowledge is relevant, what data is accessible, and what standards of coherence apply before a single question is asked. Role is also the mechanism through which the system enforces security and control: AI-driven decision support inherits the organization’s existing governance model rather than requiring a parallel security infrastructure.
1.4 What This Looks Like in Practice
1.5 Decision Context: The Knowledge That Surrounds Every Decision
The Decision Record does not operate in isolation. Before a Decision Record can be constructed, the system assembles the Decision Context: the ambient knowledge environment that connects the Role’s Scope Questions to the data and criteria needed to answer them.
For a CFO, the Decision Context draws on four systems of record: the financial planning system (Anaplan), the ERP (NetSuite), the CRM for pipeline data (Salesforce), and internal operational systems that track how the business is running. External market data can also be brought in to assess broader conditions. Each of these systems has its own ontology, a semantic layer that maps the system’s raw tables and fields to concepts the reasoning system can work with.
Beyond the systems of record, the Decision Context includes:
- Decision templates: the standard structure for how a particular type of Decision Record is organized and presented
- Enterprise-specific criteria and guidelines: the thresholds, benchmarks, and conventions specific to this organization, such as what counts as a healthy margin, how peer comparisons are constructed, and what the internal definition of a risk flag is
- Assumptions: the acknowledged priors that shape how data is interpreted
While the structural categories of Decision Context are always the same, the content within each is dynamic and domain-dependent. A Decision Context assembled for a CFO revenue review looks very different from one assembled for a portfolio manager’s rebalancing decision, even on the same platform.
1.6 How a Decision Gets Recorded and Traced
Within the boundary established by Sphere, Department, and Role, and drawing on the assembled Decision Context, the Decision Narrative is materialized through the Decision Record: a structured, auditable trace of a decision from initiation through execution and monitoring. The Decision Record comprises four layers:
Scope Question or Use-Case: Every Decision Record begins with a question from the Role’s library of Scope Questions, the inciting event that sets the decision in motion. Associated with it are an intent map (the narrative’s purpose), a decision template (the expected structure of this type of record), follow-on questions (anticipated continuations), evaluation criteria, and a learning record that captures how the template evolves over time.
Decision Artifact: The tangible output of the decision process. A Decision Artifact is organized into sections, each structured around the evaluation criteria for that Scope Question, and each drawing from the Evidence Library: a structured collection of data, documents, filings, and external references the system gathered to answer the question. Every claim traces back to a specific item in the Evidence Library, so a reviewer can inspect not just what conclusion was reached but which evidence supported it and how criteria were evaluated against it. Decision Artifacts can be authored by a user within a department or triggered autonomously by an event. A Monitoring Artifact is an example of the latter: generated automatically when a signal tied to the original decision crosses a defined threshold.
Workflows: The orchestrated processes that advance the decision from question to artifact. Workflows include audit trails, trigger conditions (including external triggers that initiate records in response to market events), approval gates, requests for additional artifacts or work, and monitoring requests. A workflow can trigger a new Decision Record in a different department, and this is what creates the chain that constitutes the Decision Narrative.
Monitoring Artifact: The decision does not end with a conclusion. A Monitoring Artifact defines what should be watched after a decision is made: the agent responsible for monitoring, the predicate conditions that would trigger re-evaluation, and the workflow to execute if those conditions are met. In investment contexts, this functions like bet monitoring, tracking whether the conditions that justified a position still hold.
1.7 How the System Tailors Itself Without Custom Code
The Scope Question library, combined with formalized assumptions in the ontology and knowledge graph, the connected web of verified data and relationships drawn from the organization’s systems of record, makes the system inherently tailorable.
Because each Role encodes its own Scope Questions, assumptions, and criteria as structured, inspectable objects rather than implicit biases buried in training data, the same reasoning engine produces fundamentally different decision support for different Roles and enterprises without any modification to the underlying engine.
Role-specific framing: A portfolio manager and a compliance officer examining the same trade work from different Scope Question libraries. Their Decision Context determines which assumptions are active, which evaluation criteria apply, what data is retrieved, and what counts as a satisfactory answer. These are not cosmetic differences. They determine the structure of the Decision Record itself.
Enterprise-specific beliefs and conventions: Institutional knowledge, including acceptable margins of error, authoritative data sources, local terminology, and hurdle rates, lives at the organizational level and propagates into every Decision Record. Two firms using the same platform may define value investing differently or apply different risk thresholds. The system carries each firm’s perspective consistently through every decision, without separate model training or custom code.
This resolves the tension that plagues most enterprise AI systems: the desire for customization versus the need for consistency. The platform is domain-agnostic; the Sphere makes it domain-specific. The reasoning engine is universal; the inherited Scope Questions and assumptions make it institutional. The decision process is structured; the Roles make it personal.
1.8 The Decision Room: What You Get
The architecture described in this blog is delivered via a Decision Room.
When a user logs into Spheresmith, they are assigned one or more Decision Rooms based on their Role. Each room is a pre-configured environment built around the decisions that Role owns. A Chief Revenue Officer gets a Revenue Risk room. A VP of Finance gets a Quote-to-Cash room. A portfolio manager gets an investment due diligence room. Each room arrives pre-loaded with the relevant Scope Questions, systems of record connections, ontology, and enterprise context for that Role.
Inside the room, every answer is grounded in ontological reasoning. The system draws from the right data sources, applies the right enterprise criteria, and builds a traceable evidence trail behind every conclusion. The user can inspect what evidence was used, which assumptions shaped the interpretation, and how the decision moves forward into monitoring. This is what makes Decision Room output auditable and consistent at enterprise scale.
