The execution chain, in depth

MasterEngine is a governed business-mission execution platform. A mission is a unit of business work — "follow up on every open quote this week," "reconcile yesterday's invoices" — that the platform plans, authorizes, executes, and verifies. Every mission passes through eight stages, in order.

1. Contracts

   Before anything runs, the mission states a contract: the goal, the definition of done, and bounds on value, cost, and risk. The contract is the yardstick the mission is judged against at the end — expected vs. actual.

2. Tenant boundary

   The mission is bound to exactly one tenant. Isolation is enforced by PostgreSQL forced row-level security across organization, workspace, and environment — a mission cannot read, write, or even see another tenant's data, no matter what a model inside it suggests.

3. Verified identity

   The mission executes as a verified identity. Authorization is identity-relative: what a mission may do depends on who (or which service) is verifiably running it.

4. Deterministic policy and authorization

   A deterministic policy engine decides whether each proposed action is allowed. Deterministic means reproducible: the same inputs always yield the same verdict. Models propose actions; models never grant them.

5. Governed Action transaction

   Authorized actions execute as transactions — atomic, bounded by the contract, and individually auditable. If an action would exceed its bounds, the transaction doesn't proceed.

6. Durable workflow

   Missions run as durable workflows on Temporal. Long-running work survives restarts and infrastructure hiccups; retries are explicit policy, not silent hope; a mission can never quietly die mid-flight.

7. Connector or model execution

   Connectors touch your systems (databases, APIs, tools); models do the cognitive work (planning, drafting, summarizing). Both operate strictly inside the authorizations granted in stage 4.

8. Evidence and outcome

   Every stage lands on the evidence timeline: what was proposed, what was authorized, what ran, what it cost, and the outcome — compared against the contract from stage 1. A mission with no evidence doesn't count as complete.

Architecture principles

The mission-spec format

A mission spec is the declarative document that describes one mission: its contract, its boundaries, and its authorized actions. The format below is a v1 draft — it will evolve as the platform ships, and every change will be recorded in the changelog.

Fields

Illustrative example

The example below is illustrative only — it shows the shape of a mission spec, not a schema you can submit anywhere today.

{
  "name": "weekly-pipeline-followup",
  "version": "1.0-draft",
  "tenant": {
    "organization": "example-org",
    "workspace": "sales",
    "environment": "production"
  },
  "contract": {
    "goal": "Follow up on every open quote older than 7 days",
    "definition_of_done": "Each open quote has a logged follow-up touch",
    "max_cost_usd": 25,
    "risk_bounds": ["no external sends without approval"]
  },
  "identity": { "type": "service", "id": "missions/sales-followup" },
  "policy": { "rule_set": "sales-standard-v1" },
  "actions": [
    { "kind": "read", "target": "quotes.open_older_than_7d" },
    { "kind": "draft", "target": "followup_message", "requires_approval": true },
    { "kind": "record", "target": "crm.followup_touch" }
  ],
  "evidence": {
    "record": ["quotes_touched", "messages_drafted", "actual_cost_usd"],
    "compare": "expected_vs_actual"
  }
}

Want more worked examples? The recipe library adapts this format to common business missions — each recipe clearly marked illustrative.