# Governed Computation

## The Theory and Practice of Legitimate State Transition

**Sean Manouge — Nilsoft**  
**Version 0.4 — 23 September 2026**  
**Status: Publication candidate**

> **Governed Computation is the theory and practice of legitimate state transition.**

**Candidate note.** Version 0.4 develops the frozen v0.3 publication edition. It does not supersede v0.3 until an explicit publication/freeze decision is made. It does **not** silently promote every working predicate, tuple, claim type, or compositional rule in this paper into accepted Nilsoft doctrine. Accepted doctrine and working theory remain distinguished below.

**Candidate citation:** Manouge, Sean. *Governed Computation: The Theory and Practice of Legitimate State Transition*. Nilsoft, version 0.4 candidate, 23 September 2026.

---

## Abstract

Software is usually described by the transformations it can perform. In systems that change consequential state, that account leaves out the conditions under which a change is justified and the evidence by which its result can be established. A credential may permit a write that its holder has no authority to make. A command may complete without producing its intended effect. An observed effect may have another cause. These are different failures, and a single success flag cannot describe them.

Governed Computation takes the **legitimate state transition** as its central object. It connects predecessor state, governing authority, bounded capability, applicable constraints, execution, observed effect, successor state, and proof. It treats uncertainty and refusal as possible results of computation. Its operating method is `observe → resolve → act → prove`. The method applies at the scale of a single local operation or a distributed institutional process; it does not prescribe one architecture or a uniform amount of ceremony.

This paper develops a working formal model of that object, identifies the failure modes the model exposes, and states what a system must make inspectable when it claims a consequential transition occurred. It also marks the boundary between Nilsoft's accepted framing and the propositions advanced here for further refinement.

## Core propositions

1. **Executability does not imply legitimacy.**
2. **Authority is scoped, temporal, and state-dependent.**
3. **Permission to attempt does not establish successful effect.**
4. **Observed effect does not necessarily establish causation.**
5. **Legitimacy, outcome, and evidentiary establishment are distinct dimensions.**
6. **Unknown, conflict, refusal, partial effect, and unverified are valid computational outcomes.**
7. **A system should claim no more than its evidence establishes.**

A useful compression of the field is:

```text
Execution ≠ Legitimacy ≠ Effect ≠ Establishment
```

The practical corollary is equally important:

```text
NO UNTYPED SUCCESS FOR CONSEQUENTIAL TRANSITIONS
```

A runtime may report that an attempt was permitted, an execution layer accepted a command, an effect was observed, or a transition was established. Those are different claims. Governed Computation is concerned with preserving the relations among them rather than collapsing them into one success state.

## 1. Doctrinal status and scope

The following propositions are accepted within PRJ-NIL:

1. **Governed Computation is the theory and practice of legitimate state transition.**
2. The **legitimate state transition** is its central computational object: a proposed or actual change whose governing conditions must be resolved rather than assumed.
3. `observe → resolve → act → prove` is Nilsoft's operational method for that object.

The accepted source wording also names authority, capability, constraints, observed effect, continuity where material, and proof as possible factors in a transition's legitimacy. It leaves the **exact formal conditions** open to later doctrinal refinement.

The formal combination of these concepts into the transition tuple, legitimacy and establishment predicates, claim grammar, operational status vector, and compositional model in this paper is therefore **working theory**. Individual concepts used by that model may already be defined elsewhere in the PRJ-NIL source corpus. Version 0.4 is a publication candidate derived from the frozen v0.3 edition; it does not, by itself, promote its formal model into accepted Nilsoft doctrine or supersede v0.3.

The scope is consequential change: a transition whose error, misattribution, or lack of evidence would matter to an operator, owner, customer, institution, or affected party. The threshold is contextual. A local preference update may need little governance. Publishing a policy, moving money, deleting records, or deploying to production may need much more.

The field concerns the **structure of legitimate change**. Particular domains supply their governing rules.

## 2. The problem with transformation alone

The conventional abstraction is useful:

```text
S₀ ──f──▶ S₁
```

It says that an operation transforms a predecessor state into a successor state. It does not say whether the operation was authorised, whether the predecessor was known accurately, whether a constraint was violated, whether the intended successor actually appeared, or whether the observed change can be attributed to that operation.

Consider a deployment. The deployer has valid credentials. The command reports success. Minutes later, traffic still reaches the previous version. The command was executable and its invocation succeeded; the intended state transition has not been established.

A second case is subtler. Traffic reaches the new version, but it was promoted by another release process. The observed effect alone does not prove that this deployment caused it.

In a third case, the intended version is live, but the deployment was made without the required release decision. Its effect is real; its authority is defective.

These cases cannot be represented faithfully as a single Boolean `success`. They ask different questions:

- **Possibility:** Can the machinery perform the operation?
- **Permission:** May this actor attempt it within this scope?
- **Legitimacy:** Do the governing conditions justify this particular transition?
- **Occurrence:** What actually changed?
- **Establishment:** What evidence supports the claim that the transition occurred legitimately and produced the asserted result?

The distinction between executability and legitimacy is the entry point to Governed Computation. Technical reach is evidence of neither governing authority nor a proven result.

## 3. A working transition model

Let a consequential transition claim be represented by:

```text
T = (S₀, A, C, K, X, E, S₁, P)
```

This is a **working analytical model**, not a required storage schema.

| Term | Meaning | Question it must answer |
|---|---|---|
| S₀ | Relevant predecessor state, observed with provenance and time | From what state was action considered? |
| A | Resolved governing authority for the decision | Who or what may govern this transition? |
| C | Bounded capability available to the actor | Which operation may be attempted, on which target and scope? |
| K | Applicable constraints and invariants | What must hold before, during, or after the operation? |
| X | Execution attempt and its reported result | What was invoked, when, by whom, and with what response? |
| E | Observed effect, including uncertainty about cause | What change was seen outside the command response? |
| S₁ | Relevant successor state | What state exists after the attempt? |
| P | Evidence supporting one or more transition claims | Why should a particular claim be believed at the required strength? |

The terms are related, not merely adjacent.

A, C, and K govern whether X may begin. S₀ supplies the state against which their conditions are evaluated. X may produce E, but a response from X is not itself E. E is assessed against the intended change and related to S₁. P supports specific claims about these relations, including what remains unknown.

Where identity, ownership, provenance, obligations, or lineage must survive, continuity is evaluated across S₀ and S₁ as part of K and P; it is not assumed from a reused name.

The tuple describes a **claim under examination**. A proposed transition can be represented before X, E, S₁, or P exists. An attempted transition may lack a verified effect. Missing terms must remain missing. The model does not manufacture them by inference.

### 3.1 Property, observation, and establishment

A central distinction is required:

> **Legitimacy is a property being assessed; establishment is the evidentiary status of a claim about that property.**

A transition may in fact satisfy its governing conditions while available evidence remains too weak to establish that fact. Conversely, strong evidence may establish that a transition was illegitimate.

Governed Computation therefore separates three questions:

1. **Normative:** Were the governing conditions for this transition satisfied?
2. **Empirical:** What execution and effect actually occurred?
3. **Epistemic:** What do the available observations and evidence justify claiming?

These dimensions interact, but they are not interchangeable.

### 3.2 Pre-action permissibility

For a domain D and consequence class q, let R[D,q] denote the governing requirements and V[D,q] the required verification strength. Let tₓ be the time of execution.

A working pre-action predicate is:

```text
MayAttempt[D,q](T, tₓ) :=
    Fresh(S₀, tₓ)
∧   Governs(A, C, S₀, tₓ)
∧   InScope(C, X, tₓ)
∧   Holds(K, S₀, tₓ)
```

Its terms ask:

- `Fresh`: is the predecessor state sufficiently current for this decision?
- `Governs`: does the resolved authority actually govern this capability, target, and decision now?
- `InScope`: does the capability permit this operation against this target and intended effect?
- `Holds`: are the applicable constraints and invariants satisfied at the time they matter?

A known false precondition makes the attempt impermissible. An unknown material precondition leaves the attempt unresolved.

### 3.3 Transition legitimacy

Pre-action permission is necessary but not sufficient for a completed legitimate transition.

Define a working legitimacy predicate:

```text
Legitimate[D,q](T) :=
    MayAttempt[D,q](T, tₓ)
∧   Bound(X, C, S₀)
∧   Matches(E, S₁, intent)
∧   ContinuityOK(S₀, S₁, K)
```

`Bound` asks whether execution used the operation, target, and relevant state actually authorised.

`Matches` asks whether the observed successor satisfies the governed intent and required effect.

`ContinuityOK` asks whether any domain-significant identity, ownership, provenance, obligations, authority, or lineage survived or changed in the authorised way.

This predicate defines the **property under assessment**. It does not imply that a runtime can always know its truth directly.

An effect can therefore occur without the transition being legitimate. A permitted attempt can also fail to produce the intended successor.

### 3.4 Causal attribution

Where another actor or process could plausibly have produced the same observed effect, matching post-state is insufficient to establish causation.

Let:

```text
Attributed(X, E ; P, Vcause[D,q])
```

mean that the evidence supports attributing the observed effect E to execution X at the causal verification threshold required by the domain.

Causal attribution may be unnecessary for some claims. For others it is essential. A system should not demand proof of causation where mere post-state is enough, nor imply causation merely because an effect followed an attempt.

### 3.5 Establishment

Let φ(T) be a specific claim about the transition, such as:

- the attempt was permitted;
- the execution layer accepted the request;
- the intended effect occurred;
- the effect was caused by this execution;
- the transition was legitimate.

Then define:

```text
Established[D,q](φ(T)) :=
    Supports(P, φ(T) ; V[D,q])
```

A **legitimate transition claim** is established only when the evidence supports the legitimacy predicate at the required threshold:

```text
EstablishedLegitimate[D,q](T) :=
    Legitimate[D,q](T)
∧   Supports(P, Legitimate[D,q](T) ; V[D,q])
```

If causal attribution is part of the claim, the relevant `Supports` test must include evidence sufficient for `Attributed`.

This formulation avoids treating `UNVERIFIED` as a species of illegitimacy. A transition may be legitimate but not yet established; illegitimate and well-established; or unresolved because the governing facts are not yet sufficient.

### 3.6 Operational status is a vector, not a verdict

A consequential transition should not be forced into one overloaded enum.

A working runtime may instead expose:

```text
Ω(T) = (R, Xₛ, Eₛ, Vₛ)
```

where:

| Axis | Example states | Meaning |
|---|---|---|
| R — resolution | `RESOLVED`, `CONFLICTED`, `MISSING`, `STALE`, `REVOKED` | What is known about governing authority and preconditions? |
| Xₛ — execution | `NOT_ATTEMPTED`, `ATTEMPTED`, `ACCEPTED`, `FAILED` | What happened at the execution boundary? |
| Eₛ — effect | `NOT_OBSERVED`, `MATCHED`, `PARTIAL`, `FAILED`, `INCONCLUSIVE` | What resulting state was observed relative to intent? |
| Vₛ — verification | `NOT_CHECKED`, `INSUFFICIENT`, `VERIFIED`, `REFUTED`, `INCONCLUSIVE` | What do the available evidence and thresholds establish? |

These states are illustrative, not a universal Nilsoft enum.

The important rule is structural:

> **Do not collapse authority, execution, effect, and verification into one status when they can materially diverge.**

A user interface may derive a concise summary such as `BLOCKED`, `UNVERIFIED`, or `VERIFIED`, but the underlying dimensions should remain recoverable where consequence warrants it.

### 3.7 Claim grammar

Consequential systems should make claims at the level their evidence supports.

A useful working grammar includes:

- `ATTEMPT_PERMITTED`
- `ATTEMPT_BLOCKED`
- `EXECUTION_ACCEPTED`
- `EXECUTION_FAILED`
- `EFFECT_OBSERVED`
- `EFFECT_MATCHED`
- `EFFECT_PARTIAL`
- `EFFECT_ATTRIBUTED`
- `TRANSITION_LEGITIMATE`
- `TRANSITION_ILLEGITIMATE`
- `TRANSITION_ESTABLISHED`
- `TRANSITION_UNVERIFIED`

These are **claim types**, not mandatory wire literals.

The point is to prevent the word `success` from silently changing meaning between layers.

For example:

- an API may establish `EXECUTION_ACCEPTED`;
- a read-back may establish `EFFECT_OBSERVED`;
- a digest comparison may establish `EFFECT_MATCHED`;
- an operation identifier or exclusive lock may help establish `EFFECT_ATTRIBUTED`;
- the combined governing and evidentiary record may establish `TRANSITION_ESTABLISHED`.

The runtime should claim no more than the strongest supported proposition.

This yields a practical invariant:

```text
ClaimStrength ≤ EvidenceStrength
```

The notation is intentionally schematic. The invariant means that a system must not emit a stronger operational claim than its evidence justifies.

## 4. Authority and state must be resolved together

Authority is not the same as information availability.

A system can read a recent draft and an older accepted decision; recency alone does not make the draft governing. It can see a dashboard and the canonical record behind it; ease of access does not transfer authority to the dashboard. It can receive a fluent model answer that is neither an owner instruction nor a source of policy.

Canonical state is authoritative only **within a declared domain**. Derived state includes caches, indexes, summaries, materialised views, and model outputs. It can guide discovery and interpretation, but its provenance and adoption status must remain visible.

The governing invariant is:

> **No silent authority substitution.**

Resolution may produce states such as `RESOLVED`, `CONFLICTED`, `MISSING`, `STALE`, `DELEGATED`, or `REVOKED`.

These states affect computation.

A revoked delegation cannot be rescued by a cached permission. A conflict between credible governing sources cannot be resolved by choosing whichever one loaded first. A stale source may require refresh before mutation. Unknown and contradiction are valid states because forcing them into a yes/no answer can manufacture permission.

Authority must also survive the handoff to execution.

A decision taken against version v of a governing source cannot silently authorise a later action against version v+1 if the change is material. The runtime may use a version, hash, lease, transaction, lock, or fresh read to bind the decision to the action. The mechanism varies; the requirement is to make the time gap visible and revalidate when it can change legitimacy.

This yields a general rule:

```text
Authority must remain valid across the state and time boundary it governs.
```

## 5. Capability, constraints, and boundaries

A capability describes an operation an actor or runtime may perform in a defined scope. It should identify its target, preconditions, expected effects, and limits.

**Least capability** follows:

- read does not imply write;
- write does not imply delete;
- draft does not imply publish;
- proposal does not imply decision;
- technical access does not imply ownership.

Authority establishes who or what governs. Capability establishes an available operation. Constraints determine whether that operation is valid **under present conditions**.

An authorised publisher may still be blocked by a stale source, an unmet approval threshold, a target lock, a retention rule, or an expired delegation. The same operation can be legitimate at one time and illegitimate at another.

Nilsoft's boundary questions are practical:

1. Who owns the governing decision?
2. Where is the authoritative source state?
3. What capability may this system exercise?
4. What external state can the operation change?

Integration does not transfer ownership.

A product that implements another institution's rule does not acquire authority to rewrite that rule. An AI tool attached to a system does not inherit the system owner's judgement. A user interface that exposes a backend endpoint does not prove that every user should be offered its effects.

Where a person owns a material decision, the system can assemble evidence, identify constraints, prepare actions, and record outcomes. The decision should remain attributable to that person. Encoding the approval as “the system decided” severs the authority chain the software is supposed to preserve.

## 6. The operating method as computation

`observe → resolve → act → prove` decomposes the transition claim into operations with distinct outputs.

A product may combine them in one interaction, but it should not erase their different epistemic and control roles.

### Observe

Acquire enough relevant state to locate the decision:

- source identity;
- timestamp;
- provenance;
- actor;
- target;
- material disagreement;
- relevant environmental state.

Observation does not decide which source governs. Its output may explicitly contain missing or contradictory information. Observing more data is useful only if it improves the decision or verification.

### Resolve

Determine:

- governing sources;
- decision owner;
- actor permission;
- applicable constraints;
- unresolved conflict;
- the next valid capability.

Resolution can terminate in `UNRESOLVED` or `BLOCKED`.

For a consequential mutation, the safe default is to withhold the action when authority or a necessary precondition is missing, while allowing a policy-defined safe move such as refresh, draft, simulation, or request for approval.

### Act

Invoke the bounded capability against an identified target.

Capture, where material:

- the request;
- precondition basis;
- execution identity;
- attempt time;
- target;
- capability;
- response;
- side effects.

Recheck volatile facts near the mutation boundary.

Retries and duplicate attempts must remain explicit. A replay can turn a once-authorised operation into an unauthorised or harmful second transition.

### Prove

Observe the resulting state and assemble evidence proportional to consequence.

Proof may require:

- read-back;
- before/after comparison;
- targeted test;
- receipt;
- signed event;
- deployment evidence;
- external confirmation;
- human confirmation where a person is the only legitimate observer of the final fact.

The proof phase can conclude that the result is partial, failed, inconclusive, or unverified. It need not produce a favourable answer.

The loop is recursive in practice. A proof step may reveal new state requiring observation and resolution. A blocked resolution may identify a safe next move.

Its value is not that every product has four screens. Its value is that **observation, authority, execution, and evidence remain distinguishable in behaviour**.

## 7. What proof can and cannot establish

An execution response reports what an execution layer said.

An effect observation reports a state seen after the attempt.

A transition claim may additionally require evidence that the attempt caused that state.

In concurrent systems, causal attribution cannot be inferred from timing alone.

A **receipt** is a durable operational record of a material operation and its verification state. It may bind:

- actor;
- target;
- capability;
- authority reference;
- pre-state;
- execution result;
- observed post-state;
- evidence references;
- verification state.

A receipt is not automatically cryptographic proof, and a mutable record must not be presented as immutable evidence.

Evidence should be sufficient for the claim without needlessly copying sensitive content.

Verification strength is proportional to consequence. A local, reversible update may need a returned value and a read-back. A deployment may require identifying the live artefact and testing served behaviour. A transfer of money or authority may require independent confirmation and durable lineage.

Proof is therefore a relation between:

1. **a typed claim**;
2. **available evidence**; and
3. **a required threshold**.

Verification is claim-relative. The same evidence may establish `EXECUTION_ACCEPTED` while remaining insufficient for `EFFECT_ATTRIBUTED` or `TRANSITION_ESTABLISHED`.

It is not a generic “verified” sticker.

### Proof debt

**Proof debt** names the state in which an operation occurred but its effect remains insufficiently verified.

Proof debt should remain visible until it is:

- verified;
- invalidated;
- superseded; or
- explicitly waived by an authority permitted to waive that requirement.

A waiver is a new governed decision. It is **not retroactive evidence** that the effect occurred.

`INCONCLUSIVE` is likewise different from `FAILED`.

- `FAILED` says a required condition is known not to hold.
- `INCONCLUSIVE` says the available evidence cannot decide the claim.

## 8. Time, continuity, and composition

Legitimacy is time-sensitive.

Authority can expire or be revoked. State can become stale between observation and action. Asynchronous effects can arrive after a command response. Evidence can be superseded by later events.

A defensible transition claim therefore identifies the relevant times of:

- observation;
- decision;
- attempt;
- effect;
- verification.

It need not claim that a verified successor remains current forever.

### Continuity

Continuity matters when the successor must preserve or legitimately transform:

- identity;
- ownership;
- obligations;
- authority;
- provenance;
- lineage.

A record migration that produces identical field values but loses the record's legal identity may fail its transition.

A policy revision that changes text without a valid supersession relationship may be a new draft rather than the effective policy.

Continuity is domain-specific. Preserving a name is neither necessary nor sufficient in every case.

### Composition

Transitions compose.

If T₁ authorises a release and T₂ deploys it, the output of T₁ must be the authority actually consumed by T₂.

If T₂ targets a different artefact, a legitimate approval does not legitimise that deployment.

A chain of individually plausible steps can fail as a whole when identity, scope, state, authority, or proof is lost at a handoff.

Conversely, governance need not centralise every step in one engine. Explicit references and checks can preserve the relation across systems.

This makes a useful compositional question:

> **What must remain true between one transition's established successor and the next transition's predecessor?**

The answer may be:

- a matching version;
- target identity;
- authority scope;
- unexpired delegation;
- continuity relationship;
- current observed external state.

A system that cannot state the required link should not claim end-to-end legitimacy merely because every component returned green.

## 9. AI raises the cost of collapsing these distinctions

AI can interpret context, generate proposals, select tools, and adapt plans.

These abilities make software more useful while widening the gap between **a plausible proposed action** and **an executable legitimate action**.

Model fluency establishes no identity, consent, ownership, source authority, freshness, or permission.

An AI system may help observe by classifying and summarising evidence. It may help resolve by identifying candidate sources or contradictions. It may prepare a bounded action.

Its output remains a proposal unless the governing source explicitly delegates the relevant decision and the runtime verifies that delegation.

Where permissions or constraints can be checked explicitly, model judgement cannot silently bypass them.

The practical boundary is:

> **Probabilistic intelligence may propose; governed runtime semantics decide what is executable.**

This is a working design principle, not a demand for one policy engine.

A human decision can be part of resolution. A deterministic check can be part of it. Either way, the system must preserve who decided and what justified the action.

Agents make provenance especially important.

Prompt text, retrieved documents, tool results, model interpretations, generated plans, and governing sources are different evidence classes.

A tool result may report state without governing it. A retrieved page may contain instructions without authority over the agent.

The runtime should bind any mutation to a specific actor, capability, target, and current governing state.

The ability to call a tool is only technical reach.

## 10. A worked transition

Suppose an operator requests deployment of artefact `build-42` to production.

The release record approves `build-42`, but the deployment runtime reads an older approval cache and the production pointer may change during execution.

### Observe

Identify:

- the live deployment;
- target environment;
- artefact digest;
- release record;
- approval status;
- source timestamps;
- runtime identity.

Preserve the cache as an observation, not as authority.

### Resolve

Establish that:

- the release record governs;
- the approval applies to the exact digest and environment;
- the operator has the deployment capability;
- no lock or newer superseding decision blocks the action.

A conflict, stale approval, expired delegation, or unknown material precondition yields `UNRESOLVED` or `BLOCKED` before mutation.

### Act

Recheck the live pointer and approval at the execution boundary.

Record the intended digest.

Invoke the bounded deployment capability.

A successful command response may support `EXECUTION_ACCEPTED`. It does not by itself support `EFFECT_MATCHED` or `TRANSITION_ESTABLISHED`.

### Prove

Read the live pointer and serve a request through the production route.

Compare the observed digest and behaviour with `build-42`.

If only the API acknowledgement exists, `EXECUTION_ACCEPTED` may be established while the effect and completed transition remain unverified.

If the pointer changed but the route still serves the old bundle, the effect is `PARTIAL` or `FAILED` under the release criteria.

If another deployer changed the pointer concurrently, `EFFECT_OBSERVED` may be supportable while `EFFECT_ATTRIBUTED` remains open until the evidence distinguishes the attempts.

The example illustrates the model's point.

Credentials, approval, command result, live state, and proof are connected, but none substitutes for another.

## 11. Failure classes and recovery

The model makes failures diagnosable by the relation they break.

| Failure class | Broken relation | Typical response |
|---|---|---|
| State or representation | The alleged S₀ is stale, incomplete, or derived state is treated as canonical | Refresh, recover provenance, preserve conflict |
| Authority | The wrong actor, source, rule, or delegation governs | Block mutation, resolve ownership or supersession |
| Capability or boundary | The actor can technically reach beyond legitimate scope | Narrow or revoke capability; identify affected targets |
| Constraint | A necessary precondition or invariant fails | Defer, reduce scope, obtain required confirmation |
| Execution | The bounded operation was not performed as intended | Diagnose the attempt; avoid unsafe retry |
| Effect | The command ran but the required change did not occur | Inspect actual state; repair or compensate under fresh authority |
| Proof | Evidence cannot establish the claimed result or cause | Carry proof debt; gather independent evidence |
| Continuity | The successor loses required identity, lineage, authority, or obligation | Restore lineage or treat the result as a different entity |

This taxonomy is diagnostic, not a universal error enum.

Recovery is itself a transition and must be governed.

A failed operation does not grant blanket authority to retry, roll back, delete, or compensate.

Where a partial effect has occurred, the new predecessor state must be observed before the next move is chosen.

## 12. Objections and limits

### Is this simply identity and access management?

Identity and access management establishes identities and permissions.

Those mechanisms are indispensable, but a permission check usually does not prove that the source state was current, the action's constraint still held, the effect occurred, the successor preserved required continuity, or the observed effect was caused by the authorised attempt.

Governed Computation asks how these facts combine for a particular transition.

It uses identity and access controls rather than replacing them.

### Is this policy as code or a workflow engine?

Policy as code can evaluate rules, and workflow engines can sequence tasks and approvals.

Either can implement part of the model.

A policy decision may be made against stale state. A workflow may report a completed step before external effect is verified.

The claim here concerns the semantics across observation, authority, capability, execution, effect, successor state, and evidence.

It does not require those semantics to live in one product.

### Is this an audit log with a new name?

An audit log records events, often after they happen.

A governed transition requires some facts **before** mutation and distinguishes reported execution from observed effect **after** it.

Receipts and logs can supply evidence, but a log entry cannot retroactively authorise an act or establish a cause it did not observe.

### Is this formal methods under a brand?

Formal methods can specify and prove properties of a model. They offer powerful techniques for parts of this problem.

Governed Computation also has to identify:

- the governing authority for the model;
- the current external state;
- the scope of a human decision;
- the execution that actually occurred;
- the evidence that the implementation produced its claimed effect.

A proof about a specification does not by itself prove that the specification was authorised or that the world now matches it.

Where formal verification is warranted, it strengthens the transition's proof rather than being displaced by this framing.

### Does domain-relative legitimacy make the theory empty?

No single rule can determine the legitimacy of every payment, deployment, policy change, and record migration.

The theory is constrained by the requirement to declare the domain rules, preserve the distinctions among the transition terms, and make the judgement inspectable.

It is falsifiable in a practical sense: a system that cannot identify what governed, what changed, or what evidence supports its completion claim does not meet its own asserted standard.

Domain-relative does not mean arbitrary.

### Does this require bureaucracy for every write?

No.

Consequence determines the amount of resolution and proof.

The model can be satisfied implicitly by ordinary program invariants for a low-risk local change. It becomes explicit when authority, effect, continuity, or evidence can materially diverge.

Adding process without reducing that divergence would be a poor implementation of the theory.

## 13. Engineering and operator consequences

The minimum useful implementation is a complete vertical slice of the transition.

A system should make the relevant predecessor state inspectable, identify what governs, bind an action to a bounded capability, check material preconditions, observe its effect, and expose verification status.

It can do this in:

- a modular monolith;
- local runtime;
- CLI;
- service;
- API;
- operator interface;
- agent tool surface.

Event sourcing, microservices, blockchain, a universal ontology, and a global transition ledger do not follow from the theory.

Operator interfaces participate in governance.

A generic success banner shown after command acceptance but before required effect verification makes an over-strong claim. The interface should instead state what is actually established, such as `Execution accepted; effect not yet verified.`

A destructive control that hides its target or scope weakens the action boundary.

An interface should reveal, at the level an operator needs:

- material state;
- authority;
- uncertainty;
- available actions;
- blockers;
- observed effects;
- proof.

When no authorised move exists, it should explain why.

Nilsoft calls the practical output **TEETH / next move**: the next relevant, authorised, bounded, safe enough, and verifiable action, or a precise blocker.

The product claim is operational, not promotional.

Where organisations spend time reconciling sources, checking authority, supervising automation, and proving effects, a governed system may reduce that work and its associated risk.

Such value must be demonstrated in an actual product and measured against its operating context.

The theory alone is not market evidence, a registered product estate, or proof of commercial demand.

## 14. The field claim

Software increasingly acts within realities it does not fully own: institutional decisions, customer environments, distributed services, delegated credentials, and model-generated interpretations.

The familiar transformation

```text
S₀ → S₁
```

remains necessary.

For consequential change, it is incomplete until the system can account for the authority that governed, the capability and constraints that bounded action, the effect that occurred, the continuity that mattered, and the evidence that supports the claim.

Governed Computation names that unit of analysis:

> **change under conditions of legitimacy**

Its object is not computation that merely changes state, but computation that can **justify and establish a consequential change of state**.

Its central claim can be stated another way:

```text
A legitimate transition is relational, not merely transformational.
```

It relates predecessor, authority, capability, constraint, execution, effect, successor, and evidence.

And a governed system must preserve another relation:

```text
what the system claims ≤ what its evidence establishes
```

The first relation governs state transition. The second governs epistemic honesty about that transition.

The field's contribution is to make legitimacy a computational question that can be represented, acted on, contested, and evidenced, while leaving the governing decision with its actual owner.

Nilsoft builds software within this field.

The field is wider than any Nilsoft product, and its formal conditions remain open to refinement.

A machine that can change state is powerful.

A system that can identify **why this change was permitted, what actually changed, and what evidence survives** is governable.

---

# Appendix A — Source and authority basis

This paper is grounded in the PRJ-NIL source corpus current on 23 September 2026.

Its accepted centre is established in:

- `01_NILSOFT.md`
- `03_PURPOSE.md`
- `13_ARCHITECTURE.md`
- `14_RUNTIME_MODEL.md`
- `25_STATE.md`

Related draft sources inform the treatment of invariants, boundaries, authority, governance, operating method, capability, data and state, interfaces, security, proof, product doctrine, engineering, customers, commercial model, design, lifecycle, and roadmap:

- `04_PRINCIPLES.md`
- `05_INVARIANTS.md`
- `06_BOUNDARIES.md`
- `07_AUTHORITY.md`
- `08_GOVERNANCE.md`
- `09_OPERATING_MODEL.md`
- `10_PRODUCT_DOCTRINE.md`
- `11_PRODUCT_ESTATE.md`
- `12_PRODUCT_LIFECYCLE.md`
- `15_CAPABILITY_MODEL.md`
- `16_DATA_AND_STATE.md`
- `17_INTERFACES.md`
- `18_SECURITY_AND_TRUST.md`
- `19_PROOF_AND_RECEIPTS.md`
- `20_ENGINEERING.md`
- `21_DESIGN_SYSTEM.md`
- `22_COMMERCIAL_MODEL.md`
- `23_CUSTOMER_MODEL.md`
- `24_ROADMAP.md`

`25_STATE.md` records the definition as accepted by explicit owner decision on 23 September 2026, the legitimate state transition as central, and the operating loop as Nilsoft's method. It also records that further formal conditions of legitimacy remain open and that the wider source corpus remains draft pending an explicit source authority decision.

Version 0.4 preserves that distinction.

This candidate develops the frozen v0.3 public theory artefact. Its working formal model remains an argument for examination unless separately accepted into Nilsoft doctrine. Until an explicit v0.4 publication decision occurs, v0.3 remains the frozen published edition.

# Appendix B — Working vocabulary

| Term | Meaning in this paper |
|---|---|
| Governed Computation | The theory and practice of legitimate state transition. Accepted Nilsoft definition. |
| Legitimate state transition | The central object under the accepted framing; exact formal conditions remain open. |
| Legitimacy | The property of satisfying the applicable governing conditions of a transition within a declared domain and scope. |
| Establishment | The evidentiary status of a specific claim about legitimacy, effect, attribution, or successor state. |
| Claim type | A proposition stated at a defined semantic level, such as attempt permitted, effect observed, effect attributed, or transition established. |
| Operational status vector | A non-collapsed representation of resolution, execution, effect, and verification state. |
| Authority | The source, actor, rule, or delegation justified in governing a decision within scope. |
| Canonical state | State designated as authoritative for a declared domain. |
| Derived state | State produced from another source by copying, caching, indexing, projecting, summarising, or generating. |
| Capability | A bounded operation available to an actor or runtime under specified scope and conditions. |
| Constraint | A rule or invariant that limits whether or how an operation may occur. |
| Execution | The attempted invocation of a bounded capability and its reported result. |
| Effect | A change observed after execution; attribution may require further evidence. |
| Proof | Evidence sufficient for a specified transition claim and consequence level. |
| Receipt | A durable record of a material operation and its verification state. |
| Proof debt | Visible state indicating that an attempted operation remains insufficiently verified. |
| Continuity | Preservation or legitimate transformation of domain-significant identity, authority, obligations, provenance, or lineage. |
| Next executable move | The next relevant, authorised, bounded, safe enough, and verifiable action available from current state. |

# Appendix C — Illustrative transition record

The following is a working example of the distinctions a runtime may retain. It is **not** a canonical Nilsoft schema or universal lifecycle.

```yaml
transition:
  id: TR-...
  consequence_class: ...

  request:
    actor: ...
    intent: ...
    target: ...
    requested_at: ...

  predecessor:
    state_ref: ...
    observed_at: ...
    provenance: ...
    freshness: ...

  resolution:
    authority_state: CONFLICTED # RESOLVED | CONFLICTED | MISSING | STALE | DELEGATED | REVOKED
    governing_source: ...
    scope: ...
    owner: ...
    constraints_satisfied: null
    alternatives: []
    uncertainty: []

  capability:
    operation: ...
    actor_scope: ...
    target_scope: ...
    expected_effect: ...
    preconditions: []

  execution:
    state: NOT_ATTEMPTED # ATTEMPTED | ACCEPTED | FAILED
    attempted_at: null
    input_state_ref: ...
    reported_result: null
    retry_identity: null

  effect:
    state: NOT_OBSERVED # MATCHED | PARTIAL | FAILED | INCONCLUSIVE
    observed_at: null
    observed_change: null
    successor_ref: null
    attribution: NOT_CHECKED # ATTRIBUTED | UNATTRIBUTED | INCONCLUSIVE

  verification:
    state: NOT_CHECKED # INSUFFICIENT | VERIFIED | REFUTED | INCONCLUSIVE
    required_strength: ...
    evidence_refs: []
    receipt_id: null
    proof_debt: false

  claims:
    - type: EXECUTION_ACCEPTED
      status: UNESTABLISHED
      evidence_refs: []
    - type: EFFECT_MATCHED
      status: UNESTABLISHED
      evidence_refs: []
    - type: TRANSITION_ESTABLISHED
      status: UNESTABLISHED
      evidence_refs: []

  next_move:
    capability: ...
    blocker: ...
```

The record deliberately does **not** contain one authoritative `success` field.

Its fields should be compressed, expanded, or omitted according to actual product needs, provided a consequential transition does not collapse authority, action, effect, attribution, and proof into one unsupported completion claim.

# Appendix D — Version 0.4 candidate note

Version 0.4 is derived from the frozen v0.3 publication edition.

Its principal change is formal rather than cosmetic: it removes the remaining ambiguity created by treating legitimacy, execution outcome, and evidentiary verification as one top-level judgement.

Relative to version 0.3, this candidate:

- replaces the overloaded four-state judgement with explicit semantic predicates and an operational status vector;
- defines `Legitimate` separately from `Established`;
- introduces claim-relative verification;
- introduces an explicit causal-attribution boundary;
- adds a working claim grammar for attempt, execution, effect, attribution, legitimacy, and establishment;
- states the invariant `ClaimStrength ≤ EvidenceStrength`;
- removes the generic `success` field from the illustrative transition record;
- sharpens operator-interface consequences around over-strong completion claims;
- preserves the distinction between accepted Nilsoft doctrine and working formal theory.

The frozen v0.3 edition remains unchanged.

Version 0.4 does not supersede v0.3 until an explicit publication/freeze decision is made.

---

**Candidate by Nilsoft**  
**Author: Sean Manouge**  
**Version 0.4 — 23 September 2026**