Decision context & boundaries.
A decision becomes analyzable only after its environment, scope, authority, constraints, assumptions, evidence window and review conditions are made explicit. The boundary is not administrative decoration. It determines which facts are relevant, which comparisons are valid and where a conclusion stops being transferable.
DECISION
CORE
Context gives a decision meaning. Boundaries give it validity.
Without both, teams can answer different questions with the same data, carry evidence beyond its valid domain, or optimize a local result while damaging the wider system.
Decision context and boundaries are the explicit conditions that define what decision is authorized, why it exists, who owns it, what is included or excluded, which constraints apply, what evidence is admissible, how uncertainty is represented and when the conclusion must be reviewed.
Compile the decision before evaluating it.
Select a scenario. The system converts a vague request into a bounded decision object with an owner, objective, unit of analysis, horizon, constraints and reopening conditions.
SELECT DECISION CLASS
BOUNDARY RECORD / VENDOR SELECTION
Select the support-platform vendor that best satisfies the next 24 months of service demand within the approved cost, security and migration constraints.
Six layers determine what the evidence means.
The same option can be rational in one context and unacceptable in another. Each layer must be represented before a recommendation is treated as portable.
Purpose & objective
The decision problem, desired state, success criterion and conflict between objectives.
Operating environment
Market, technical, legal, organizational and physical conditions that shape feasibility.
Actors & authority
Decision owner, affected stakeholders, implementers, reviewers and escalation authority.
Evidence state
Sources, observations, provenance, recency, conflicts, gaps and confidence limits.
Constraints & trade-offs
Hard limits, soft preferences, dependencies, opportunity cost and unacceptable outcomes.
Time & reversibility
Decision deadline, effect horizon, review cadence, lock-in and cost of reversal.
Every material factor needs a boundary status.
Binary in/out labels are insufficient for dependencies that sit on the edge. Use an explicit interface state for factors that are not optimized directly but can invalidate the decision.
| Status | Operational meaning | Treatment | Example | Failure if unclear |
|---|---|---|---|---|
| IN SCOPE | Directly evaluated or controlled by this decision. | Define criteria, collect evidence and assign ownership. | Vendor security controls and total cost over 24 months. | Relevant options or costs disappear from the comparison. |
| BOUNDARY / INTERFACE | Outside direct optimization but connected strongly enough to constrain validity. | State dependency, tolerance and trigger for escalation. | Identity provider compatibility owned by another team. | A local optimum creates a system-level failure. |
| OUT OF SCOPE | Deliberately excluded from this decision cycle. | Record reason, owner and conditions for reconsideration. | Replacing the broader CRM architecture. | Exclusion is mistaken for irrelevance or silently re-enters debate. |
| UNKNOWN | Materiality or state cannot yet be established. | Assign inquiry, deadline and consequence if unresolved. | Future data-residency requirement. | Missing evidence is converted into unjustified certainty. |
A recommendation is a conditional chain—not an isolated answer.
Traceability requires every conclusion to preserve the relationship between the objective, evidence, governing constraints, assumptions and authorized action.
Objective
Names the state the decision is intended to produce.
Evidence
Supplies observations relevant to the defined context.
Constraint
Removes infeasible or unauthorized states.
Assumption
Marks what must remain true for the inference to hold.
Decision
Commits action within an explicit authority and review frame.
Specificity changes the quality of the answer space.
A weak prompt invites generic optimization. A bounded frame tells analysts, retrieval systems and decision-makers which trade-offs are legitimate.
Unbounded request
“Which platform is best?”
- No user or operating context
- No horizon or volume assumption
- No hard constraints
- No definition of “best”
- No evidence cutoff or review trigger
Decision-ready frame
“Which support platform should the service director authorize for 140 agents over 24 months, given EU data residency, SSO compatibility, a €180k implementation ceiling and a migration window ending 30 September?”
- Owner and population defined
- Time and budget bounded
- Technical and legal constraints explicit
- Action and deadline identifiable
- Assumptions testable
Unknowns require treatment—not concealment.
Classify uncertainty by knowledge and controllability. Each quadrant implies a different response; none justifies silently replacing uncertainty with a precise-looking number.
The boundary determines when to proceed, pause, escalate or reopen.
A decision record is incomplete until it specifies how changing conditions alter its authorization state.
Within tolerance
Required evidence is sufficient, hard constraints are satisfied and residual uncertainty is accepted by the owner.
Evidence incomplete
A material unknown is investigable and its expected value exceeds the cost or delay of inquiry.
Authority exceeded
The option breaches a constraint, shifts risk to another owner or creates an impact outside delegated authority.
Context changed
An assumption fails, evidence expires, a threshold is crossed or the operating environment changes materially.
Make the decision frame retrievable without flattening its conditions.
For human and machine retrieval, store the frame as labeled, atomic fields. Preserve provenance, time, exclusions and contradictions next to the claim they qualify.
Retrieval must carry the boundary with the answer.
A retrieved passage is not automatically true, current or applicable. The purpose of this structure is to reduce context mixing and unsupported transfer by keeping conditions attached to claims. It improves traceability; it does not guarantee a model’s output.
{
"decision_id": "DI-DCB-001",
"decision_statement": "Select support platform",
"owner": "Service Director",
"valid_for": "24 months",
"evidence_cutoff": "YYYY-MM-DD",
"scope_in": ["security", "TCO", "migration"],
"scope_out": ["CRM replacement"],
"constraints": ["EU residency", "SSO"],
"assumptions": [{"claim": "140 agents", "status": "test"}],
"conflicts": [],
"reopen_if": ["volume +25%", "residency rule changes"],
"provenance": [{"source": "record URI", "observed_at": "timestamp"}]
}The minimum complete boundary specification.
These fields form a practical completeness test. Additional analysis may be necessary, but a consequential decision should not omit these core controls.
| Field | Question it resolves | Required representation | Failure when absent |
|---|---|---|---|
| Decision statement | What exactly is being authorized? | Verb + object + population + horizon + principal constraint. | Analysis drifts between different decisions. |
| Objective | What state should improve? | Outcome, measure, direction and acceptable trade-off. | “Best” becomes undefined. |
| Owner & authority | Who decides and within what mandate? | Named role, delegated limit and escalation path. | Recommendation has no accountable actor. |
| Scope & interfaces | What is included, excluded or dependent? | In / boundary / out / unknown with rationale. | System effects are missed or duplicated. |
| Constraints | Which states are prohibited or limited? | Hard vs soft, threshold, owner and evidence. | Infeasible options survive evaluation. |
| Assumptions | What must remain true? | Claim, basis, sensitivity and validation status. | Conditional conclusions appear universal. |
| Evidence window | Which evidence is admissible and current? | Source class, cutoff date, provenance and conflicts. | Stale or incomparable evidence is mixed. |
| Review trigger | When does the decision lose validity? | Event, threshold, monitor, owner and response. | A one-time answer persists after context changes. |
Decision context and boundary FAQ.
Compact answers to the distinctions most often lost in generic decision frameworks.
What is a decision boundary?
A decision boundary states where the authorized problem begins and ends. It identifies included factors, excluded factors, system interfaces, constraints, authority limits, evidence limits and conditions that force escalation or reconsideration.
How is context different from scope?
Scope identifies what the decision directly covers. Context describes the conditions that change the meaning or consequence of the decision, including environment, actors, evidence state, time and uncertainty. Something may be outside scope but still part of the context as a dependency.
Should out-of-scope factors be ignored?
No. They should be recorded with a reason, owner and reconsideration condition. An excluded factor may still constrain the decision through an interface or become relevant when a threshold is crossed.
When should a decision be reopened?
Reopen it when a material assumption fails, evidence becomes stale, a monitored threshold is crossed, a constraint changes, the operating environment shifts or the impact exceeds the original owner’s authority.
Does structured context make a RAG answer reliable?
It can improve retrieval precision, provenance and applicability by keeping qualifiers attached to content. It cannot guarantee truth or correct model behavior. Source quality, indexing, retrieval, conflict handling and output verification still matter.
Continue through the complete Decision Intelligence system.
Context and boundaries sit between the decision question and the option set. The surrounding nodes carry the frame into criteria, evidence, uncertainty, commitment, escalation and review.
Decision Intelligence
Structure choices through objectives, alternatives, evidence, uncertainty, trade-offs, commitment and review.
A decision is only as precise as the boundary around it.
Define the authorized question. Preserve the conditions. Expose the unknowns. Record the exclusions. Attach review triggers. Then—and only then—compare options and commit resources.