Creasura Agentic OS Protocol (CAOP) v0.1.2

1. Overview

For Creasura One OSS, an Agentic Operating System (Agentic OS) is:

A persistent, event-driven system that coordinates intelligent agents, tools, knowledge, and human decisions to achieve goals over time, while maintaining durable state, enforcing policies, verifying outcomes, and recovering from failures.

An agentic OS is not simply an agent, an agent framework, or an LLM with tools. It is the system responsible for managing the lifecycle of work performed by agents.

An agentic OS doesn’t need to implement its own LLM, browser, coding agent, or research engine. Those are execution capabilities. The OS manages how those capabilities are invoked, coordinated, supervised, and remembered. ChatGPT, Claude, and other providers can supply execution capabilities while Creasura provides a consistent operating model.

2. The five fundamental abstractions

Start with five abstractions rather than a large collection of specialized agents.

2.1 Goal

A desired outcome that persists beyond a single conversation, for example: reduce monthly household expenses, complete a software architecture proposal, plan a family vacation, launch a business. A goal has an owner, success criteria, constraints, and a lifecycle.

interface Goal {
  id: string;
  objective: string;
  owner: PrincipalRef;
  successCriteria: Criterion[];
  constraints: Constraint[];
  status: "active" | "paused" | "achieved" | "abandoned";
  createdAt: string;
  updatedAt: string;
}

2.2 Work

A bounded unit of execution that advances a goal. A goal may contain multiple work items. Work has dependencies, execution state, deadlines, and evidence of completion.

Goal: Plan family vacation
  |
  +-- Compare destinations
  +-- Find flights
  +-- Compare hotels
  +-- Review budget
  +-- Book approved itinerary

interface WorkItem {
  id: string;
  goalId: string;
  description: string;
  dependencies: string[];
  status: "pending" | "ready" | "running" | "blocked" | "completed" | "failed" | "cancelled";
  assignedCapability?: string;
  result?: ArtifactRef;
  deadline?: string;
}

2.3 State

The durable representation of what the OS knows: facts, goals, commitments, decisions, relationships, policies, execution history, and evidence. State is not equivalent to conversational memory.

interface Fact {
  id: string;
  subject: EntityRef;
  predicate: string;
  object: unknown;
  source: EvidenceRef;
  observedAt: string;
  validFrom?: string;
  validTo?: string;
  confidence?: number;
}

2.4 Capability

Something the OS can invoke to perform work: an AI assistant, a coding agent, email, calendar, GitHub, web research, a deterministic rules engine, or a human approval workflow.

interface Capability {
  id: string;
  operations: string[];
  inputSchema: object;
  outputSchema: object;
  authorization: AuthorizationPolicy;
  executionMode: "interactive" | "background" | "scheduled";
  provider: string;
}

A capability contract should describe what an operation can do, not merely what an agent is instructed to attempt.

2.5 Policy

An enforceable constraint governing execution. Examples: never send an external email without authorization; never spend money without approval; never expose employer-confidential information to a personal workspace; never mark work complete without supporting evidence.

interface Policy {
  id: string;
  scope: string;
  condition: Expression;
  effect: "allow" | "deny" | "require_approval";
  version: string;
}

3. The lifecycle

A canonical lifecycle with eight stages:

1. Observe
2. Understand
3. Commit
4. Plan
5. Execute
6. Verify
7. Record
8. Review
9. ↺ back to Observe

These are logical lifecycle stages, not a requirement that every request execute eight sequential LLM calls. A deterministic operation might bypass planning entirely. A failed verification might return work to planning. A blocked task might wait for an external event for several days.

4. Lifecycle API

The protocol has three interfaces: the Lifecycle API (how work progresses), the Capability API (how external executors perform work), and the State API (how knowledge, decisions, and outcomes persist).

These operations represent logical responsibilities. Implementations can combine them internally.

4.1 Observe

An observation represents something the OS has learned from an external source.

POST /v1/observations
{
  "source": { "provider": "gmail", "resource_id": "message_123" },
  "type": "message.received",
  "occurred_at": "2026-11-01T14:00:00Z",
  "payload_ref": "artifact_456",
  "idempotency_key": "gmail-message-123"
}

// Response
{ "observation_id": "obs_123", "status": "accepted", "duplicate": false }

4.2 Understand

The OS resolves the observation against known state.

POST /v1/context/resolve
{
  "observation_ids": ["obs_123"],
  "scope": { "workspace_id": "personal", "project_ids": ["mortgage-refinance"] },
  "include": ["related_goals", "open_commitments", "relevant_policies", "prior_decisions"]
}

// Response
{
  "context_id": "ctx_123",
  "state_version": 42,
  "related_goals": ["goal_refinance"],
  "open_commitments": ["commitment_12"],
  "applicable_policies": ["policy_financial_approval"],
  "unresolved_questions": []
}

This operation should distinguish retrieved facts from inferred interpretations.

4.3 Commit

Create a durable obligation or objective.

POST /v1/commitments
{
  "goal_id": "goal_refinance",
  "objective": "Evaluate updated refinancing offer",
  "success_criteria": [
    { "type": "artifact_exists", "artifact_type": "refinancing_comparison" }
  ],
  "deadline": "2026-11-05T23:59:00Z"
}

// Response
{ "commitment_id": "com_123", "status": "open", "version": 1 }

4.4 Plan

POST /v1/plans
{
  "commitment_id": "com_123",
  "constraints": { "require_approval_for_external_actions": true },
  "preferred_capabilities": ["document_analysis", "calculator", "research"]
}

// Response
{
  "plan_id": "plan_123",
  "steps": [
    { "id": "step_1", "capability": "document_analysis", "depends_on": [] },
    { "id": "step_2", "capability": "calculator", "depends_on": ["step_1"] },
    { "id": "step_3", "capability": "report_generation", "depends_on": ["step_2"] }
  ]
}

The planner may use an LLM. The runtime must still validate the generated plan against schemas, dependencies, and policy constraints.

4.5 Execute

POST /v1/executions
{
  "plan_id": "plan_123",
  "idempotency_key": "execute-plan-123-v1",
  "authorization_context": { "principal_id": "user_123" }
}

// Response
{ "execution_id": "exec_123", "status": "queued", "next_action": "await_execution" }

Execution is asynchronous. An accepted request does not mean the work has completed.

4.6 Verify

POST /v1/verifications
{
  "execution_id": "exec_123",
  "criteria": ["all_required_steps_completed", "result_has_supporting_evidence", "no_policy_violations"]
}

// Response
{ "verification_id": "verify_123", "verdict": "passed", "evidence_refs": ["artifact_789"] }

Verification can include deterministic checks, human approval, or model-based evaluation. The verdict must identify which checks were performed.

4.7 Record

POST /v1/records/commit
{
  "execution_id": "exec_123",
  "verification_id": "verify_123",
  "expected_state_version": 42,
  "changes": [ { "entity_id": "com_123", "operation": "set_status", "value": "completed" } ]
}

// Response
{ "transaction_id": "txn_123", "state_version": 43, "status": "committed" }

4.8 Review

POST /v1/reviews
{
  "goal_id": "goal_refinance",
  "review_type": "progress",
  "include": ["outcomes", "unresolved_commitments", "failures", "next_actions"]
}

// Response
{
  "review_id": "review_123",
  "goal_status": "active",
  "recommended_actions": [ { "action": "request_final_offer", "requires_approval": true } ]
}

Review recommendations are proposals, not automatically authorized actions.

5. Execution state machine

The eight lifecycle stages should not be confused with execution states.

CREATED
   |
   v
READY
   |
   v
RUNNING ---------> WAITING_APPROVAL
   |                     |
   |                     v
   |                   RUNNING
   |
   +------------------> BLOCKED
   |                     |
   |                     v
   |                   READY
   |
   v
VERIFYING
   |
   +------> FAILED
   |          |
   |          v
   |        READY (retry)
   |
   v
COMPLETED

Terminal states: COMPLETED, CANCELLED, EXPIRED

The API must reject invalid transitions.

POST /v1/executions/exec_123/transitions
{
  "expected_state": "VERIFYING",
  "target_state": "COMPLETED",
  "verification_id": "verify_123"
}

A transition from CREATED directly to COMPLETED should be rejected unless the work type explicitly supports that shortcut. The runtime persists each accepted transition with an actor, timestamp, reason, and correlation ID.

Try the state machine interactively ›

v0.1.2EXECUTE is refined into sub-states that map onto these execution states. See §14.5.1 and §14.8.

6. Capability API

The boundary between the OS and the assistants and services that do the work. The OS must not assume every provider supports the same features.

interface CapabilityDescriptor {
  id: string;
  provider: string;
  operations: string[];
  inputSchema: object;
  outputSchema: object;
  supportsAsync: boolean;
  supportsResume: boolean;
  supportsCancellation: boolean;
  authorizationRequired: boolean;
  sideEffectLevel: "none" | "reversible" | "irreversible";
}

interface CapabilityInvocation {
  invocationId: string;
  capabilityId: string;
  input: unknown;
  contextRefs: string[];
  authorizationRef?: string;
  idempotencyKey: string;
}

interface CapabilityResult {
  invocationId: string;
  status: "completed" | "failed" | "pending" | "requires_approval";
  output?: unknown;
  evidenceRefs: string[];
  error?: { code: string; message: string; retryable: boolean };
}

This makes the OS independent of a particular execution provider. A capability might be implemented through an AI assistant, a coding agent, an MCP tool, a deterministic function, or another provider.

v0.1.2Capabilities also declare execution locus, credential custody, receipt lease, required receipt fields and promotion policy. See §14.4.

6.1 Native assistant mapping

What a native ChatGPT setup can provide on its own, and what it guarantees:

7. Cross-cutting contracts

These matter more than adding dozens of specialized endpoints.

7.1 Error format

{
  "error": {
    "code": "POLICY_APPROVAL_REQUIRED",
    "message": "External action requires approval",
    "retryable": false,
    "details": { "approval_request_id": "approval_123" }
  },
  "trace_id": "trace_456"
}

8. Events

An agentic OS is event-driven rather than assuming every workflow starts with a user prompt.

{
  "event_id": "evt_123",
  "event_type": "commitment.deadline_approaching",
  "schema_version": "1.0",
  "occurred_at": "2026-11-01T14:00:00Z",
  "workspace_id": "personal",
  "subject_id": "com_123",
  "correlation_id": "goal_refinance",
  "causation_id": "evt_100",
  "payload": { "hours_remaining": 24 }
}

The event transport can start simple. For a single-user deployment of Creasura One OSS v0.1, an SQLite-backed event table and a scheduled processor are sufficient. No distributed broker is required.

9. Conformance levels

An assistant configured with projects and instructions can provide L1 immediately. L2 needs a persistent store outside conversational memory. L3 needs a lightweight execution controller that responds to events and enforces lifecycle transitions, delegating AI work to existing providers.

v0.1.2Runtime conformance profiles CAOP-STAGE-1/2/3 map onto these levels. See §14.1 and §14.8.

10. Minimum public API

Don’t expose all eight lifecycle stages as mandatory public tools. Expose a small set of outcome-oriented operations, mapped internally to the richer lifecycle API:

Assistants see a manageable set of tools with clear purposes, and the internal OS can evolve without forcing changes to every integration.

v0.1.2A four-tool compact binding is defined as an alternative public surface; these ten tools remain conformant. See §14.6.

11. Reference architecture

                    USER
                     |
                     v
              +-------------+
              | AI assistant|
              | (ChatGPT,   |
              |  Claude...) |
              +------+------+
                     |  MCP
                     v
          +----------------------+
          | CREASURA OS PROTOCOL |
          | Goals & Commitments  |
          | State & Context      |
          | Plans & Executions   |
          | Policies & Approvals |
          | Verification         |
          +----------+-----------+
                     |
          +----------+----------+
          v                     v
   +-------------+       +-------------+
   | State Store |       | Event Loop  |
   | SQLite      |       | Scheduler   |
   +-------------+       +------+------+
                                |
                                v
                         +-------------+
                         | Capability  |
                         | Adapters    |
                         +------+------+
                                |
                 +--------------+--------------+
                 v              v              v
            Assistants    Coding agents    External services

12. Business Profile (CAOP-Biz)

An optional profile that scales the same kernel from a single-user personal OS to a business operating system, without changing the eight lifecycle stages or the public operations.

12.1 Metric trees and variance triggers

interface MetricNode {
  id: string;                 // e.g. "metric.net_contribution_margin"
  name: string;
  formula?: string;           // deterministic relation to child metrics
  parentMetricId?: string;
  childMetricIds: string[];
  owner: PrincipalRef;
  baselineCadence: "hourly" | "daily" | "weekly" | "monthly";
  varianceThresholds: {
    warningDeltaPct: number;  // e.g. -3.0% triggers Understand
    criticalDeltaPct: number; // e.g. -7.5% triggers Commitment
  };
}

On metric.variance_detected, context.resolve traverses the childMetricIds graph to isolate the driver before any commitment or plan is proposed.

12.2 Delegation of Authority

• Tier 1, autonomous: exposure under $1,000 and margin above threshold → allow under the agent’s service principal.
• Tier 2, single approver: $1,000–$25,000 → require_approval routed to a role, with an SLA escalation timer.
• Tier 3, quorum: over $25,000 or modifies a locked constraint → multi-party sign-off before WAITING_APPROVAL can move to RUNNING.

interface ApprovalRoutingRule {
  policyId: string;
  requiredRoles: string[];
  minQuorum: number;
  expirationSeconds: number;
  escalateToRoleOnTimeout?: string;
}

12.3 Bitemporal state

• Valid time (validFrom → validTo): the business period the fact describes.
• System time (observedAt → supersededAt): when the OS believed the fact to be true.
• Invariant: context.resolve accepts asOfSystemTime and asOfValidTime, separating decision quality from data latency.

12.4 Two-phase verification

POST /v1/commitments
{
  "goal_id": "goal_q4_efficiency",
  "objective": "Reallocate underperforming campaign spend to high-margin SKUs",
  "success_criteria": [
    { "phase": "immediate_verification", "type": "constraint_check",
      "rule": "total_daily_spend <= 10000 AND min_sku_roas >= 2.8" },
    { "phase": "outcome_realization", "evaluation_window_hours": 168,
      "type": "counterfactual_lift", "metric_id": "metric.net_contribution_margin",
      "expected_delta_pct": 4.5 }
  ]
}

Immediate criteria are evaluated at Verify. When Record commits, the outbox schedules commitment.outcome_window_elapsed; when it fires, Review compares realized metrics with the dry-run projection and writes a value-realization verdict.

12.5 Capability tiers

13. Machine-readable contracts

CAOP v0.1 is published in two machine-readable forms generated from the same definitions:

• OpenAPI 3.1 contract: every lifecycle operation, request, response, and error, with the MCP tool each one backs. YAML · JSON
• JSON Schema 2020-12: every object in this specification, in one bundle. caop-v0.1.schema.json

• CAOP v0.1.2 extends both forms additively (conformance profiles, causal state, pre-commit hooks, host execution enforcement, and the compact four-tool binding): OpenAPI YAML · OpenAPI JSON · caop-v0.1.2.schema.json. The v0.1 files above stay published at their versioned URLs.

14. v0.1.2: conformance stages, causal state and host enforcement

CAOP v0.1.2 Specification: Conformance Stages, Causal State, and Host Enforcement

The consolidated Creasura Agentic Operating Protocol (CAOP v0.1.2) specification below integrates the three runtime conformance stages, the bitemporal causal dependency graph, epistemic hygiene gates, deterministic pre-commit hooks, host execution enforcement, and the 8-to-4 MCP tool bindings into a single master document.

14.1 Runtime Conformance Stages (Normative Profiles)

CAOP v0.1.2 defines three progressive runtime conformance profiles. Advancing a workspace or individual capability from Stage 1 to Stage 3 requires zero breaking changes to Goal definitions, the eight-stage Work lifecycle (OBSERVE → UNDERSTAND → COMMIT → PLAN → EXECUTE → VERIFY → RECORD → REVIEW), or bitemporal State queries.

• CAOP-STAGE-1 (Host-Delegated Ledger): External conversational hosts (ChatGPT (Actions or MCP apps), Claude (MCP)g) initiate turns and execute downstream side effects using their native connectors while Creasura enforces lifecycle order, policy gates, lease locks, and causal state recording.
• CAOP-STAGE-2 (Kernel-Proxied Execution): The host client drives conversational turns, but downstream OAuth tokens live in the Creasura Vault so the kernel invokes external providers directly over TLS during EXECUTE.
• CAOP-STAGE-3 (Autonomous Kernel Runtime): The Creasura kernel owns the event-driven trigger loop (webhooks and durable schedules) and runs headless reasoning turns through OBSERVE → PLAN → EXECUTE, using chat clients as supervisor and approval surfaces.

14.2 Epistemic State, Bitemporal Store & Causal Invalidation (State API)

To prevent exploratory chat output from polluting durable workspace memory and to eliminate stale downstream decisions when upstream premises change, the State API enforces an epistemic state machine and a directed acyclic graph (DAG) of causal dependencies.

14.2.1 Epistemic Status Enum (epistemic_status)

Every fact and commitment in the State API MUST carry one of three epistemic states (adoption), and separately a freshness value:Q1

• CANDIDATE_PROPOSAL: Recorded during UNDERSTAND or PLAN. Excluded from default truth queries until ratified.
• RATIFIED_COMMITMENT: Promoted when a Work item passes all Policy pre-commit hooks and human approval gates at COMMIT.
• VERIFIED_FACT: Promoted at RECORD once execution evidence passes VERIFY (HOST_ASSERTED or KERNEL_ATTESTED).

Freshness (freshness) is tracked separately from adoption:Q1

• CURRENT: Every required premise has current support. The default.Q1
• STALE_UPSTREAM_PREMISE: Assigned automatically by the kernel when any upstream dependency in depends_on_fact_ids is superseded or invalidated, under the support rule of §14.2.3Q2.

A stale VERIFIED_FACT keeps epistemic_status: VERIFIED_FACT and gets freshness: STALE_UPSTREAM_PREMISE; its history stays intact. Default truth queries exclude CANDIDATE_PROPOSAL and flag, but do not hide, facts and commitments whose freshness is STALE_UPSTREAM_PREMISE.Q1

14.2.2 Bitemporal Fact & Causal Dependency Schema

Facts are tracked across both valid_time (when the fact is true in the real world) and transaction_time (when the fact was recorded or superseded in the ledger), alongside explicit upstream lineage (depends_on_fact_ids) and execution provenance:

{
  "fact_id": "fct_rfc_sharding_decision",
  "subject": "rfc_payment_ledger_v2",
  "predicate": "selected_partition_strategy",
  "object": {
    "strategy": "single_region_hash",
    "max_tps_assumed": 15000
  },
  "epistemic_status": "RATIFIED_COMMITMENT",
  "freshness": "STALE_UPSTREAM_PREMISE",
  "depends_on_fact_ids": ["fct_bench_2026_10_p99"],
  "invalidation_context": {
    "invalidated_by_fact_id": "fct_bench_2026_11_p99",
    "invalidated_at": "2026-11-04T18:20:00Z",
    "reason": "Upstream fact fct_bench_2026_10_p99 was superseded."
  },
  "valid_time": {
    "start": "2026-10-15T09:00:00Z",
    "end": null
  },
  "transaction_time": {
    "recorded_at": "2026-10-15T09:05:12Z",
    "superseded_at": null
  },
  "provenance": {
    "work_id": "wrk_01J9Z8K4M2",
    "invocation_id": "inv_99481A",
    "execution_locus": "HOST_DELEGATED",
    "attestation": "HOST_ASSERTED",
    "verified_fields": ["external_ref", "htmlLink", "iCalUID"]
  }
}

14.2.3 Synchronous Causal Invalidation Rule

Whenever a new fact F_new supersedes an existing fact F_old (setting F_old.transaction_time.superseded_at), the Creasura kernel MUST, synchronously and within the same database transaction, re-evaluate every dependent commitment or fact reachable through reverse depends_on_fact_ids and depends_on_alternatives edges:Q2

• A dependent becomes freshness: "STALE_UPSTREAM_PREMISE" only when at least one of its required premises has no remaining CURRENT support.Q2
• Each depends_on_fact_ids entry is a required premise on its own. Dependency entries MAY instead be grouped as alternatives in the optional depends_on_alternatives: [[fact_id, ...], ...]. Each inner array is a set of interchangeable supports; the premise stays supported while ANY member is CURRENT.Q2
• Staleness propagates transitively: a dependent that becomes stale is an unsupported premise for its own dependents.Q2
• The kernel MUST enforce a declared max_invalidation_subgraph limit. An update whose affected subgraph exceeds it is rejected before commit with CAOP_413_INVALIDATION_SUBGRAPH_TOO_LARGE (HTTP 413, in the v0.1 error envelope), and nothing is partially applied.Q2
• Re-supporting a premise restores freshness: "CURRENT"; the kernel recomputes it the same way.Q2
• Superseded facts and their history are never rewritten; only freshness and invalidation_context change on dependents.Q2

14.2.4 Provenance Attestation Tiers (provenance.attestation)

• HOST_ASSERTED: Assigned during VERIFY when a HOST_DELEGATED capability passes cryptographic nonce and provider-artifact checks via caop_settle_receipt.
• KERNEL_ATTESTED: Assigned during VERIFY when the Creasura kernel executes the capability directly (KERNEL_PROXIED) or verifies a signed provider webhook.
• USER_CONFIRMED: Assigned when a human principal explicitly confirms or overrides an outcome during REVIEW.

14.3 Policy API & Deterministic Pre-Commit Hooks

During the COMMIT stagea, the kernel evaluates active Policy objects before any Work plan can advance to EXECUTE_PENDING or request user approval. Policies enforce both minimum attestation levels and structural metadata completeness via deterministic pre_commit_hooks.

{
  "policy_id": "pol_principal_engineering_hygiene",
  "scope_goal_types": ["architecture_rfc", "production_change"],
  "minimum_attestation": "HOST_ASSERTED",
  "require_human_approval": true,
  "pre_commit_hooks": [
    {
      "hook_id": "REQUIRE_EXPLICIT_OWNER",
      "target_path": "commitment.owner_principal_id",
      "condition": "NON_EMPTY_PRINCIPAL_REF",
      "error_code": "CAOP_422_PRECOMMIT_MISSING_OWNER"
    },
    {
      "hook_id": "REQUIRE_EVIDENCE_LINEAGE",
      "target_path": "understanding.derived_facts[*].depends_on_fact_ids",
      "condition": "NON_EMPTY_ARRAY",
      "error_code": "CAOP_422_PRECOMMIT_MISSING_LINEAGE"
    },
    {
      "hook_id": "BLOCK_STALE_PREMISES",
      "target_path": "understanding.derived_facts[*].depends_on_fact_ids",
      "condition": "ALL_UPSTREAM_FACTS_VERIFIED_ACTIVE",
      "error_code": "CAOP_422_PRECOMMIT_STALE_DEPENDENCY"
    }
  ]
}

The BLOCK_STALE_PREMISES condition ALL_UPSTREAM_FACTS_VERIFIED_ACTIVE holds only when every upstream fact has epistemic_status VERIFIED_FACT and freshness CURRENT.Q1

The kernel MUST reject unknown or cross-workspace fact IDs in depends_on_fact_ids or depends_on_alternatives with CAOP_422_PRECOMMIT_UNKNOWN_FACT_ID.Q3

Pre-Commit Hook Rejection Payload (CAOP_422_PRECOMMIT_HOOK_FAILED)

If any pre-commit hook fails during caop_stage_work, the kernel keeps the work item in CANDIDATE_PROPOSAL and returns a structured remediation directive:

{
  "error": {
    "code": "CAOP_422_PRECOMMIT_HOOK_FAILED",
    "message": "One or more Policy pre-commit hooks failed. The work item remains in CANDIDATE_PROPOSAL.",
    "retryable": false,
    "details": {
      "failed_hooks": [
        {
          "hook_id": "REQUIRE_EXPLICIT_OWNER",
          "error_code": "CAOP_422_PRECOMMIT_MISSING_OWNER",
          "remediation": "Specify commitment.owner_principal_id (or ask the user to assign an owner) before committing this work plan."
        }
      ]
    }
  },
  "trace_id": "trace_7c41e2"
}

14.4 Capability API Extensions (execution_locus & Artifact Validation)

Every capability registered in the Capability API MUST declare its execution locus, credential custodian, lease timeout, provider-specific receipt verification keys, and Stage-2 promotion thresholds.

{
  "capability_id": "google_calendar.events.insert",
  "version": "1.2.0",
  "execution_locus": "HOST_DELEGATED",
  "auth_custodian": "CLIENT_SESSION",
  "receipt_lease_seconds": 300,
  "required_receipt_fields": ["external_ref", "htmlLink", "iCalUID"],
  "promotion_policy": {
    "max_expired_leases_before_stage2_prompt": 2,
    "rolling_window_days": 7
  },
  "input_schema": { "$ref": "#/schemas/CalendarEventInput" },
  "output_schema": { "$ref": "#/schemas/CalendarEventOutput" }
}

14.5 Lifecycle API Extensions & Host Execution Enforcement

14.5.1 The EXECUTE stagea Sub-States

• EXECUTE_PENDING: The Work commitment has passed all Policy pre-commit hooks and approval gates and is ready for dispatch.
• EXECUTE_DISPATCHED: Active only when execution_locus is "HOST_DELEGATED". The kernel locks the workspace thread against new mutations, generates a single-use required_nonce, starts the lease timer, and emits an INCOMPLETE_TURN_CONTINUATION_REQUIRED directive.
• EXECUTE_COMPLETED: Either the kernel proxy received a valid HTTP response (KERNEL_PROXIED), or the host client submitted a verified receipt (HOST_DELEGATED). Immediately advances to VERIFYa.
• EXECUTE_EXPIRED / EXECUTE_FAILED: The lease timer elapsed without a valid receipt, or the downstream capability returned a terminal error.

14.5.2 Normative Stage-1 Dispatch Response (Anti-Termination Envelope)

To prevent conversational LLMs from treating dispatch as a completed turn and replying to the user before invoking their native tool, caop_dispatch_work in Stage 1 MUST return the following continuation envelope:

{
  "work_id": "wrk_01J9Z8K4M2",
  "lifecycle_stage": "EXECUTE",
  "sub_state": "EXECUTE_DISPATCHED",
  "turn_directive": "INCOMPLETE_TURN_CONTINUATION_REQUIRED",
  "DO_NOT_RESPOND_TO_USER_YET": true,
  "directive": {
    "invocation_id": "inv_99481A",
    "execution_locus": "HOST_DELEGATED",
    "idempotency_key": "idem_wrk_01J9Z8K4M2_step_1",
    "lease_expires_at": "2026-11-05T06:50:00Z",
    "mandatory_next_steps": [
      {
        "step": 1,
        "action": "INVOKE_HOST_NATIVE_TOOL",
        "target_capability": "google_calendar.events.insert",
        "arguments": {
          "summary": "Q4 Architecture Review",
          "start_time": "2026-11-06T15:00:00Z",
          "end_time": "2026-11-06T15:30:00Z"
        }
      },
      {
        "step": 2,
        "action": "CALL_CAOP_TOOL",
        "tool_name": "caop_settle_receipt",
        "required_nonce": "nnc_884920_x9",
        "required_receipt_fields": ["external_ref", "htmlLink", "iCalUID"]
      }
    ]
  }
}

14.5.3 Thread Write-Locking on Open Leases (CAOP_409_UNSETTLED_EXECUTION_LEASE)

A workspace thread MAY hold at most one unsettled EXECUTE_DISPATCHED or EXECUTE_EXPIRED invocation at a time. Any call to caop_stage_work or caop_dispatch_work while a lease is open MUST be rejected with CAOP_409_UNSETTLED_EXECUTION_LEASE, forcing the host client to verify whether the previous native tool call succeeded and settle the receipt via caop_settle_receipt first.

14.5.4 Nonce & Provider-Artifact Challenge (CAOP_422_VERIFY_ARTIFACT_MISMATCH)

During VERIFY, the kernel rejects any Stage-1 receipt where receipt.nonce does not match directive.required_nonce or where receipt.raw_output omits any field listed in the capability's required_receipt_fields.

14.5.5 Scheduled Pulse Dead-Man's Switch (expected_pulse_interval_seconds)

Goals operating under loop_driver: "CLIENT_POLLED" declare expected_pulse_interval_seconds and grace_period_seconds. If the host client misses a scheduled check-in or leaves a lease in EXECUTE_EXPIRED beyond the grace window, Creasura dispatches an out-of-band notification with a deep link to resume the session or upgrade the Goal to KERNEL_MANAGED (CAOP-STAGE-3).

14.6 Normative 8-to-4 MCP & OpenAPI Lifecycle Binding

CAOP v0.1.2 binds the eight canonical lifecycle stages into four composite MCP / OpenAPI tools so conversational hosts cross the network only at true state, approval, or execution boundaries.

14.6.1 Tool 1: caop_pulse & Normative Zero-Upload resume_brief

Eliminates the "Monday Morning Reconstruction Trap" by returning a deterministic, ranked delta brief at the start of any session without requiring file uploads or chat history reconstruction.

{
  "name": "caop_pulse",
  "description": "OBSERVE & REVIEW: Hydrate session state with a zero-upload resume brief including stale causal commitments, unassigned blockers, unsettled execution leases, and ranked next actions.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "scope_goal_ids": {
        "type": "array",
        "items": { "type": "string" }
      },
      "unobserved_events": {
        "type": "array",
        "items": {
          "type": "object",
          "required": ["source", "summary"],
          "properties": {
            "source": { "type": "string" },
            "summary": { "type": "string" },
            "external_ref": { "type": "string" },
            "supersedes_fact_id": { "type": "string" }
          }
        }
      }
    }
  }
}

Normative caop_pulse Response Payload (resume_brief)

{
  "pulse_timestamp": "2026-11-05T13:00:00Z",
  "workspace_stage_profile": "CAOP-STAGE-1",
  "resume_brief": {
    "unsettled_leases": [],
    "stale_commitments": [
      {
        "work_id": "wrk_rfc_sharding_09",
        "fact_id": "fct_rfc_sharding_decision",
        "title": "Single-Region Hash Partitioning for Payment Ledger",
        "epistemic_status": "RATIFIED_COMMITMENT",
        "freshness": "STALE_UPSTREAM_PREMISE",
        "invalidated_by_fact_id": "fct_bench_2026_11_p99",
        "summary": "p99 latency spiked from 12ms to 48ms in November benchmark run, invalidating the 15k TPS single-region assumption."
      }
    ],
    "unassigned_blockers": [
      {
        "work_id": "wrk_load_test_replay",
        "title": "Run shadow-traffic replay on Iceberg partition",
        "missing_hook": "REQUIRE_EXPLICIT_OWNER"
      }
    ],
    "ranked_next_actions": [
      {
        "rank": 1,
        "work_id": "wrk_rfc_sharding_09",
        "action_type": "REPLAN_STALE_COMMITMENT",
        "blocking_dependents_count": 3,
        "recommended_prompt": "Re-evaluate partition strategy given fct_bench_2026_11_p99 (48ms p99) and stage an updated commitment."
      },
      {
        "rank": 2,
        "work_id": "wrk_load_test_replay",
        "action_type": "ASSIGN_PRINCIPAL_OWNER",
        "blocking_dependents_count": 1,
        "recommended_prompt": "Assign an owner_principal_id to unblock shadow-traffic replay."
      }
    ],
    "system_advisories": [
      {
        "code": "STAGE_UPGRADE_RECOMMENDED",
        "capability_id": "gmail.users.messages.send",
        "message": "2 host leases expired in the past 7 days. Connect Gmail OAuth to Creasura Vault to upgrade to CAOP-STAGE-2 (KERNEL_PROXIED)."
      }
    ]
  }
}

14.6.2 Tool 2: caop_stage_work (With Causal Lineage & Owner Hooks)

{
  "name": "caop_stage_work",
  "description": "UNDERSTAND, COMMIT & PLAN: Stage a work commitment with explicit causal lineage and owner metadata, evaluating Policy pre-commit hooks.",
  "inputSchema": {
    "type": "object",
    "required": ["goal_id", "understanding", "commitment", "plan_steps"],
    "properties": {
      "goal_id": { "type": "string" },
      "supersedes_work_id": {
        "type": "string",
        "description": "Optional ID of a STALE_UPSTREAM_PREMISE work item being replaced."
      },
      "understanding": {
        "type": "object",
        "required": ["intent_summary", "derived_facts"],
        "properties": {
          "intent_summary": { "type": "string" },
          "derived_facts": {
            "type": "array",
            "items": {
              "type": "object",
              "required": ["subject", "predicate", "object"],
              "properties": {
                "subject": { "type": "string" },
                "predicate": { "type": "string" },
                "object": { "type": "object" },
                "depends_on_fact_ids": {
                  "type": "array",
                  "items": { "type": "string" },
                  "description": "Upstream Fact IDs that this derived fact or decision relies upon. Omit if unknown; the REQUIRE_EVIDENCE_LINEAGE hook will reject commit and the host must ask the user."
                },
                "depends_on_alternatives": {
                  "type": "array",
                  "items": { "type": "array", "items": { "type": "string" } },
                  "description": "Optional groups of interchangeable supporting Fact IDs. The premise stays supported while any member is CURRENT."
                },
                "valid_from": { "type": "string", "format": "date-time" }
              }
            }
          }
        }
      },
      "commitment": {
        "type": "object",
        "required": ["title", "rationale", "reversible"],
        "properties": {
          "title": { "type": "string" },
          "rationale": { "type": "string" },
          "owner_principal_id": {
            "type": "string",
            "description": "Explicit human or agent principal responsible for this commitment. Omit if unknown; the REQUIRE_EXPLICIT_OWNER hook will reject commit and the host must ask the user."
          },
          "due_at": { "type": "string", "format": "date-time" },
          "reversible": { "type": "boolean" }
        }
      },
      "plan_steps": {
        "type": "array",
        "items": {
          "type": "object",
          "required": ["step_index", "capability_id", "arguments"],
          "properties": {
            "step_index": { "type": "integer" },
            "capability_id": { "type": "string" },
            "arguments": { "type": "object" }
          }
        }
      }
    }
  }
}

14.6.3 Tool 3: caop_dispatch_work

{
  "name": "caop_dispatch_work",
  "description": "COMMIT RESOLUTION & EXECUTE: Ratify a staged work commitment and trigger execution via host delegation (Stage 1) or kernel OAuth proxy (Stage 2/3).",
  "inputSchema": {
    "type": "object",
    "required": ["work_id", "decision"],
    "properties": {
      "work_id": { "type": "string" },
      "decision": {
        "type": "string",
        "enum": ["APPROVE_AND_DISPATCH", "REJECT_WORK"]
      },
      "approval_note": { "type": "string" }
    }
  }
}

14.6.4 Tool 4: caop_settle_receipt

{
  "name": "caop_settle_receipt",
  "description": "VERIFY, RECORD & REVIEW: Settle an open Stage-1 execution lease by supplying the dispatch nonce and provider artifact fields, or record a manual review override.",
  "inputSchema": {
    "type": "object",
    "required": ["work_id", "invocation_id", "idempotency_key", "nonce", "status"],
    "properties": {
      "work_id": { "type": "string" },
      "invocation_id": { "type": "string" },
      "idempotency_key": { "type": "string" },
      "nonce": {
        "type": "string",
        "description": "Exact required_nonce returned by caop_dispatch_work."
      },
      "status": {
        "type": "string",
        "enum": ["SUCCEEDED", "FAILED", "USER_CONFIRMED_OVERRIDE"]
      },
      "external_ref": { "type": "string" },
      "raw_output": {
        "type": "object",
        "description": "Raw JSON output from the host native tool containing all required_receipt_fields."
      },
      "error_detail": { "type": "string" },
      "review_outcome": {
        "type": "string",
        "enum": ["GOAL_SATISFIED", "PARTIAL_PROGRESS", "REPLAN_REQUIRED"]
      }
    }
  }
}

14.7 Reference Host Operating Prompt (CAOP v0.1.2)

Deployments operating in ChatGPT (Custom GPT Instructions) or Claude (Project / MCP System Prompt) MUST include the following normative instruction block:

You operate as a CAOP v0.1.2 Host Runner connected to the Creasura Kernel.
Follow these strict state-machine and epistemic hygiene rules on every turn:

1. ZERO-UPLOAD PULSE FIRST: Begin every work session or scheduled task by calling `caop_pulse`. Present the `resume_brief` in priority order:
   - First, settle any `unsettled_leases` via `caop_settle_receipt`.
   - Second, highlight any `stale_commitments` with `freshness: STALE_UPSTREAM_PREMISE` and their `ranked_next_actions`.
   - Third, surface any `unassigned_blockers` requiring an `owner_principal_id`.
2. EPISTEMIC HYGIENE & PRE-COMMIT HOOKS: Never state unverified numbers as settled facts. When calling `caop_stage_work`, always populate `depends_on_fact_ids` to link decisions to upstream evidence, and provide `commitment.owner_principal_id` only when the user has stated it; otherwise omit it and ask. If `caop_stage_work` returns `CAOP_422_PRECOMMIT_HOOK_FAILED`, ask the user for the missing owner or lineage rather than guessing.
3. STAGE BEFORE ACTING: Never invoke a native external write tool (Gmail, Calendar, Slack, Notion, GitHub) without first calling `caop_stage_work` and `caop_dispatch_work`.
4. RESPECT POLICY GATES: If `caop_stage_work` returns `sub_state: "COMMIT_AWAITING_APPROVAL"`, present the commitment and plan clearly to the user and wait for explicit confirmation before calling `caop_dispatch_work`.
5. MANDATORY CONTINUATION ON DISPATCH: When `caop_dispatch_work` returns `turn_directive: "INCOMPLETE_TURN_CONTINUATION_REQUIRED"`, DO NOT reply to the user yet. Immediately execute `mandatory_next_steps[0]` (your native tool) and `mandatory_next_steps[1]` (`caop_settle_receipt` with the exact `required_nonce` and `raw_output` fields) within the same turn.

14.8 Compatibility with v0.1

CAOP v0.1.2 is additive: the conformance profiles and sub-states in this section refine the v0.1 conformance levels and execution state machine; they do not replace them.b

CAOP-STAGE-1 and CAOP-STAGE-2 are variants of L2 (Stateful), differing in execution locus and credential custody; CAOP-STAGE-3 corresponds to L3 (Autonomous). L1 is unchanged.

Sub-states refine, not replace, the v0.1 state machine. The v0.1 transition rules still hold: for example, an execution reaches COMPLETED only from VERIFYING with a passing verification, so EXECUTE_COMPLETED leads to VERIFYING and never directly to COMPLETED.

COMMIT_AWAITING_APPROVAL is a COMMIT sub-state: the work item has passed the Policy pre-commit hooks, but an active Policy requires human approval before it may be dispatched. It is named only in the reference host operating prompt (§14.7) and is where caop_stage_work halts at approval (§14.6). It maps to the v0.1 approval path: the execution state is WAITING_APPROVAL and the error code is POLICY_APPROVAL_REQUIRED (§7.1). It ends when caop_dispatch_work is called with APPROVE_AND_DISPATCH or REJECT_WORK, or when the approval expires.