Principles of decision intelligence

A decision, a plan and a permission are three different things

Partly built

A recommendation answers “what should we do?”. A plan answers “exactly which operations, in what order, at what cost, and when do we stop?”. A permission answers “who allowed these specific effects?”. GodEngine’s internal decision service, deployed on 4 October 2026, already keeps to the first part: it compares alternatives and recommends one, marks every record it writes as not authorised, and grants nothing. It is not yet used in everyday answers. Plans, and the approvals bound to them, are still proposals.

Note In the proposed design, approval is bound to a digest of the plan, so a changed plan cannot run under a stale yes.

An approved plan is fixed. If it changes, it gets a new identity, and unless an explicit policy proves the change stays inside what was already allowed, it needs a new approval.

Causes before answers

In everyday use

The engine first pulls the facts, causes and effects out of a question, and only then reasons about them. An answer that skips this step can sound right while resting on a cause nobody checked. Writing the causes down also gives you something specific to disagree with.

Several scenarios, not one answer

In everyday use

A single forecast hides the spread of ways a decision could play out. GodEngine builds a set of scenarios for the decision and probes each one before it writes the report. The report is a comparison, not a verdict, and it is meant to be read alongside your own judgement.

Keep the confidences apart

Partly built

People mean at least five different things by “confidence” in a decision:

• how sure the system is about what kind of question this is;
• how much evidence covers it, and how fresh that evidence is;
• how uncertain the forecast is, and whether the forecasting method has been calibrated against outcomes;
• whether the plan is feasible;
• whether the action is authorised.

In the records written by GodEngine’s internal decision service, these are five separate fields. They are never averaged into one number, and none of them authorises an action. One of them is still thin: evidence does not yet carry the time it was collected, so its freshness is marked “not assessed” rather than guessed.

Note The decision service labels its own model confidence “an internal diagnostic, not a calibrated probability”. Every internal engine score is treated that way until its link to a real-world quantity has been validated. None is presented as a business fact.

Hard constraints are never traded for score

Partly built

A budget limit or a permission boundary is not a weight that a high enough score can outbid. The internal decision service applies this to options: one that breaks the budget, a deadline or a risk ceiling ranks below every option that fits, and if none fits, the record says the limits need a review. Ranking whole plans by expected quality, risk, speed and cost, only among plans that already satisfy every hard constraint, is still a proposal.

Unknown stays unknown

Proposed

Preconditions take three values: true, false and unknown. Unknown cannot silently become true. A step that depends on an unknown input is blocked until the input is known, and the block is shown rather than hidden. Missing evidence produces an unknown state or a question back to you, never an invented probability.

Material inputs must matter

Partly built

If someone changes an investment from 10 lakh to 90 lakh, the modelled budget constraint must change, or the system must reject the change as irrelevant and say why. The length or wording of a question cannot stand in for the financial inputs it contains.

The internal decision service reads amounts written in lakh, crore or rupees, and its test suite contains exactly this case: a 10 lakh budget and a 90 lakh budget must produce different modelled constraints. Everyday answers do not go through that service yet. The blueprint keeps the case as a standing test rather than a one-time check, because it is an easy property to lose as a system grows.

Start with the least expensive path

Proposed

Not every question needs deep simulation. The rule is to start with the cheapest path that meets the acceptance criteria and to escalate only for a specific reason: a missing capability, material uncertainty, or a failed check.

Note GodEngine's heavier simulation modes work, but today they are slow. That is one more reason not to reach for them by default.

Show the work as it happens

In everyday use

A GodEngine report streams in as each stage of the engine finishes, so you can follow how the answer was built and stop reading at the point where it stops convincing you.

Execution success is not business success

Proposed

A receipt says an operation happened. It does not say the operation worked for the business. In the proposed records, an action receipt and a measured outcome are separate things: the outcome names the intended metric, its baseline, the measurement window, what was observed, and what else might explain it.

Partial success is a first-class result. The record says which steps happened and which did not.

Note One of the standing tests in the blueprint is “successful outreach with no sales”: execution must show as successful while the business result stays separate and may fail.

Measure work, not headcount

These notes do not describe the engine by how many agents, models or simulations it contains. A count says nothing about whether a decision got better. The measure we hold ourselves to is more useful, verifiable work per unit of time and cost, with decision quality and authority boundaries intact.

More modules, more agents and more elaborate output are not measures of success. This one is an editorial rule rather than a feature, so it carries no mark.