Built for work that has to be provable.
Say what you want built.
Watch it happen.
One sentence in, and ForgeOS plans, builds and runs your own checks — narrating as it works, showing you the exact change and the page it produces, waiting for your accept. Your workspace is born ready: a sample project connected, open-source models included, nothing to configure. Free during early access.
8
Gates before any release
23
Repositories under governance
0
Actions taken without a grant
Append-only
Evidence chain
1 · Ask
Type an outcome. Auto plans it and starts building in an isolated copy — your code is never written to.
2 · Watch
The builder narrates every step in the thread — what it edited, why, and what the repository’s own tests said.
3 · Accept
The exact diff and the rendered page arrive inline. One tap accepts; one tap downloads the project.
What ForgeOS does
One loop, from intent to running software.
You describe an outcome. ForgeOS carries it the whole way and shows its work.
- Understands
Reads the repository, its structure, dependencies and history, and states what it believes before acting.
- Plans
Turns the goal into ordered work with a stated outcome, the files it expects to touch, and what it will not do.
- Builds
Writes the change on a branch, against a named base, in scoped paths.
- Runs your checks
Runs your repository’s own test suite against the change, in an isolated copy, and shows you what it said. It reports those results; it does not add security or accessibility checks of its own.
- Shows proof
Every claim links to the run that produced it. What was not checked is stated as not checked.
- Asks you
Only for real decisions — with the risk, the blast radius, the cost, and what happens if you do nothing.
- Publishes
Puts your project online at a plain web address you choose, and takes it down again when you say so. Deploying to your own production, with rollback, is not connected yet — and ForgeOS says so rather than implying it.
- Keeps improving
Watches what it shipped, finds regressions and gaps, and proposes the next change.
You write
An outcome, in plain language
ForgeOS carries
Plan → build → verify → release
You decide
Only what genuinely needs an owner
You receive
Working software, with evidence
How it works
A goal moves through states you can see.
These are the states ForgeOS actually uses — not a marketing abstraction over them.
| State | What it means for you |
|---|---|
| planned | ForgeOS has read the system and written the plan. Nothing has been changed. |
| ready | The plan is accepted and the work is queued to start. |
| leased | The work is being done right now, on a branch, in scoped paths. |
| blocked | ForgeOS stopped because it needs a decision or an input it does not have. |
| in review | Built, and your repository’s own checks ran and passed. Waiting on a decision. |
| completed | Accepted, and written into your project. Whether it was independently reviewed, deployed or released are separate facts with their own receipts — this state does not claim any of them. |
| failed | It did not work and ForgeOS is telling you rather than retrying quietly. |
| cancelled | Stopped by you, or superseded. |
ForgeOS never takes a consequential action on its own authority. Writing to your source, deploying, touching production or spending beyond your limit each require a decision you grant — and every one is reversible or tells you plainly that it is not.
Repository connection & authority
Connect a repository. Grant only what you mean to.
ForgeOS starts read-only. Every further capability is a separate, revocable grant — and where a grant is absent, execution stops rather than assumes.
Deploy is its own decision. Releasing is never implied by permission to write code; production is a further, explicit grant. Spending caps, model and provider choices, and integration scope are yours to set and to change.
The full model, with every consequential authority the system can hold, is on the Trust page.
The authority model
Your goal → ForgeOS
Models, agents and tools
Not tied to one model or one vendor.
ForgeOS routes work across models and agents, records which one did what, and keeps that choice yours. A model is a component, not the product.
Choose providers
Restrict work to the providers you permit, per repository if you need to.
Attributed work
Every change records which model and agent produced it, and the evidence for it.
Tools under policy
External tools and integrations run inside the authority you granted, never beyond it.
Security, privacy and governance
Authority is explicit, recorded, and reversible.
Fail closed
When ForgeOS lacks authority or evidence, it stops and asks. It does not proceed on assumption.
Recorded approvals
Every consequential decision is attributed to a person, with what they were shown at the time.
Tenant boundaries
Your repositories, evidence and history stay yours and are not pooled across customers.
Readable audit history
What happened, who authorised it, what it affected, and how to reverse it.
What we do not claim. ForgeOS does not promise correct software without review, and it does not certify your compliance. It tells you what was verified, by what, and what remains unverified — including when the honest answer is that it does not know.
The product
The conversation is where all of this lives.
The plan, the work, the proof and the decisions — one thread, owned by you. Mission Control stays one step behind it, as the console.
Start with one goal.
Connect a repository, describe an outcome, and watch ForgeOS plan it before anything changes.