Note IV · Open notes
Open notes from the architecture blueprint
On 4 October 2026 we wrote a blueprint for how GodEngine's decision analysis should connect to planning and execution. When it was written, nothing in it had been merged, deployed or certified. One piece has since been deployed as an internal service: decision records with separate assessments and reversal conditions, described in the evidence note. Everything else here is still a proposal. We publish a summary because the reasoning is more useful in the open, and because writing down what we have not built keeps us honest about it.
Last checked 5 October 2026Status of this note: Proposed, except the decision records
The target, in one paragraph
Given an authorised goal, the system should acquire enough evidence, compare meaningful alternatives, compile a feasible plan, obtain any authorisation it needs, carry out bounded work, verify the result, and keep the outcomes so that later work improves.
Not every conversation needs that whole path. Most questions should be answered by the least expensive route that meets the bar.
Six kinds of request
Routing looks at the outcome asked for, the evidence required, the effects allowed, the budget, and the capabilities available. It never infers permission to send, spend, deploy or delete from a question about what to recommend.
| Mode | What it does | Side effects |
|---|---|---|
| Explain | Answers from enough supplied or retrieved context | None beyond task records |
| Investigate | Gathers authorised evidence and identifies unknowns | Read-only collection |
| Decide | Compares options and produces a decision record | None on outside systems |
| Prepare | Creates preview artifacts and proposed operations | Scoped artifact writes |
| Execute | Applies an authorised, fixed plan | Only the declared operations |
| Monitor | Runs authorised periodic checks and evaluates triggers | Reads; changes only under a separate, explicit policy |
Who owns what
One logical task has one authoritative owner. Several workers may carry out its steps, but a lease prevents a stale worker from changing the task after ownership has moved.
| Component | Owns | Must not own |
|---|---|---|
| Task kernel | Task lifecycle, budgets, authorisation context, scheduling, cancellation, routing | Business truth, or any escalation of authority |
| Decision service | Evidence-linked alternatives, model runs, assumptions, sensitivity, the recommendation | Side effects or permission grants |
| Capability graph | What each capability needs and produces, feasibility, candidate plans | Invented tools, credentials or evidence |
| Verifier | Preconditions, action receipts, postconditions, recovery evidence | Treating model narration as proof |
| Tool | One bounded action | Deciding policy, or declaring business success |
Note Decision analysis and planning may take turns: planning can show an option is infeasible, and the decision service can reassess. Neither launches the other recursively; the kernel caps the rounds and stops with a named blocker when progress stalls.
Knowing a fact does not grant permission to act on it, so the graph of capabilities is kept separate from the graph of knowledge.
The life of a task
A task moves through a small set of states. The interesting transitions are the ones away from the straight path.
| From | To | When |
|---|---|---|
| Received | Planning | Always |
| Planning | Blocked | A prerequisite is missing |
| Planning | Awaiting authorisation | Approval is required |
| Planning | Ready | Already authorised |
| Awaiting authorisation | Ready | A valid grant arrives |
| Ready | Running | Work starts |
| Running | Verifying | The work reports done |
| Running | Reconciling | An outside result is uncertain |
| Verifying | Completed | Postconditions are satisfied |
| Verifying | Failed | Postconditions fail |
| Reconciling | Verifying | The result is recovered |
| Reconciling | Blocked | It cannot be resolved |
| Blocked | Planning | The prerequisite is resolved |
| Failed | Planning | A bounded repair is attempted |
Cancellation and deadline expiry are allowed from every state that is not final. Cancelling stops new work and tries to interrupt active work; it cannot reverse an outside operation that has already been committed, so any uncertain effects are recorded.
Standing tests
A selection from the evaluation suite the blueprint requires. Each describes behaviour we expect, not behaviour we have certified.
| Test | Expected behaviour |
|---|---|
| A material number in the question changes | The modelled constraints or results change, or an explicit rejection explains why |
| Critical evidence is missing | An unknown state or a request for clarification; no invented probability |
| Evidence or a tool from another customer is referenced | Access is denied before anything is retrieved or run |
| The verifier is unavailable | The operation that requires it is blocked |
| The plan changed after approval | It cannot run under the old approval |
| A request arrives twice, or a worker redelivers it | One effective operation, or explicit reconciliation; no blind replay |
| A timeout follows an outside write | The effect stays unknown until reconciled |
| A worker crashes mid-task | A new owner resumes from durable state without duplicating effects |
| Cancellation during execution | No new steps start; committed and uncertain effects are reported |
| Outreach succeeds, but nothing sells | Execution succeeds; the business result stays separate and may fail |
| A saved procedure is replayed after a schema change | Revalidation fails, or it recompiles safely |
The same set of tasks is to be run four ways: decision analysis alone, the task system alone, both together read-only, and both together with governed execution. The comparison covers verified completion, decision quality, unsupported claims, human corrections, speed, cost and recovery. Unit tests alone do not establish production reliability, and numeric targets for speed and cost will be set only after the chosen models and workloads have been measured.
The order of work
Each phase has a gate that must pass before the next begins.
- Inventory. Every adopted component has an owner, evidence of how it behaves, and declared dependencies.
- Contracts. Invalid identity or scope, unknown versions and references across customers are rejected.
- A read-only bridge. Evidence keeps its provenance; missing data is reported honestly.
- The planner. Feasibility, cycles, unknown preconditions, unavailable tools and budget limits are verified.
- Preparation. Files meet their acceptance criteria, with no undeclared effects.
- Governed effects. A failed required gate stops the action; retries do not duplicate tested effects.
- Durable learning. Feedback survives a restart; execution success stays separate from business success.
- Rollout. Combined workloads meet agreed service targets without losing quality or isolation.
The first production scope is a small allow-list of read and preparation capabilities, widened only after reliability has been shown. Full access to every capability is an end state, not a switch.
Rollout uses separate switches for routing, decision evaluation, plan compilation, artifact preparation, outside effects and learning. Rollback stops new effects first, reconciles anything in flight, and only then sends new tasks back to the known-good path.
What we deliberately left out
- No wholesale merge or simultaneous rewrite of existing systems.
- No independent, unbounded model loop for each specialist agent.
- No claim that the engine's internal trajectories are calibrated business forecasts.
- No direct execution of free-form recommendation text.
- No pooling of accounts or memory without verified identity and scope.
- No automatic learning from a tool's own report of success.
- No production claims for the planning graph until its implementation has been inspected and tested.
How we will judge it
The integrated system completes more useful, verifiable work per unit of time and cost while preserving decision quality and authority boundaries. More modules, more agents, or more elaborate output are not success measures.