Trust

ForgeOS acts only inside authority you granted, and it records what it did.

This page describes controls the software actually enforces. Where something is a commitment rather than an enforced control, or has not been published yet, it says so.

The authority model

Every consequential capability is a separate grant.

Permission to read is not permission to write. Permission to write is not permission to deploy. Each is granted on its own and can be withdrawn on its own, from Trust & control in Mission Control.

The authority map

Each branch is a separate, withdrawable grant. A missing grant stops execution; it is never assumed.

Your goal → ForgeOS

read repositorystructure, history and dependencies, so ForgeOS can plan against what is really there. This is where every connection starts.grant

write sourcea separate grant, scoped to a branch and to paths. Work outside the scope it was given does not run.separate

run testsbounded execution inside the workspace, never on your production systems.bounded

deploy previewits own grant, distinct from production.separate

deploy productionprotected. Releasing is never implied by permission to write code.protected

public trafficprotected, and separate from production activation.protected

customer dataoff unless you turn it on. Connecting a repository does not grant it.protected

spendno model provider runs work until you choose one and set a limit. Work stops at the limit rather than passing it.protected

payments & legalprotected actions. Not exercisable by the system on its own authority.protected

anything not grantedthe branch simply ends. Execution stops at the boundary; it is never assumed across it.

grantgiven at connection separateits own grant, scoped, revocable boundedruns only inside stated limits protectedan explicit decision, every time not granted — stops

Revoking a grant stops future work that depended on it rather than silently downgrading. What each grant is scoped to — branches, paths, environments, limits — is recorded with the grant and shown in Trust & control.

What happens at the edge

When ForgeOS lacks authority or evidence, it stops.

This is the behaviour that makes the rest of the page meaningful. A system that guesses when it is unsure cannot honestly promise anything about what it will not do.

It stops and asks
A goal that needs a decision moves to a stopped state and waits. It does not proceed on assumption and does not retry quietly.
Review is not optional
Finished work sits in review until a person accepts or rejects it, and the person who reviews cannot be the agent that built it.
Scope is enforced, not requested
Two pieces of work cannot claim overlapping paths in the same repository at the same time.

Evidence

The record of what happened is append-only and verifiable.

Every state change, approval, rejection and failure is written to a chain in which each entry carries a hash of the one before it. Editing history breaks the chain, and the check that detects it is the one reported on the status page.

Attributed decisions

An approval records who made it and what they were shown at the time, taken from what the interface actually rendered.

Readable history

The history of a goal is shown in Mission Control in plain language, alongside the raw recorded entries.

event 41 · submitted_for_review · sha256:9f2c…

event 42 · approved · by owner@acme · sha256:e07a… ⟵ hashes event 41

event 43 · released · sha256:b511… ⟵ hashes event 42

editing any entry breaks every hash after it

What evidence is not. When an agent submits finished work, its report of what it did is the agent's claim, not an independent verification. ForgeOS shows it as a claim. Check results come from runners, and where no runner is connected, no check is reported as passing — see status for what is connected here.

Your data

Tenant boundaries, and no customer data access by default.

Not pooled

Your repositories, goals, evidence and history belong to your tenant and are not shared across customers.

Customer data is its own grant

Access to customer data is not granted by connecting a repository. It is off unless you turn it on.

Providers are yours to choose

Which model providers may run work is a setting, per instance and per repository.

Withdrawable

Any grant can be revoked. Revoking stops future work that depended on it rather than silently downgrading.

Privacy and terms

Both documents exist as drafts. Neither is in force.

The privacy policy and terms of service are published as working drafts so you can see what we intend to commit to before we commit to it. No lawyer has reviewed either. They bind nobody, and using ForgeOS today does not put you under them — early access is arranged in writing with us directly, and that arrangement is what governs.

What that means for a review. Do not rely on either draft for a procurement decision, a security review or a regulatory assessment. The controls described above are what the software actually enforces today, and you can read them in the product at Trust & control. For the data-processing detail, ask us and you will get an answer from a person rather than a document that has not been read by one.

Limits

What we do not claim.

No certification
ForgeOS does not certify your compliance with any standard, and holds no audit report it can show you.
No promise of correctness
Review exists because generated software can be wrong. ForgeOS tells you what was verified and by what, not that the result is correct.
No uptime guarantee
There is no published availability commitment, because none has been measured over a meaningful period.
No hidden autonomy
If ForgeOS could take a consequential action without asking, that would be listed here as a capability. It is not, because it cannot.

Have a question this page did not answer?

Security reviews, procurement questionnaires and data questions all go to the same place.