Inspect the Runtime Contract Behind ODEI

1) Human onboarding preview

Open the app surface, inspect the runtime profile, pricing, activation boundary, and exact intake contract, then retain the returned intake ID if you are invited into the founding cohort lane. The app preview can render a provisioning capsule locally from the same submitted runtime contract.

1. Open https://app.odei.ai
2. Review runtime profile + model access
3. Inspect pricing + plan + auth + entitlement artifacts
4. Inspect activation states + expected outputs
5. Inspect the exact runtime package:
   https://app.odei.ai/runtime-package.json?profile=founder-operator
6. Inspect the exact intake template or preload a sharable preview:
   https://app.odei.ai/?profile=founder-operator&model=Claude&governance=Approval-first
7. If invited, submit intake and store the intake ID
8. If using the app surface, save the locally-rendered provisioning capsule

2) Agent bootstrap

Bind the graph model from public artifacts first, then switch to signed v2 requests for governed query and guardrail validation.

curl -fsS https://api.odei.ai/health
curl -fsS https://api.odei.ai/openapi.json
curl -fsS https://api.odei.ai/api/v2/schema
# then attach Bearer or X-Api-Key for v2 world-model routes

3) Commercial contract

Treat the x402 surface as machine-readable capability metadata. It describes the paid query plane but does not act as an auth grant.

curl -fsS https://api.odei.ai/.well-known/x402.json
# publish capability metadata
# keep payment + auth as separate concerns

Founder operator

Best for inbox triage, investor follow-ups, and weekly operating briefs that already recur every week.

Profile: founder-operator
Model: Claude
Governance: Approval-first
First mission:
Prepare my weekly operating brief and surface follow-ups that matter.

Deal operator

Best for silent thread detection, counterparty timing, and next-touch preparation across email, calendar, and CRM.

Profile: deal-operator
Model: ChatGPT
Governance: Hybrid autonomy
First mission:
Track silent threads and draft the next follow-up with deal context loaded.

Research operator

Best for fixed-perimeter monitoring, World Model updates, and receipt-backed briefs when something materially changes.

Profile: research-operator
Model: Gemini
Governance: Approval-first
First mission:
Watch my research perimeter and issue a brief when the landscape moves.

Team runtime

Best for a small team that needs one shared World Model, approvals, and governed operator lanes before full rollout.

Profile: team-runtime
Model: Bring your own layer
Governance: Team approvals
First mission:
Stand up one shared runtime with the first operating cadence queued.

World Model workspace

The workspace contract makes the first memory boundary explicit so context, people, commitments, and artifacts stop resetting with every session.

Personal runtime:
- one bounded World Model namespace
- one accountable operator lane
- one reopenable provisioning trail

Governance + receipts

The runtime boundary is not just memory. Approvals, execution limits, and outcome receipts stay attached so the operator can inspect why work happened.

Stable boundary:
- governance profile
- receipt surface
- first mission queue
- operator review lane

Portable model layer

The model provider can change later. The workspace contract is what should remain stable when Claude, ChatGPT, Gemini, or another model sits on top.

Replaceable layer:
- model provider
- model access mode
- execution surfaces
- world sources stay governed

Observe → Decide

The loop starts from bounded world sources, then applies priority, timing, and governance before action is queued.

Input boundary:
- world sources
- first mission
- runtime profile
- governance posture

Act → Verify

Execution is governed, then checked against receipts, approval outcomes, and state changes before the loop compounds.

Execution boundary:
- governed action lane
- approval mode
- receipt surface
- verification contract

Evolve

The World Model updates timing, preferences, and context so the next cycle starts from a better operator memory, not from zero.

Continuity boundary:
- same world model
- same governance loop
- same receipt trail
- replaceable model layer

What to bring

Keep the first runtime bounded so activation produces a governed operator instead of a loose assistant spec.

Bring:
- one model provider + access mode
- one governance mode
- three world sources to start
- one or two execution surfaces
- one mission with a real operating cadence

Shareable preview presets

Use query presets to open the same onboarding state in the app for demos, operator reviews, or agent-assisted handoff.

Founder:
https://app.odei.ai/?profile=founder-operator&model=Claude&governance=Approval-first

Deals:
https://app.odei.ai/?profile=deal-operator&model=ChatGPT&governance=Hybrid%20autonomy

Research:
https://app.odei.ai/?profile=research-operator&model=Gemini&governance=Approval-first

What activation returns

The post-submit output contract is already explicit even while public self-serve activation is still closed.

Immediate API response:
- intake_id
- lane
- source
- receivedAt
- consentAt
- summary
- normalized
- activation_package
- launch_checklist
- provisioning_trail.links.provisioningCapsule
- provisioning_trail
- provisioning_trail.links.firstMissionPack
- provisioning_trail.links.activationPackage
- provisioning_trail.links.launchChecklist

App preview:
- provisioning_capsule rendered from submitted runtime contract
- activation_package rendered from the same runtime contract
- launch_checklist rendered from the same runtime contract

Then:
- runtime_scope
- governance_boundary
- tool_map
- first_mission_queue
- receipt_surface

What it fixes

Without a first mission pack, onboarding yields a runtime boundary but not a clear first proof of value.

What it returns

- template label
- resolved first mission
- first delivery
- receipt expectations
- success signal
- loop contract

How to use it

Humans inspect it in the app before submit. Agents pin it as a bootstrap artifact alongside the intake template and provisioning schema.

What it fixes

Without an activation package, readiness can still feel abstract. This artifact makes the first runtime boundary explicit before public self-serve opens.

What it returns

- profile label
- workspace boundary
- governance boundary
- first delivery
- receipt surface
- included entitlements
- activation review sequence
- billing mode

How to use it

Humans inspect it in the app before submit. Agents pin it next to the first mission pack and provisioning schema so the activation boundary stays deterministic.

What it fixes

Without a checklist, reviewed provisioning still feels interpretive. This artifact makes launch readiness operational before self-serve activation opens.

What it returns

- profile label
- review state
- counts by captured / defined / pending_input / pending_review
- checklist items with summary + next step
- explicit operator gate before activation

How to use it

Humans inspect it in the app before submit. Agents pin it next to the activation package and first mission pack so launch readiness stays deterministic.

Ideal first operator

- founder operator
- deal operator
- research operator
- small team preparing one shared runtime

Not for yet

- casual experimentation without a real mission
- public self-serve activation before review
- broad team rollout before one runtime is proven

What to prepare

- one model lane
- three world sources or fewer
- one governance mode
- one execution boundary
- one mission with a real cadence

Activation cadence

Immediate:
- deterministic intake envelope returned immediately

First operator review window:
- runtime scoping
- governance review

After reviewed provisioning:
- activation readiness
- first mission queue
- receipt surface

1) Shareable preview state

The app encodes model lane, governance mode, world sources, execution surfaces, and first mission into a reusable preview URL.

profile + model + governance
world sources + execution surfaces
first mission
= reusable preview URL

2) Exact intake contract

The intake payload is fully visible before submission. Humans can inspect it in the app; agents can POST the same contract directly.

Preview app state
→ inspect exact JSON payload
→ copy or download contract
→ submit to /api/intake

3) Deterministic intake envelope

The API response is intentionally deterministic so downstream tooling can anchor the provisioning trail without ambiguity while still having enough runtime context to continue cleanly.

{
  "ok": true,
  "id": "intake_...",
  "intakeId": "intake_...",
  "lane": "human",
  "source": "app_odei_ai",
  "receivedAt": "2026-03-17T...",
  "consentAt": "2026-03-17T...",
  "summary": {
    "runtimeProfile": "founder-operator",
    "modelProvider": "Claude",
    "governanceMode": "Approval-first"
  },
  "normalized": {
    "workspaceName": "Odei Founder Runtime",
    "operatorScope": "Solo operator"
  },
  "provisioningTrail": {
    "currentState": "intake_received",
    "nextSteps": ["runtime_scoping", "governance_review", "tool_mapping", "first_mission_queue"],
    "links": {
      "intakeStatus": "https://api.odei.ai/api/intake/intake_...",
      "provisioningCapsule": "https://api.odei.ai/api/intake/intake_.../capsule",
      "resumeApp": "https://app.odei.ai/?intake=intake_...",
      "authState": "https://app.odei.ai/auth-state.json",
      "entitlementsState": "https://app.odei.ai/entitlements-state.json",
      "activationState": "https://app.odei.ai/activation-state.json",
      "activationPackage": "https://app.odei.ai/activation-package.json?profile=founder-operator",
      "launchChecklist": "https://app.odei.ai/launch-checklist.json?profile=founder-operator",
      "firstMissionPack": "https://app.odei.ai/first-mission-pack.json?profile=founder-operator",
      "billingContract": "https://app.odei.ai/billing-contract.json"
    }
  },
  "activationPackage": {
    "profileLabel": "Founder operator",
    "workspaceBoundary": "Odei Founder Runtime · Solo operator",
    "governanceBoundary": "Approval-first · Review with me first",
    "firstDelivery": "A governed operating brief with the real next actions already queued.",
    "receiptSurface": "Signals, draft actions, approval requests, and outcome checks attached to the brief."
  },
  "launchChecklist": {
    "profileLabel": "Founder operator",
    "reviewState": "pending_reviewed_provisioning",
    "counts": { "captured": 2, "defined": 5, "pendingInput": 0, "pendingReview": 1 },
    "items": [{ "id": "operator_identity", "state": "captured" }]
  }
}

4) App-rendered provisioning capsule

The app renders the provisioning capsule from the same submitted runtime contract, and GET /api/intake/{intakeId}/capsule keeps the canonical handoff artifact live after submit.

API envelope received
→ app renders provisioning capsule
→ canonical capsule endpoint stays live
→ render launch checklist
→ runtime scoping
→ governance review
→ first mission queue

Status lookup

Use the intake ID returned by POST /api/intake to reopen the current provisioning state from the live API boundary.

GET /api/intake/{intakeId}

{
  "ok": true,
  "intakeId": "intake_...",
  "lane": "human",
  "source": "app_odei_ai",
  "receivedAt": "2026-03-18T...",
  "consentAt": "2026-03-18T...",
  "summary": { ... },
  "normalized": { ... },
  "provisioningTrail": {
    "currentState": "intake_received",
    "nextSteps": ["runtime_scoping", "governance_review", "tool_mapping", "first_mission_queue"],
    "links": {
      "intakeStatus": "https://api.odei.ai/api/intake/intake_...",
      "provisioningCapsule": "https://api.odei.ai/api/intake/intake_.../capsule",
      "resumeApp": "https://app.odei.ai/?intake=intake_...",
      "authState": "https://app.odei.ai/auth-state.json",
      "entitlementsState": "https://app.odei.ai/entitlements-state.json",
      "activationState": "https://app.odei.ai/activation-state.json",
      "activationPackage": "https://app.odei.ai/activation-package.json?profile=founder-operator",
      "launchChecklist": "https://app.odei.ai/launch-checklist.json?profile=founder-operator",
      "firstMissionPack": "https://app.odei.ai/first-mission-pack.json?profile=founder-operator",
      "billingContract": "https://app.odei.ai/billing-contract.json"
    }
  },
  "activationPackage": { ... },
  "launchChecklist": { ... },
  "activation": {
    "reviewState": "pending_founder_cohort_review",
    "activationState": "intake_received",
    "publicLaunch": "not_yet_public",
    "selfServeActivation": "closed"
  },
  "readiness": {
    "auth": {
      "state": "operator_identity_captured",
      "next": "verify operator details",
      "note": "Runtime credentials are issued only after reviewed provisioning."
    },
    "entitlements": {
      "state": "preview_only_until_activation",
      "next": "grant founding cohort runtime entitlements",
      "note": "Workspace, governance, and receipt surface activate after review."
    },
    "billing": {
      "state": "billing_readiness_captured",
      "next": "review setup scope and runtime plan",
      "note": "Public self-serve checkout remains closed until launch."
    },
    "activation": {
      "state": "pending_reviewed_provisioning",
      "next": "runtime scoping -> governance review -> first mission queue",
      "note": "Self-serve activation remains closed until reviewed provisioning completes."
    }
  }
}

App resume path

The same intake ID can reopen the provisioning capsule directly in app.odei.ai without resubmitting the contract.

https://app.odei.ai/?intake=intake_...

Resume flow:
intake ID
→ GET /api/intake/{intakeId}
→ GET /api/intake/{intakeId}/capsule
→ render provisioning capsule
→ render activation package
→ render launch checklist
→ render readiness states
→ continue runtime scoping

The resume payload now carries explicit readiness lanes for auth, entitlements, billing, and activation so humans and agents can reopen the exact same business boundary.

What is live now

- app preview
- bootstrap, pricing, provisioning, and activation artifacts
- founding-cohort intake
- deterministic intake envelope

What is intentionally closed

- public self-serve activation
- public billing checkout
- one-click runtime launch from Agent Builder

Canonical read path

Pin the machine-readable launch state together with bootstrap, pricing, and activation artifacts so operators, builders, and agents all reason from the same commercial boundary.

Founder operator preset

Use this when the first runtime should manage inbox triage, operating briefs, and priority follow-ups.

Preview:
https://app.odei.ai/?profile=founder-operator&model=Claude&governance=Approval-first

curl -X POST https://api.odei.ai/api/intake \
  -H "Content-Type: application/json" \
  -d '{
    "lane": "human",
    "consent": true,
    "name": "Founder",
    "agentName": "Maya",
    "role": "Founder",
    "workspaceName": "Odei Founder Runtime",
    "operatorScope": "Solo operator",
    "telegram": "odei_ai",
    "modelProvider": "Claude",
    "modelAccess": "Bring my API key",
    "governanceMode": "Approval-first",
    "runtimeProfile": "founder-operator",
    "activationPreference": "Review with me first",
    "billingReadiness": "Invoice me for founding cohort setup",
    "worldSources": ["Email", "Calendar", "Documents"],
    "executionSurfaces": ["Draft + send", "Internal reports"],
    "firstMission": "Prepare my weekly operating brief",
    "useCase": "Prepare my weekly operating brief from email, calendar, and documents while keeping follow-ups governed."
  }'

Deal operator preset

Use this when the first runtime should track conversations, silent threads, and governed investor or client follow-ups.

Preview:
https://app.odei.ai/?profile=deal-operator&model=ChatGPT&governance=Hybrid%20autonomy

curl -X POST https://api.odei.ai/api/intake \
  -H "Content-Type: application/json" \
  -d '{
    "lane": "human",
    "consent": true,
    "name": "Operator",
    "agentName": "Atlas",
    "role": "Deal operator",
    "workspaceName": "Investor Runtime",
    "operatorScope": "Solo operator",
    "telegram": "odei_ai",
    "modelProvider": "ChatGPT",
    "modelAccess": "Use ODEI credits",
    "governanceMode": "Hybrid autonomy",
    "runtimeProfile": "deal-operator",
    "activationPreference": "Queue when ready",
    "billingReadiness": "Use self-serve billing when live",
    "worldSources": ["Email", "Calendar", "CRM"],
    "executionSurfaces": ["Draft + send", "CRM updates"],
    "firstMission": "Track silent investor threads and draft the next follow-up",
    "useCase": "Track silent investor threads, preserve deal context, and draft the next governed follow-up."
  }'

Immediate response envelope

The direct API response is deterministic and provisioning-ready. The app preview renders the provisioning capsule after this envelope lands, but the API already returns the boundary humans and agents need.

{
  "ok": true,
  "id": "intake_...",
  "intakeId": "intake_...",
  "lane": "human",
  "source": "app_odei_ai",
  "receivedAt": "2026-03-17T...",
  "consentAt": "2026-03-17T...",
  "summary": {
    "runtimeProfile": "founder-operator",
    "modelProvider": "Claude",
    "governanceMode": "Approval-first"
  },
  "normalized": {
    "workspaceName": "Odei Founder Runtime",
    "operatorScope": "Solo operator"
  },
  "provisioningTrail": {
    "currentState": "intake_received",
    "nextSteps": ["runtime_scoping", "governance_review", "tool_mapping", "first_mission_queue"],
    "links": {
      "intakeStatus": "https://api.odei.ai/api/intake/intake_...",
      "resumeApp": "https://app.odei.ai/?intake=intake_...",
      "authState": "https://app.odei.ai/auth-state.json",
      "entitlementsState": "https://app.odei.ai/entitlements-state.json",
      "activationState": "https://app.odei.ai/activation-state.json",
      "billingContract": "https://app.odei.ai/billing-contract.json"
    }
  },
  "readiness": {
    "auth": { "state": "operator_identity_captured", "next": "verify operator details", "note": "Runtime credentials are issued only after reviewed provisioning." },
    "entitlements": { "state": "preview_only_until_activation", "next": "grant founding cohort runtime entitlements", "note": "Workspace, governance, and receipt surface activate after review." },
    "billing": { "state": "billing_readiness_captured", "next": "review setup scope and runtime plan", "note": "Public self-serve checkout remains closed until launch." },
    "activation": { "state": "pending_reviewed_provisioning", "next": "runtime scoping -> governance review -> first mission queue", "note": "Self-serve activation remains closed until reviewed provisioning completes." }
  }
}

Lifecycle states

Use these states to reason about the business and technical boundary after intake.

preview
→ intake_received
→ runtime_scoping
→ governance_review
→ activation_ready

What the user receives

Every successful cohort submit has explicit outputs instead of ambiguous “we will contact you” behavior. The API response and the app-rendered capsule are separate but aligned artifacts.

Immediate API response: intake_id, lane, source, receivedAt, consentAt, summary, normalized, provisioning_trail
App preview: provisioning_capsule rendered from submitted runtime contract
Operator review: runtime_scope, governance_boundary, tool_map
Activation: agent_runtime, first_mission_queue, receipt_surface

Artifacts

Keep the activation artifact pinned with bootstrap, pricing, the billing contract, provisioning, and the intake template so humans and agents read the same business contract.

Current auth state

Read this as the current commercial boundary for humans and agents that want to bootstrap against ODEI.

preview = public
founding_cohort_intake = open
public_signup = closed
public_billing_checkout = closed
self_serve_activation = closed

Plan shapes

Commercial shape is already fixed even before pricing amounts are public. The app exposes the plan geometry separately from the launch state, and the billing contract fixes the reviewed boundary before self-serve opens.

Personal Runtime
→ setup
→ monthly runtime
→ metered execution

Team Runtime
→ custom setup
→ team runtime
→ metered execution

Artifacts

Pin auth, plans, entitlements, activation, pricing, the billing contract, and the intake template together so every actor reads the same provisioning boundary.

Capsule role

Use the capsule as the handoff artifact between human onboarding, runtime scoping, and downstream agent/bootstrap tooling. It is generated by the app surface after the intake response lands.

{
  "artifact": "odei.agent.provisioning-capsule",
  "version": "2026-03-17",
  "intake": {
    "intakeId": "intake_...",
    "status": "intake_received"
  },
  "runtime": {
    "modelProvider": "Claude",
    "runtimeProfile": "founder-operator",
    "worldSources": ["Email", "Calendar", "Documents"]
  }
}

Boundary rule

The provisioning capsule is a handoff contract, not an auth grant and not proof that runtime activation is complete.

Human onboarding submit
→ intake ID returned
→ provisioning capsule generated
→ runtime scoping + governance review
→ first mission queue

Artifacts

Keep bootstrap, pricing, the billing contract, provisioning schema, and the intake template pinned together so humans and agents read the same onboarding boundary.

1) Runtime Smoke

Verify server liveness and public contract endpoint.

curl -fsS https://api.odei.ai/health
curl -fsS https://api.odei.ai/openapi.json

2) Intake Registration

Submit consented lane onboarding payload and capture intake ID.

curl -X POST https://api.odei.ai/api/intake \
  -H "Content-Type: application/json" \
  -d '{"lane":"human","consent":true,"name":"Operator","role":"PM","telegram":"odei_ops","useCase":"Daily planning with graph context"}'

3) V2 Query/Auth

Execute authenticated graph query on v2 lane.

curl -X POST https://api.odei.ai/api/v2/world-model/query \
  -H "Authorization: Bearer <jwt>" \
  -H "Content-Type: application/json" \
  -d '{"search":"guardrail","limit":5}'