Operational Reasoning.

The inversion.

Most AI products put the operational intelligence inside the model. The agent has the system prompt that knows the workflow. The runtime has the orchestration code that sequences the steps. The framework has the abstractions that decide which tool to call when.

This is convenient for the vendor. It is fatal for the buyer.

Models deprecate. Prompts drift. Orchestration code lives only inside the framework that wrote it. When the model the system was built on is sunset — and the model clock churns every six months — the operational intelligence goes with it.

Operational Reasoning is the inversion. The intelligence does not live inside the model. It lives inside the schema. The schema describes what is possible, what is required, what comes next, what gets recorded. The model reads the schema to know what to do. The model writes the schema to record what happened.

When the model is replaced, the schema is unchanged. The next model reads the same schema, executes the same transitions, and produces the same audit. The operational intelligence persists. The model is disposable.

The schema is the new prompt.

"Prompt engineering" was a useful interim discipline. It is not a long-term architectural foundation. The discipline is real but the artifact is fragile: a prompt is a string of natural language whose behavior depends on the specific model, the specific version, the specific tokenizer, the specific RLHF.

A schema is different. A schema is a contract. It declares the entities, their states, the transitions between them, the activities that drive the transitions, the forms that capture the activities, and the audit shape that records them. The schema does not depend on which model is reading it.

In Inistate, the AI does not receive a prompt that explains what to do. It receives a schema that defines what is possible. It chooses an activity, fills the form, and submits. The schema validates. The transition fires. The audit record persists.

The schema is the new prompt. Every architect who has tried to ship an AI agent in production has felt the prompt fragility problem. The fix is not better prompts. The fix is to stop putting intelligence in the prompt at all.

In code, this is what it looks like.

An abridged module schema with one entity, three states, an actor-agnostic activity, a confidence threshold, and the history-event shape.

{
  "module": "leave_application",
  "entity": "LeaveApplication",
  "states": ["Draft", "Submitted", "Approved", "Confirmed"],
  "activities": [
    {
      "name": "submit",
      "actor": "any",
      "from": "Draft",
      "to": "Submitted",
      "form": {
        "fields": [
          { "name": "start_date", "type": "date", "required": true },
          { "name": "end_date",   "type": "date", "required": true },
          { "name": "reason",     "type": "string" }
        ]
      },
      "confidence_threshold": 0.85
    }
  ],
  "history_event": {
    "by":      { "type": "actor_ref" },
    "on":      { "type": "timestamp" },
    "changes": { "type": "field_diff[]" },
    "ai": {
      "type": "object",
      "fields": ["reasoning", "sources", "model", "model_version", "prompt_hash", "confidence"],
      "optional": true
    }
  }
}

The schema above is the operational source of truth. A human submitting the form through the browser, Claude submitting it through MCP, and GPT-5 submitting it through MCP all hit the same code path. They all produce the same history event. The audit can be queried with one query.

This is what externalizing operational intelligence into persistent schemas means in practice.

→ See the full schema

Why Operational Reasoning compounds.

Every workflow built on the harness is a permanent asset. The workflow runs today on whatever model is current. It will run tomorrow on whatever model is next. The workflow is not a function of the model; it is a function of the schema.

Over time, an organization accumulates a library of schemas — leave applications, expense approvals, vendor onboarding, incident response, medication review, trade settlement, claims adjudication. Each schema is durable. Each is portable across models. Each is auditable in the same shape.

The compounding asset is the schema library. Models will continue to churn. The harness will continue to run.

This is why the right purchase decision is to buy by audit format and harness portability, not by the specific model your vendor happens to ship today.

→ Read the procurement argument