OPERATING MODEL · BUSINESS AI
Business AI should not gain authority just because it reasons well.
A business AI system can understand a request correctly and still be unauthorized to perform the resulting action. Safe, useful execution therefore needs a chain that keeps evidence, reasoning, authority, mutation and verification separate.
1. Resolve business context before reasoning
The organization, legal entity, location, period, user and relevant business objects determine what the request actually refers to.
Without that context, even a linguistically correct answer can point to the wrong customer, account, employee or operating period.
2. Read evidence before making business claims
Current business questions should use current authorized records rather than model memory or generic assumptions.
Evidence can come from finance, operations, people, inventory, customers, documents or another governed capability, depending on the question.
3. Reasoning produces a proposed action, not permission
The system can compare options, explain consequences and prepare the next step.
That cognitive result should not change authority. A more capable model is still bounded by the same user, organization and capability permissions.
4. Preparation is different from execution
Drafting an invoice, message, journal proposal or schedule is lower authority than posting, sending or committing it.
Keeping those states explicit lets automation remain useful before the final mutation is authorized.
5. Authorization should be exact
Approval should identify the capability, organization context and mutation being authorized instead of granting a broad generic ability to act.
Sensitive actions can require human approval even when the system already knows what should happen.
6. Execute only the authorized mutation
The execution layer should perform the exact supported action and preserve the resulting identifiers and business state.
It should not treat a successful tool call as proof that the intended business outcome actually occurred.
7. Verify independently
After execution, the system should read the resulting state and compare it with the intended outcome.
That verification can detect partial failure, unexpected state, duplicated actions or downstream exceptions.
8. Keep durable proof
Important business actions need a durable record of evidence, decision, authority, execution and verification.
That proof supports audit, troubleshooting and later human review without requiring the model's conversation to become the system of record.