Portfolio → AI Control Center
Finished is not the same as correct.
AI Control Center is a Windows application that coordinates AI coding agents through defined roles, verification steps, and human approval. It makes AI prove its work: every step leaves evidence tied to the version it checked, and the tests themselves are proven by breaking the code on purpose.
Swipe sideways to see the whole diagram.
One person coordinating AI coding agents needs to know who checked the work, which version they checked, and whether the test could catch a mistake.
I defined the product rules and architecture, reviewed designs before implementation, and checked the app through use. AI coding agents wrote the code.
Start with the version-bound evidence diagram and deliberate-break verification flow. This case presents design schematics and dated review results and limits; no product demo is provided.
On a report, “done” and “done right” look identical
An AI agent is very good at finishing the visible task. A test that always passes, a value computed and pushed to the screen that nothing ever reads, a review stamped on a version that has since changed — all of these report green. One sweep of this project found 30 of them.
So the product is built around one question: what would it take to actually know?
| Risk to avoid | How AICC responds |
|---|---|
| No explicit point where a person decides | It stops when it's your call |
| The same role does the work and sets the bar | Whoever does the work never sets the bar |
| An approval detached from the version it checked | An approval is bound to a version; change it and it expires |
| Passing tests that may not catch a failure | Green counts only after something has turned it red |
| Records that can only be read inside the app | Records are plain text, in your folder, verifiable without the app |
A stamp is worth exactly as much as the version it was stamped on
Read the detail
Every role in a run leaves a stamp. A stamp records who, when, on which content digest, and on what evidence. Approval requires every required stamp to sit on the same digest; a change to the content invalidates only the stamps whose inputs changed, so unaffected work is not re-done.
Decisions are recorded as a hash chain that can be exported and checked with a standalone verifier that needs nothing from the app. It detects any altered or deleted entry in the middle of the chain; it does not claim to detect a chain rewritten end to end.
A green test only counts after something has turned it red
- Restores from a copy, never
git checkout— that once destroyed uncommitted work - Zero skips is a hard rule: an empty parametrize producing one SKIP fails the run
- Two layers, neither substitutes for the other: pytest checks a value is read; a DOM probe in a real QWebEngine checks it is drawn
- A dedicated tool hunts the recurring defect “computed, pushed to the screen, read by nothing”
Whoever does the work never sets the bar
| Duty | Read | Write files | Set the acceptance bar | Approve |
|---|---|---|---|---|
| Plan | ● | — | ● | — |
| Work | ● | ● only this one | never | — |
| Review | ● | — | ● | — |
| Approve | ● | — | — | ● can't override a machine stamp |
Each role is one seat with its own duty, its own conversation and its own view of the rules. The engine dispatches by duty, not by seat name — and it blocks a role from verifying its own work.
- The acceptance bar is set by a non-Work seat; the engine refuses if the criteria stamp and the implementation stamp come from the same role
- A rejection is routed to the responsible seat by duty, not by position
- A duty that grants power is never auto-assigned: if you didn't seat it, the engine won't pick one for you
Under the hood: Claude Code runs read-only duties in plan mode; Codex runs them in a read-only sandbox. Only Work gets write access. These are the vendor tools' own permission modes: AICC asks for them, and is not an operating-system sandbox itself.
Most tools sell more automation. This one is built to stop.
Power is never handed out by default
A duty that grants power is never auto-assigned. If you didn't seat it, the engine won't pick one for you.
“Can't verify” is not “broken”
A task that declares no way to check it is marked not verifiable. It isn't treated as a failure, so no agent is sent to fix what isn't broken.
Your approval can't overrule a check
If the machine check failed, approving doesn't make it pass. The approver reads; it can't rewrite the result.
It's a graph — and each node still has the four layers inside it
Prompt, context, harness, loop, graph — the five layers people now describe as graph engineering. They aren't stages that replace each other; every run in AICC uses all five at once, and the fix loop lives inside one node.
Where each layer lives in the code
| Prompt | what to do, limits, success criteria, return format — prompt_builder |
|---|---|
| Context | just enough for this step: each duty receives only its rule layers plus the shared project memory |
| Harness | what it may touch: the CLI runner, the project's sensitivity level and permission mode |
| Loop | the fix loop in the workflow worker: up to two repair attempts, then the run goes back to a person |
| Graph | the lineup of seats and the nine step gates; state kept in run records, a timeline, and the stamp chain |
Three things, stated plainly
It doesn't take what you didn't give it
Your Claude or Codex login never passes through AICC — it only opens the vendor's own sign-in. No browser or app caches are read. A test fails if any new way to accept an API key appears in the credential module.
It doesn't resell the model
You use your own Claude and Codex accounts, under their own usage limits. AICC adds nothing on top of what you pay them.
It has no server of its own
No account, no sign-up, no AICC server. Project records are plain-text files in your own folder, and AICC is itself the first project it manages. Prompts do go to Claude or Codex through their own command-line tools, and the optional LINE and Google Drive features have their own data paths.
What exists, what's proven, what isn't
Built
- Windows desktop app; an earlier build was installed, launched and uninstalled twice on Windows
- Roles with duty-bound permissions, stamp chain, timeline, exportable decision log
- One person running several projects side by side
Verified
- An AI-assisted pre-release review ran 2,219 tests: 2,200 passed, 19 failed, 0 skipped; the repository explains each failure
- The same review ran 853 deliberate breaks and published the misses too
- 30 false greens found and cleared to 0 (Aug 24–27, 2026)
Next
- Owner acceptance run for the next beta
- The public repository ships source only; the current installer still needs a full upgrade test. Known limits are listed in SECURITY.md
- The source is on GitHub; the breaking tool also stands on its own as negative-control