GodEngine Research

Working notes ยท Edition of 5 October 2026

How GodEngine reasons about a decision, and where it stops

GodEngine is a decision intelligence engine. You ask about a decision; it breaks the question into causes and effects, builds scenarios and writes a report that shows its reasoning. This site is not the product. It is the method behind it, written down: how evidence is weighed, how uncertainty is reported, what would make a recommendation reverse, and what the system will not do.

One question, several paths A single line runs from the left to a branching point, then splits into three paths. The middle path is drawn heavier and marks the current recommendation. The upper path is a thin alternative. The lower path is dashed and crosses a short bar, marking the condition under which the recommendation would reverse.
One question, several paths. The heavy line is the current recommendation; the dashed line marks the condition under which it would reverse.

Three sentences

A successful tool call is not a successful business strategy. A simulation score is not an observed probability. A proposed plan is not permission to execute it.

From our architecture blueprint, 4 October 2026

Most of what follows expands those three lines. Decision tools fail in a few predictable ways: they report a guess as a measurement, they blend different kinds of confidence into one reassuring number, they treat a recommendation as if it were permission to act, and they describe themselves by how many parts they have rather than by whether a decision got better. These notes are our attempt to avoid each of those failures in public, where you can check us.

Contents

  1. IPrinciples of decision intelligence

    Eleven working rules: why a decision, a plan and a permission are kept apart, why confidences are never averaged, and why unknown stays unknown.

  2. IIEvidence, uncertainty and reversal conditions

    What counts as evidence, how numbers in answers are checked, how forecasts are kept honest in a ledger, and how every recommendation names what would change it.

  3. IIIWhat GodEngine will not do

    The edges of the system, the rules it follows, and the weaknesses we know about today, each dated and marked.

  4. IVOpen notes from the architecture blueprint

    A summary of a proposal we have not built yet: request modes, who owns what, the life of a task, standing tests and the order of work.

What a decision should leave behind

Proposed

The architecture we are working towards asks every decision task to produce five separate things, so that none of them can quietly stand in for another. Only the first exists today, in an internal service that is not yet part of everyday answers; the other four are proposals.

  1. A decision. The recommendation, the alternatives, the assumptions, the uncertainty, and what would change the recommendation.
  2. A plan. The exact operations, their dependencies, the expected resource use, what needs authorisation, and when to stop.
  3. Deliverables. The actual files, analyses or other artifacts that were asked for.
  4. An execution record. Which operations completed, failed, were blocked or remain uncertain, with evidence for each.
  5. An outcome assessment. Later measurements against the original objective, with the limits of attribution stated.

How to read the status marks

Each idea on this site carries a mark saying how far it has travelled from paper into the product. There are four.

In everyday use
Part of the product as people use it today.
Partly built
Works, with limits we name, or exists in the engine but is not yet used in everyday answers.
Built, switched off
Implemented, but off by default.
Proposed
A design we intend to build. Not shipped, and it may change.

Nothing is marked as finished because it ran once. When a mark changes, the page changes and the date at the foot of the page moves.

Looking for the products?

This site does not sell anything. GodEngine's products, and where each one stands today, are described at godengine.in.