A public, implementation-independent model for designing AI-assisted systems that are useful, governable, recoverable, and safe to operate at scale.
The central idea is simple:
Observe authoritative state, determine what is allowed, delegate to the correct owner, verify the result, and preserve a recovery path.
AI should increase execution capacity without making authority ambiguous.
Automation does not create authority.
Every meaningful action should have:
- an identified owner;
- an explicit scope;
- defined preconditions;
- a known mutation ceiling;
- verification requirements;
- and a recovery path.
Invocation is not authorization.
State-changing actions should be based on current evidence, not assumptions, stale snapshots, or generated summaries.
Evidence should answer:
- What is true now?
- Who owns this state?
- Is the evidence current?
- What action is permitted?
- What would prove success?
Use the least powerful capability that can complete the task.
read capability
!= invocation capability
!= mutation authorization
A system that can inspect something does not automatically have permission to invoke it.
A system that can invoke something does not automatically have permission to mutate it.
Owner-local authority
The orchestration layer coordinates.
The owning subsystem decides whether an action is actually allowed.
A higher-level controller may route or invoke an action, but the owner must independently validate its own:
* contract;
* scope;
* prerequisites;
* mutation ceiling;
* rollback;
* and post-action verification.
Fail closed
Ambiguity should reduce authority, not increase it.
If identity, evidence, ownership, scope, or verification cannot be established, the system should stop or degrade into observation-only operation.
Reversibility
Material mutations require a bounded recovery path.
Depending on the system, this may include:
* version control;
* backups;
* receipts;
* deployment artifacts;
* rollback commands;
* last-known-good state;
* or owner-specific recovery procedures.
Convergence over duplication
Do not create another controller, policy, registry, or documentation surface when an existing owner can absorb the requirement without weakening its boundary.
New capabilities should have a distinct purpose and a clearly non-colliding authority surface.
⸻
2. Authority Direction
When multiple sources describe the same system, authority should flow deliberately.
A useful hierarchy is:
1. Current explicit operator intent, subject to safety and owner contracts.
2. Current owner-specific runtime instructions.
3. Machine-readable contracts and registries.
4. Owner-generated evidence describing current state.
5. Reviewed source defining the next governed implementation.
6. Generated views, mirrors, projections, caches, and historical records.
A newer timestamp does not automatically create authority.
A more convenient representation does not automatically create authority.
A generated artifact should not silently become the source from which its own authority is derived.
⸻
3. System Model
A governed AI system can be understood as several distinct layers.
Operator
Defines intent and grants task-level direction.
Control plane
Provides cross-system visibility and sequencing.
It may:
* read authoritative evidence;
* determine posture;
* identify the correct owner;
* sequence safe next actions;
* invoke explicitly permitted owner operations.
It should not silently absorb the authority of the systems beneath it.
Owners
Subsystems that possess domain-specific authority.
Examples include:
* deployment;
* lifecycle;
* integrity;
* routing;
* recovery;
* repository maintenance;
* client supervision;
* fleet reconciliation.
Validators
Determine whether contracts or invariants hold.
Validation capability does not imply repair capability.
Runtime
The implementation actually operating in the environment.
Reviewed source and deployed runtime are separate facts.
Evidence
Machine-readable observations, receipts, identities, health states, and verification artifacts produced by owners.
Recovery
The bounded mechanism for returning a failed or unsafe system to a known-good state.
⸻
4. Operating Posture
A whole-system controller can expose a simple posture without inventing competing subsystem truth.
OPEN
Required evidence is sufficiently current and healthy for normal governed operation.
RESTRICTED
Operation may continue, but stale evidence, unresolved attention states, or incomplete verification prevent expansion of mutation scope.
FROZEN
Required authority, integrity, identity, or contract evidence is unavailable or failing.
Only diagnostics and separately governed recovery should proceed.
⸻
5. Change Lifecycle
A durable system change should generally follow:
DISCOVER
↓
CLASSIFY
↓
IDENTIFY OWNER
↓
DECLARE CONTRACT
↓
VALIDATE
↓
REVIEW
↓
MERGE
↓
DEPLOY
↓
VERIFY
↓
PROMOTE KNOWN-GOOD STATE
Each transition should be independently meaningful.
In particular:
merged != deployed
deployed != verified
verified != authorized for broader mutation
⸻
6. Mutation Contract
A state-changing operation should define, at minimum:
owner:
action:
scope:
preconditions:
evidence_required:
confirmation_required:
mutation_ceiling:
backup_or_recovery:
verification:
receipt:
failure_behavior:
Mutation should be bounded to declared targets.
Successful command execution alone is not sufficient evidence of successful mutation.
⸻
7. Verification
Post-action verification should establish that:
* the intended target changed;
* unrelated targets did not change;
* the resulting state satisfies the owner contract;
* runtime identity is what was expected;
* required evidence was freshly produced;
* and rollback remains possible where applicable.
The system should distinguish between:
action invoked
action accepted
action completed
verification passed
These are not equivalent states.
⸻
8. Last Known Good
A known-good state should represent verified reality, not merely the newest revision.
Promotion should occur only after the relevant implementation has:
* passed required validation;
* been deployed where applicable;
* been verified;
* and produced the evidence required by its owner.
Known-good state should support recovery, not simply reporting.
⸻
9. AI Agent Behavior
AI agents operating inside this model may:
* inspect;
* reason;
* propose;
* classify;
* validate;
* generate plans;
* execute explicitly admitted actions;
* and verify outcomes.
They should not:
* infer mutation authority from tool access;
* broaden scope silently;
* bypass owner contracts;
* treat generated output as authoritative merely because it is recent;
* convert an observation into permission;
* or hide uncertainty behind successful execution.
⸻
10. Definition of Done
A change is not complete because code exists.
Depending on scope, done means:
* ownership is clear;
* authority is explicit;
* source is reviewed;
* validation passes;
* required evidence exists;
* runtime parity is verified;
* mutation is bounded;
* rollback is known;
* documentation routes to the correct source of truth;
* and the resulting system is understandable by the next operator or agent.
⸻
11. Documentation Rule
Documentation should explain and route authority.
Machine-readable contracts should enforce exact semantics.
Documentation alone should not grant runtime mutation authority.
Current counts and volatile runtime state should come from generated evidence rather than manually maintained prose.
⸻
12. Design Test
For any new capability, ask:
1. What problem does this solve?
2. Who owns it?
3. Does an existing owner already cover it?
4. What evidence establishes current state?
5. What is the minimum required capability?
6. What permits mutation?
7. How is success verified?
8. How is failure recovered?
9. What becomes authoritative?
10. Can the component be removed without breaking unrelated owners?
If those answers are unclear, the design is not finished.
⸻
Public Contract
{
"schema_version": "jared.ai-operating-model/v1",
"classification": "public-reference",
"authority": "conceptual",
"scope": "AI-assisted system architecture and governance",
"mutation_authority": "none",
"counts_source": "derived-only",
"implementation_independent": true
}
This document explains an operating model.
It does not grant authority to any implementation, runtime, repository, agent, or controller.
source & further reading
gist.github.com — original article
rules for ai agents
Free Claude AI API keys and credits for agentic coding & vibe coding for developers.
Velaru audit anchor — 658 entries — SCITT RFC9943 — 2026-08-29T00:14:22.060739