ForgeOSby Medina19
Sign in Create account

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 — then shows you the exact change and waits for your accept. Your workspace opens ready, and says on its first screen which models this instance has ready. Free during early access.

A ForgeOS conversation at the review moment: the exact diff the builder produced in an isolated copy, with Not this, See the evidence and Accept beneath it, and the repository’s own tests passing in the evidence panel.

Checked

Your own tests run before anything reaches you

Read-only

Until you allow writing, one repository at a time

Nothing spent

Until a goal asks, and never past the limit you set

Append-only

Every claim links to the run that produced it

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.

Measured, not promised. Over a thousand builds on free open-source models, on a corpus audited first: 68.8% verified end to end — with false successes counted against the product (15.3%) and reported, never rounded away. The runs are retained in the repository, and the Trust page says what each rung of “done” means.

  1. Understands

    Reads the repository, its structure, dependencies and history, and states what it believes before acting.

  2. Plans

    Turns the goal into ordered work with a stated outcome, the files it expects to touch, and what it will not do.

  3. Builds

    Writes the change on a branch, against a named base, in scoped paths.

  4. Runs your checks

    Runs your repository’s own test suite against the change, in an isolated copy. It reports those results; it does not add security or accessibility checks of its own.

  1. Shows proof

    Every claim links to the run that produced it. What was not checked is stated as not checked.

  2. Asks you

    Only for real decisions — with the risk, the blast radius, the cost, and what happens if you do nothing.

  3. Publishes

    Puts your project online at a plain web address you choose, and takes it down when you say so. Deploying to your own production is not connected yet — and ForgeOS says so.

  4. 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.

The states you will see on a goal, in the words the product uses for them.

What a goal goes through
StateWhat it means for you
plannedForgeOS has read the project and written the plan. Nothing has been changed.
queuedThe plan is accepted and the work is waiting for a builder.
workingThe work is being done right now, in an isolated copy, on its own branch.
waiting on youForgeOS stopped because it needs a decision or something it does not have.
ready for reviewBuilt, and your repository’s own checks ran and passed. The exact change is in front of you.
acceptedWritten into your project. Whether it was independently reviewed, deployed or released are separate facts with their own receipts — this word does not claim any of them.
doneSaid only when every claim the outcome required was proven, and each proof is on the goal’s record.
stoppedIt did not work, and ForgeOS says why rather than retrying quietly.
cancelledEnded by you, or superseded by a newer ask.

ForgeOS takes no consequential action outside your project on its own authority — and a project it created for you finishes itself unless you turn that off. Writing to your source, deploying and spending beyond your limit each require a decision you grant.

Repository connection & authority

Connect a repository. Grant only what you mean to.

ForgeOS starts read-only. Every further capability is a separate, revocable grant — where a grant is absent, execution stops.

Deploy is its own decision — never implied by permission to write code. The full model is on the Trust page.

The authority model

Your goal → ForgeOS

read repositorygranted at connection — understanding and planning onlygrant
write sourceseparate grant, scoped to branches and paths, revocableseparate
run testsbounded execution, inside the workspacebounded
deploy productionprotected — an explicit decision, every timeprotected
public trafficprotected — separate from production activationprotected
spendbounded by your limits; beyond them, protectedprotected

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.

It can look at a picture, but nothing is stopped by what it sees. A vision model reads screenshots and writes down what it thinks — and that verdict is recorded, not enforced. For anything visual, treat “verified” as “the code is sound”, and look at it yourself before you publish.

The product

The conversation is where all of this lives.

The plan, the work, the proof and the decisions — one thread, owned by you.

A ForgeOS conversation at the decision moment: the goal's thread ends in the exact diff the builder produced in an isolated copy, with Not this, See the evidence and Accept beneath it, and the plan the work followed in the context panel.
A real goal at the decision moment, captured from the product with example data. Nothing is applied until you accept.

Start with one goal.

Connect a repository, describe an outcome, and watch ForgeOS plan it before anything changes.