Build governed missions,
not chatbots.
MasterEngine is a governed business-mission execution platform. This hub documents how missions are specified, authorized, executed, and verified — with the execution chain, a mission-spec format, and copy-paste recipes you can adapt to your own deployment.
Your first governed mission in 5 minutes
A conceptual walkthrough of the MasterEngine execution chain. No SDK is required for this walkthrough — it maps the exact stages every mission passes through, so you know what a governed mission is before you ever run one.
Minute 1 — Write the contract
Define what the mission must achieve and what success looks like, up front. The contract is the mission's promise: scope, expected value, acceptable cost, and risk bounds. Everything downstream is measured against it.
Minute 2 — Set the tenant boundary
Bind the mission to exactly one tenant. Tenant isolation is enforced by PostgreSQL forced row-level security, so data can never leak across organizations, workspaces, or environments.
Minute 3 — Attach a verified identity
Every mission executes as a verified identity — never as an anonymous agent. Identity determines which authorizations can even be requested.
Minute 4 — Authorize with deterministic policy
A deterministic policy engine decides what the mission is allowed to do. Models propose actions; models never decide authorizations. The policy decision is reproducible: same inputs, same verdict, every time.
Minute 5 — Execute and verify
Authorized actions run as governed Action transactions inside a durable workflow (Temporal). Connectors or models perform the work, and every step lands on the evidence timeline — expected vs. actual value, cost, and risk.
You now understand a governed mission
Contract → tenant boundary → verified identity → deterministic authorization → governed execution → evidence. Ready for the full picture? Read the execution-chain docs or grab a copy-paste recipe.
Every mission walks the same eight stages
This chain is the platform's core guarantee. Skipping a stage isn't possible — a mission that can't clear authorization never reaches execution, and a mission with no evidence never counts as done.
- Contracts
The mission declares its goal, success criteria, and bounds on value, cost, and risk.
- Tenant boundary
The mission is pinned to one tenant. PostgreSQL forced row-level security enforces isolation across organization, workspace, and environment.
- Verified identity
The mission executes as an authenticated, verified identity — the basis for everything authorization can grant.
- Deterministic policy and authorization
A policy engine — not a model — decides what is allowed. Same inputs always produce the same verdict.
- Governed Action transaction
Each authorized action executes as a transaction: atomic, audited, and bounded by the contract.
- Durable workflow
Workflows run on Temporal: they survive restarts, retries are explicit, and long-running missions can't silently die.
- Connector or model execution
Connectors reach your systems; models do the cognitive work. Both operate strictly inside what policy authorized.
- Evidence and outcome
Every step is recorded on the evidence timeline, comparing expected vs. actual value, cost, and risk.
Models are kept out of the authorization path. They propose, they execute, they summarize — but the decision to allow an action is made by deterministic policy. That separation is what makes a mission governed instead of merely automated.
Three ways into the hub
📖 Docs
The execution chain in depth, the platform architecture, and the v1 mission-spec format (draft).
🧪 Recipes
Copy-paste mission-spec recipes for common business missions — each clearly marked illustrative.
🗒 Changelog
What's new in the developer preview, and the public roadmap for these docs and the platform.