JS

03AI infrastructure and R&D

Atlas / Johann OS

A governed AI runtime built for a single operator, where the reasoning layer and the enforcement layer are separate systems and the audit chain is anchored outside the machine that writes it.

Role
System vision, governance architecture, qualification strategy, orchestration design, and acceptance
Timeframe
2026 to present, active R&D
Status
In development · in daily use by one operator
Outcome
A deny-by-default runtime where approval binds to an exact payload hash, the audit chain is anchored as signed tags in a separate repository, and an independent verifier under its own identity decides whether work actually passed.
How I work, on every project
I decide what the system is for, what it is forbidden to do, and what the finished outcome must be. AI agents execute against written guidance, and that guidance is ready only when the outcome is explicit and agreed.

What this is

Atlas is the AI system I run on my own machine, built the way I would want one built before it touched anything that mattered.

The deal every AI assistant offers is the same. Give it access, get leverage. That deal is fine right up until the day it is wrong about something, and then the interesting question is not whether the model made a mistake. Models make mistakes. The question is whether anything in the system was ever in a position to catch it.

Atlas is my answer, and I am its only user. It reads and reasons freely. It is permitted to change almost nothing without me. Every step it takes lands in a record that can be checked afterwards, including the steps I approved and should not have.

Atlas is also where the discipline gets tested before it goes near client work. The approval boundaries and evidence chains in the Civilocity systems were proven here first, on the system whose failures land on me.

The problem

Three things are wrong with the ordinary arrangement.

The first is that the model is its own guard. Instructions telling an assistant what not to do are requests, and they are evaluated by the same thing they are meant to restrain. If the only reason a dangerous action did not happen is that the model chose well that time, then nothing was actually stopping it.

The second is that an audit log written by the agent is not evidence about the agent. Neither is a purely local log, because a local log can be rewritten by whoever administers the machine. That includes me. A record that only proves I did not feel like editing it proves very little.

The third is the one I like least. I am the owner, the builder, and the only reviewer. A system where I approve my own work has no independent check in it, and my approval is exactly the signature that would be worth forging.

Where the boundary sits

Proposes THE MODEL READS AND REASONS FREELY Runtime permits ORDINARY CODE DENY BY DEFAULT Person approves AGAINST THE EXACT PAYLOAD HASH Anchored record HASH-CHAINED SIGNED OUTSIDE THE MACHINE REASONING LAYER ENFORCEMENT LAYER
The reasoning layer proposes. The runtime decides what is permitted. A person approves. The record lands in a chain anchored outside the machine that writes it.

The reasoning layer proposes. The runtime decides what is permitted. A person approves.

Nothing that changes state runs on the model's say-so. A proposed action becomes a pending record, and approving it requires the exact hash of its payload, so approval attaches to a specific set of bytes rather than to a description of them. A pending action cannot be edited. You supersede it, which mints a new payload hash and sends the replacement back for review on its own terms. The kill switch ships enabledC2.

Authority is scoped by token rather than assumed. Raw captured material is hidden by default, and deliberately revealing it is itself an audited event, requiring the last eight characters of the content hash for the sensitive classes. Raw text never enters audit metadata.

An audit log has to survive its own administrator

The chain is hash linked and written to two stores that are verified separately, a database table and an append-only fileC6, so that a dropped line or an edited row surfaces as a disagreement between them rather than as silence. One scheduled exporter is the only writer of the file, protected by three independent locks, and a crash mid-write is resolved by reconciliation rather than by appending again.

None of that solves the real problem, which is that a wholly local chain can be coherently rewritten by a local administrator. So the chain is anchored outside itself. Receipts, meaning hashes and counts and never event content, are committed as signed tags to a separate private repository, using a signing key deliberately held outside the runtime's own secret store. Publication runs every 250 events or six hours, whichever comes first. The anchor timestamp advances only once the receipt has been retrieved from the remote and its signature verified, so a publication that merely left the machine does not count as one that arrived.

The verifier does not take the worker's word

Newer work in the runtime splits a task among three parties that do not trust each other: a manager that grants authority, a worker that does the job and declares what it produced, and a verifier that decides whether that declaration is true.

The verifier runs under its own principal identityC7, stamped into every receipt it issues. It receives read-only access to the approved baseline, the sealed artifacts, and its own code. It recomputes every fact it asserts and never accepts a manifest field it could derive itself.

Four checks are frozen, each aimed at a specific way a result could be a lie. Verifying against the wrong revision is caught by comparing the supplied baseline identity to the one the authority envelope approved. An artifact altered after sealing is caught by re-reading every object through content-addressed verification, which holds even where filesystem protection has been defeated. A manufactured pass, meaning a protected baseline test quietly modified so the work looks finished, is caught by hashing every declared artifact that shadows a protected test path. And a verifier whose own code no longer hashes to its approved identity refuses to claim success at all.

The manager resolves a task on the verifier's verdict. The worker's claim resolves nothing.

The worker and the clock in this layer are synthetic. What is proven is the protocol, not a production workload.

What it is not allowed to do

Autonomy in Atlas scales with reversibility, not with how well the model has been behaving lately. An action class graduates to running without per-instance approval only after a defined and tested undo exists, the blast radius is bounded, injection and misuse tests are green, the audit chain verifies, and at least ten human-approved executions have completed cleanly across at least fourteen daysC9. Two undos inside seven days suspend the rule automatically. No track record lets Atlas widen its own authority.

Some things never graduate: money movement, password manager access, secrets and private keys, unbounded host shell, recursive delete, autonomous privilege expansion, final decisions in regulated matters, and disabling the audit, the sanitizer, the injection controls, or the kill switch. Recovery from backup resets autonomy to zero until it is manually re-verified.

The decisions I would defend

Enforcement is not the model's job. The runtime is ordinary code with no opinions, and it is the thing that says no. That separation is the whole design.

Reviewing my own work does not count. Contract changes pass an independent architect review whose revise verdict is a hard stop rather than an opinion, and the system keeps a standing register of its own open governance contradictions rather than resolving them quietly. One review round returned ten confirmed defectsC8 in code I had already accepted. Ten defects is the argument for the review, not against it.

Honest maturity is part of the product. Capabilities are held in four separate buckets: working, qualified under test, in development, and not permitted to execute. A system that cannot say what it has not yet earned is not a governed system.

Evidence

Demonstrations use synthetic material. Nothing from the personal vault is published.

  • The four frozen verifier checks with the specific failure each one detects, and the tests that exercise them
  • Audit chain verification across both stores, plus an anchor receipt and its verified signature
  • A sanitized design and qualification document pair, the autonomy policy and never-list as written, and the test inventory at the pinned revision

Status

Working and in daily use. The deny-by-default enforcement runtime, payload-hash approval with supersede, the kill switch, token-scoped clients, the hash-chained audit across both stores, the external signed anchor, and the governed capture and memory flow.

Qualified under test. 2,461 automated tests are collected across 208 test filesC1 at the pinned revision, and the release procedure requires a clean full-suite run before any deploy. 74 paired design and qualification documentsC4 govern the system, with 25 or more versioned JSON Schemas.

In development. The worker contract runtime, with its manager, worker, and independent verifier, running against a synthetic worker and a synthetic clock.

Not permitted. External provider access, consultation, and supervised coding remain forbidden through the runtime. Nothing on the never-list executes under any approval.

Known gaps. One user, one operator, one machine. No multi-user operation, no unattended autonomy, no production hardening, and no claim here implies otherwise. The test figure above is a collection count at the pinned revision rather than a published pass count; it will be restated as a pass count when a full run is archived as evidence. The worker contract layer is synthetic and has not carried real work. Independent review means one reviewer, and that reviewer is itself an AI.

Claims ledger

What this page asserts, and where each assertion is checked. Each entry names its evidence and the source-repository commit it was checked against. A number that is not in this ledger does not appear on the page.

C1

2,461 automated tests are collected across 208 test files in the governed runtime, which ships only after a clean full-suite run.

documented
Test suite summary and repository inventory; report excerpt in the evidence room
checked 2026-08-30 at 48f62b6c0f
C2

Planning, approval, and execution are separate control boundaries: a default-deny enforcement runtime with a kill switch, token-scoped clients, and actions approved only against exact payload hashes, logged to a hash-chained audit trail.

documented
Architecture and design/qualification documents; simplified control-boundary diagram planned in Phase 3
checked 2026-08-02 at 77280451e2
C3

Qualification gates produce cryptographic evidence bundles hash-pinned to the repository state, including deliberately adversarial cases, and the adversarial canary corpus documents its own known gaps.

documented
Evidence bundle set from qualification gates A2–A4/B2–B3; sample synthetic bundle planned for the evidence room
checked 2026-08-02 at 77280451e2
C4

74 paired design and qualification documents govern the system, with 25+ versioned JSON Schemas.

documented
Repository documentation inventory; sanitized design/qualification pair shown on the Method page
checked 2026-08-02 at 77280451e2
C5

A companion service-identity sensor (C#/.NET Native AOT) passes 479 of 479 tests, with adversarial static scans for prohibited APIs and five qualification gates.

documented
Test suite and qualification gate records (gates C1–C5); excerpt in the evidence room
checked 2026-08-02 at c8bbd24a58
C6

The hash-chained audit is written to two independently verified stores (a database table and an append-only JSONL) by a single scheduled exporter under three independent locks, and is anchored outside the machine: receipts carrying hashes and counts only are committed as signed git tags to a separate private repository, signed with a key held outside the runtime's secret store, every 250 events or 6 hours, whichever comes first.

documented
Audit chain, exporter, and anchor modules in the Gatekeeper runtime, with the section 8.2/8.4 frozen parameters; chain verification output and a signed anchor receipt planned for the evidence room
checked 2026-08-30 at 48f62b6c0f
C7

Worker output is resolved by an independent verifier running under its own principal identity with read-only inputs, applying four frozen checks that detect a wrong baseline, a manifest mismatch, a manufactured pass, and a verifier whose own code no longer matches its approved identity; the manager resolves a task on the verifier's verdict rather than the worker's claim.

documented
Independent verifier module and its dedicated test file in the Gatekeeper runtime worker-contract layer
checked 2026-08-30 at 07ff48da3b
C8

Contract changes pass an independent architect review whose revise verdict is a hard stop, and the system maintains a standing register of its own open governance contradictions; one review round returned ten confirmed defects in already-accepted code.

documented
Review round records in the governance track; the ten-defect round is the WS5B stage E6 hardening commit
checked 2026-08-30 at c3a6b0578b
C9

Autonomy is earned against written thresholds rather than granted: an action class may run without per-instance approval only after a tested undo, bounded blast radius, green injection tests, a verifying audit chain, at least 10 clean human-approved executions and at least 14 days; two undos within 7 days suspend the rule automatically, and a never-list (money movement, credential stores, secrets, unbounded shell, recursive delete, self-expansion of privilege, disabling audit or kill switch) never graduates.

documented
Autonomy policy in the runtime governance set, version 2026-07-10
checked 2026-08-30 at 48f62b6c0f

Next

04Operator-Safe AI Workflows