Reviewed statements our Platform and Systems Architect answers from: the platform, how a change reaches production, the Harness, observability and how data is kept safe.
- The Harness: independent review
In the Harness, the reviewer always comes from a different AI model family than the author, because tools on the same engine share its blind spots, so no model marks its own homework. If no qualified reviewer is free, the change waits rather than merging unreviewed.
- The Harness: evidence
The merge decision reads only evidence, such as test results, gate results and diffs, and never the AI's own summary of its work. Those claims are kept, but only to catch a model whose story contradicts the evidence.
- The Harness: no override
The merge queue has no override switch, because an override flag is a human in the loop wearing a disguise. If the queue itself is unreachable, the founder can grant one scoped, expiring exception, and never for a failing test, a failing gate or out-of-scope changes.
- The Harness: separation of roles
A builder never chooses its own reviewer; selection is fixed policy. And a reviewer cannot change a single byte of the work it reviews: the system compares the workspace before and after every review rather than trusting it.
- Builder Loop
Our loop assumes any builder can stop without warning at any moment. So work is always pushed and its running log kept current, and the next builder can pick it up from the log and the branch alone.
- Data safety and security
Registering alone grants no access. A new account can reach nothing until a role is explicitly granted, so access is closed by default, and nobody ever sets another person's password.
- What the platform is
CHAI Systems is an AI-first company, run today by one human, its founder, as a starting point rather than a rule. Its platform lets the founder and AI build tools run the company and build its products.
- What the platform is
Beneath the two consoles sit shared services, called owners, for delivery, scheduling, memory, notifications and voice. The consoles, the command line and the build tools all use these same shared capabilities.
- Cell and smallest deployable unit
A Cell is a self-hosted deployment of the platform and its boundary for placement and failure. A Cell is deployed as a whole; inside it, a service owner is the unit a deployment changes and restarts.
- How deployments work
A change is deployed only after it reaches the main line. A deployment then rolls one machine at a time, restarts only what changed, and stops at the first machine whose restart it cannot prove. Deploying needs a typed confirmation and a fresh sign-in.
- The Harness
Work delivered through the Harness lands only through its merge queue, the single writer to the main line. It merges only when tests pass with their count recorded, repository gates pass, declared outcomes are met, changes stay in scope, and all is re-checked after rebasing.
- The Harness: review lenses
Review is not one pass. It runs through named lenses, such as staff engineer, security officer, QA lead, release engineer and technical writer, chosen by what is being built, and every lens that was skipped is named so a gap never reads as coverage.
- The Harness: findings
Every review finding is either blocking or improving. A blocking finding means the change is wrong, unsafe or misses its finish line, and it is fixed before landing; an improving finding is noted, and the change lands.
- Observability
The standard is that every service can be seen and driven from the control plane. A service counts as done only when it has a health check, its own start and stop controls, registration for monitoring and operations, and tests, and its logs carry a time and a level.
- Data safety and security
Each Cell runs its own self-hosted identity service. Every call must be authenticated and anonymous calls are refused, because network position is not an identity, and every change and every refusal is audited to a person or a named service.
- Data safety and security
Internal consoles and services listen only on their own machine unless an exception is deliberate. Secrets never appear in source code, logs, chat or work records, and the security standard requires data to be encrypted at rest and in transit.
- Data safety and security
The public conversation service is built to stay apart from everything internal: it has its own identity, storage and keys, it cannot reach the internet itself, and it holds no cloud credentials; a separate helper that answers only to it does that work.
- Delivery Loop
Every non-trivial piece of work follows the Delivery Loop: a brief that states the goal, the assumptions and how done will be shown; the build; verification against that bar; and a record of what was proven, what failed and what is next.
- Builder Loop
The Builder Loop sets how a builder works: each change is built in its own isolated workspace, pushed early to its own remote branch so nothing lives on one machine, logged as it goes, handed over cleanly, and finished with nothing left orphaned.
- Work cards
Work is tracked on work cards that state what is true right now with its evidence, checkable finish lines each with its status, the single next action, and what it is blocked by and who can clear it. Cards are updated from evidence, never from their own earlier text.
- Evidence
Every claim about a result is labelled Proven, Estimated, Hypothesis or Untested. An estimate is never presented as proven, and negative results are reported as plainly as positive ones.
- Delivery
Work that does not go through the Harness lands only in break-glass circumstances, and even then a human approval is recorded.
- Review
Today the independent review informs rather than blocks, while its sensitivity and accuracy improve. At launch, findings will carry a severity: some, such as style, stay informational, and others will block the merge.
Each statement here is approved by the founder and due for re-review within 90 days.