Invite-only · under validation

Make AI's "it's done"
believable.

For people building with Claude Code or Codex CLI (or about to start). When you delegate development to AI, the feeling left at the end is "is it really done?" Trust Driven OS is an operating layer that requires evidence for AI's completion reports and asks for your approval before risky actions.

We do not say "absolutely safe." What we promise is not praying while anxious, but the ease of delegating comfortably while you verify.

GitHub repository Got the repo? Jump to setup → Currently invite-only. Access needs an invitation from the maintainer.

Not an app — a "company structure" you load into your AI

It layers on top of terminal-based AI dev tools like Claude Code or Codex CLI.

It has three parts: an org chart (74 specialist roles with clear boundaries), work regulations (rules for checking, approving, and recording), and programs that automatically verify the rules are followed. If a raw AI tool is a "smart individual," an AI wearing this becomes a team that works like a proper company — it asks before building, reports with evidence, escalates risky decisions for sign-off, and leaves records.

AI itself is being advanced by every vendor. But the more capable the AI, the more the side delegating to it needs structure. We don't build the AI — we build only the structure that makes AI delegable. That is this product's position. Everything runs on your own computer, and your work data is never sent outside.

Has your AI ever done this to you?

None of these are fixed by hoping the AI has a good character. We solve them by putting rules on the system's side.

Says "it's done" — but it doesn't work Left alone, an AI's completion report is just self-assessment. Here, the system automatically bounces back any completion that lacks evidence — test results, a work record. "Probably fine" is not treated as done.
Before you notice, it's doing something dangerous Irreversible actions like publishing, spending, or deleting cannot be run on the AI's judgment alone. They are stopped just before, waiting for your GO.
A sloppy request yields sloppy output Before building something new, the AI asks you: "who is this for?", "why now?". A vague idea becomes a spec just by answering the questions.
You want it smarter, but fear it changing on its own Each time work finishes, the AI team proposes improvements. But it never rewrites a single line of its own rules until you approve. The joy of raising it and the safety of it not changing coexist.

Scenes you'll meet once you start

The moments that first surprise people, shown as the actual conversation.

1. Before building, a question comes back

You"Build a reservation-management app."

AI team"Before building, please answer these first. (1) Why is it needed now? (2) Whose effort does it reduce, and how? (3) How is that work handled today?"

An AI that starts writing immediately gets it wrong immediately. The sloppier the request, the sooner a question comes back — and your answers become the requirements.

2. Completion reports come with evidence

AI team"Done. Evidence: all 75 verification tests pass / change and review records kept / unverified items: none."

Not a bare "it's done," but what was checked and how far, every time. What couldn't be checked is honestly marked "unverified."

3. "Wait, where were we?" — the record answers

You"That invoice cleanup from last week — how far did it get?"

AI team"On July 3 the list formatting was completed (record kept). One item is on hold — waiting on the recipient confirmation. Shall I continue?"

Every task is left in a ledger, so remembering is the AI's job. Even across conversations or days, you resume from where you left off.

4. The AI proposes; you decide

AI team"One improvement learned from this work: 'for this kind of request, ask the budget cap first.' Adopt it?"

You"Adopt."

The more you use it, the smarter it gets for your work — but it changes only when you approve. It feels like raising a team member.

Other reasons it feels easy

AI-driven development is convenient but easy to scatter and easy to break. We close off the typical failures ahead of time.

Decide "which one is real" first The most common accident in AI-driven development is losing track of folders and branches. Before starting, a rule is built in to decide the location, the branch, and the source of truth — then move. No more "final_latest_actually-final" folders.
Every piece of work leaves a record Who, when, what, why. Work records, review records, adopted-improvement records pile up in a ledger automatically. A week later, "why is it like this?" is answered by the record, not memory.
One entrance, a pro-standard specialist team behind it Design, implementation, QA, research, writing, even quote/invoice admin — 74 specialist roles divide the work behind one request desk. Each reads its field's pro standard before building, so "AI-looking screens" and "vaguely plausible text" are banned by default.
Ceremony scales with the weight of the request A small ask like a typo fix finishes quickly with no checks. The more publishing or spending is involved, the deeper the checks get automatically. No heavy ritual for light work.
Japanese work doesn't fall apart Tofu (missing) glyphs, line breaks in odd places, Letter paper where A4 was meant, CSV mojibake in Excel — it's designed to avoid the pitfalls of Japanese work from the start.

Things actually running on this structure

Trust Driven OS is also a foundation for building tools and services. Here are things published on the same structure, and separate brands whose production and operation it supported.

Event Dashboard Rooms → A dashboard to manage event room assignments and operational status on one screen. (live)
Calc Sheet → A calculation sheet with spreadsheet-style formulas that runs in the browser alone. (live)
All works → The list of services and tools published on this structure.

Separate brands supported with this structure

The following are independent brands. They are shown as real examples whose production and operation this structure supported.

The Art of SHEER → An art brand, run independently on its own domain.
Folding Arts → A folding-form brand, run independently on its own domain.

How far can you trust it — scores published without padding

A product that sells "no bragging without evidence" cannot pad its own marketing. We publish the verification results, including the items not yet met (as of 2026-07-08).

Check	Measured	Verdict
Verification tests for completion reports and safety gates	all 75 pass	pass
Request intake success rate	95.79% (832 cases)	pass
Safety-gate false triggers	0	pass
Collisions when multiple AIs work at once	0 (20 of 20 succeeded)	pass
Consecutive incident-free days	day 2 (target 30, counted in real days)	not yet
Reproduction in a third party's environment	pending	not yet

The two unmet items can only be filled by time and outside collaborators. We will not fake the day count to fill them.

The idea at the root — trust-driven as a design principle

From here on is for those who want to read it. You can skip it and still use the product.

The name Trust Driven is not decoration; it is the design principle. We concluded that people can't trust AI not because AI is malicious, but because trust could only be measured by "impression." So this system treats trust as records, not impressions. Evidence-backed completion, approved changes, bounded roles — trust becomes an asset that accrues daily, not a mood.

This isn't only about humans and AI. The same discipline holds among the 74 specialist roles inside. Who owns what, and what they don't. How work is handed over and received. Because the AIs trust each other by contract, the team doesn't collapse.

The goal is not to bind with surveillance, but a way of working where trust, autonomy, curiosity, and honesty hold at the same time. AI can move freely because the boundaries are clear. It can keep learning because changes require approval. It can stay honest because saying "not done yet" honestly is not penalized by the system.

This site not claiming "absolutely safe" is part of the same philosophy. We believe trust is not something you declare, but something that keeps being verified.

Get started — to your first request in 10 minutes

It layers on top of AI coding tools like Claude Code or Codex CLI. The first launch commands differ slightly by OS.

macOS / Linux

# 1. Get it (invite-only repository)
git clone https://github.com/sheer-jp/trust-driven-os-dist.git
cd trust-driven-os-dist

# 2. Set up (prints READY at the end)
./runtime/setup.sh

# 3. Your first request
./runtime/trust.sh goal "fix a typo in the README"

Windows (WSL)

# 1. Install WSL (first time only; reboot after)
wsl --install

# 2. Install dependencies inside WSL (Ubuntu)
sudo apt update && sudo apt install -y git python3 ripgrep jq sqlite3 tmux

# 3. Get it and launch (in PowerShell)
git clone https://github.com/sheer-jp/trust-driven-os-dist.git
cd trust-driven-os-dist
powershell -File .\windows\setup.ps1
powershell -File .\windows\trust.ps1 "fix a typo in the README"

On Windows the same thing runs through WSL (Ubuntu) (native-machine proof is still in progress). Personal info and work data are stored separately from the system itself, and no personal data is included in the distribution.

A detailed guide is in the bundled README (about a 10-minute read). To request an invitation, contact the maintainer (Arisa) directly.

Make AI's "it's done"believable.