1. Question
State the decision or problem precisely. Define the desired outcome, time horizon, constraints, and what information would change the answer.
OI operating model
How Optimized Intelligence Works
Optimized Intelligence (OI) turns intelligence into a repeatable decision process. The basic flow is: question, context, evidence, reasoning, challenge, verification, decision, controlled action, and feedback.Each stage exists because a different type of error can enter the system at a different point.
The nine-stage OI workflow
2. Context
Bring in the relevant operating context: prior decisions, environment, user constraints, system state, and domain rules. Exclude history that is merely familiar but not relevant.
3. Evidence
Collect the strongest available signals. Classify source quality, independence, recency, directness, and whether a claim is observed, inferred, predicted, or speculative.
4. Reasoning
Connect the evidence to candidate conclusions. Preserve assumptions and uncertainty instead of hiding them behind a single polished answer.
5. Challenge
Look for contradictory evidence, competing hypotheses, missing variables, circular reporting, failure modes, and conditions that would falsify the leading conclusion.
6. Verification
Check the facts, calculations, identities, dependencies, and other claims that materially affect the decision. Use deterministic tests when they are available.
7. Decision
Select the best-supported path. State confidence proportionally to the evidence and keep unresolved issues visible.
8. Controlled action
Act only within explicit authority. Higher-impact or novel actions may require approval, reversibility, sandboxing, or independent validation.
9. Feedback
Measure what happened. Save the result, update the model of the problem, and improve the workflow for the next cycle.
Why context comes before more data
Many decision failures begin before reasoning starts. A vague question can produce a precise but irrelevant answer. A missing constraint can make a recommendation impossible to execute. Too much historical context can bias the system toward familiar explanations even when current evidence points elsewhere.
OI therefore treats context as a controlled input. The system should know which facts describe the present decision, which preferences or rules are durable, and which earlier experiences are useful only as hypotheses. Context should improve the decision, not trap it.
Evidence has a genealogy
Three articles can look like three sources while all tracing back to the same unverified post. OI treats source independence as part of evidence quality. Primary sources, direct measurements, official records, and independent confirmations carry different weight from repetition.
Challenge is separate from reasoning
The system that builds a case can become attached to its own conclusion. A dedicated challenge step asks what would make the conclusion wrong, what evidence points elsewhere, and whether the preferred explanation depends on an assumption that has not actually been verified.
Verification should match the risk
Not every statement needs the same verification burden. A low-stakes draft may need little more than a human glance. A calculation that controls a financial model may need a reproducible formula check. A software patch may need compilation, tests, regression checks, and deterministic repository-state proof. A high-impact operational action may need explicit authorization and a rollback path.
The OI principle is proportionality: verify the claims and state transitions that can materially change the outcome. This avoids both extremes - blind trust on one side and expensive over-validation of every trivial detail on the other.
Specialized nodes inside the workflow
The nine-stage loop does not require one general model to do everything. Different nodes can own different parts of the work. A retrieval node can gather evidence. A domain node can interpret it. A challenge node can test competing explanations. An engineering node can create a patch and run tests. An execution-control node can enforce authority boundaries.
What matters is that handoffs preserve state: the question, evidence, confidence, constraints, and authority status should not silently disappear when work moves from one node to another.
Authority is a state, not a feeling
A system should not infer permission from urgency or confidence. Read-only inspection, source mutation, deployment, financial action, external communication, and destructive cleanup are different authority classes. A governed workflow can allow one while prohibiting another.
Feedback turns a workflow into a system
Without outcome tracking, the same reasoning can be repeated forever without learning whether it worked. Feedback closes the loop by comparing the expected result with the observed result and updating rules, confidence, thresholds, or tests.
A compact example
Suppose a business wants to know why a product page stopped converting. OI starts by defining the decision: diagnose the cause and choose the safest high-value change. It gathers traffic, device, conversion, price, inventory, campaign, and page-change evidence. It considers competing explanations, such as lower-intent traffic, a broken checkout path, pricing, stock, or a page regression. It verifies the strongest claims, chooses a bounded change, defines a success metric and stop rule, and measures the result. The output is not merely an explanation; it is a testable decision process.
Framework resources and comparisons
Go deeper into the operating rules, decision structures, reusable resources, and comparison pages that support the Optimized Intelligence workflow.