Welles Decision Architecture
People and AI systems can make recommendations, prepare decisions and trigger actions. Welles Decision Architecture defines the basis on which these may become authorized, sustainable obligations.
We provide the decision and control architecture. We do not build agents. Your IT team or an implementation partner connects the rules to existing systems and demonstrates their enforcement.
DECIDE · GOVERN · CARRY
DECIDE
CEO Decision Architect
Examine the business situation for actual demands, causes and deferred decisions. Establish a decision question, serious options and economic consequences. Keep observation, hypothesis and conclusion distinct.
GOVERN
TOOD 3
Examine evidence, mandate, obligations and accumulated effects before execution. Rules determine when action is permitted and when evidence, human approval, escalation or a stop is required. Technical capability is not a mandate.
CARRY
SOA LUMEN
Who actually takes on the work and consequences? SOA LUMEN examines load, mandate, decision rights, competence, resources, interfaces and displaced work. Formal approval does not create available capacity.
The result is a reviewable decision with boundaries and assigned responsibility. Unresolved conditions stay visible; a plausible recommendation does not replace approval.
Agent Decision Boundary
What is evidenced, assumed, unresolved or outdated?
Which role may create which effects, within which limits?
Which promises, costs or services arise alongside existing commitments?
Who decides on exceptions, with which authority and actual available time?
When does an action remain paused, who resolves the gap and what allows it to resume?
What was checked, authorized and executed? Which effects actually followed?
Illustrative example · Procurement
A procurement agent places several individually permitted orders. Together, they commit more budget than its mandate allows. A manager is also expected to approve every exception, although other tasks already occupy their capacity.
DECIDE clarifies procurement needs and alternatives. TOOD 3 examines the new obligation alongside existing commitments and approval rights. SOA LUMEN assesses who can actually handle exceptions and which other work must give way. Missing prerequisites remain documented as unresolved conditions.
This example illustrates the review process; it does not describe a verified customer integration.
Development status
Current status
TOOD 3 exists as a reference architecture with a locally verified implementation. This status applies to the local test scope. It does not establish complete integration into your systems or approval for production use.
Next evidence in the actual use case
The enterprise IT team must connect data access, identities, mandates and interfaces. Tests must demonstrate that approvals, escalation and stop rules hold during failures and changed conditions. Operations, accountable roles and approval scope are then explicitly defined.
A local test does not replace integration evidence or operational approval. The Controlled Decision Pilot provides findings and open conditions for the next decision; technical integration is commissioned separately.
Start with one specific case
A review defines the decision boundary. A pilot tests the rules against 10–20 cases. Scope, internal contributions and deliverables are agreed before starting.
View engagements and fixed fees