Introduction

Manifest is a governed ontology platform. It holds an organisation's shared object model — the object types, the actions that may change them, and the links between them — and turns every proposed change, from any surface, into a reviewed, audited mutation.

Three ideas carry the whole platform.

The ontology is governed metadata

Object types, action types, and link types are authored as data in the designer — there is no compiled content assembly. A draft ontology is proposed, reviewed, and published as an immutable version. The API serves the highest published version through a fail-closed registry: the ontology is validated against the platform's rules at startup, and an invalid ontology is a crashed deploy, never a broken runtime. An empty store is a valid day-one state — the platform boots with an empty registry, and the first publish hot-reloads it.

Mutations are proposals

Nothing writes to an object directly. A change enters as an action proposal — from the UI, the REST API, or an AI agent over MCP — and passes through one pipeline: validation, policy decision, guards (duplicate detection, unique-key enforcement), and, where the action type requires it, human review. Only an approved action executes, and execution is the only path that mutates an aggregate. The result is an event in the store: an audit trail that is the system of record, not a log bolted onto it.

Structural impossibility over policy

Where most platforms document what shouldn't be done, Manifest prefers making it unrepresentable. The agent surface holds no schema of its own — its tools are generated from the registry. Platform bindings cannot reach the domain model. A shortcut across a layer fails an architecture test, not a code review.

Where to next

• Getting Started — the designer flow from first object type to first governed action.
• The Ontology — types, versions, and the fail-closed registry in detail.
• Actions & Review — the pipeline every mutation rides.
• REST API — the machine contract.