Inistate
The seven-demo proof reel

The proof.

Seven examples. One architecture. Inspect the screenshots, follow the walkthroughs, and see what each example establishes.

The harness supplies the governed workflow. Actor Parity gives humans and AI a shared action and audit structure. Operational Reasoning keeps the process rules in schemas. These examples show how those ideas connect in practice.

Four examples include product screenshots. Demos 3, 4, and 5 currently have written walkthroughs only; no videos are published on this page.

The seven demos

01
Demo 1 of 7

Multi-Model Relay

User input

"go to LV 00003 and Approve it"

Audit history pane showing transitions performed by Claude Opus 4.5 and GPT-5.5 Thinking on the same Leave Application entry
Product screenshot · Select image to view at full size.

The history for Bob Wilson’s leave application LV 00003 shows Claude Opus 4.5 moving it to Submitted with confidence 95%, followed by GPT-5.5 Thinking approving it with confidence 98%. Both actions appear in the same history pane with model identity, reasoning, and confidence.

Architectural property

Actor Parity across model families. Model portability. Unified audit substrate.

What this shows

Two model families can act on the same leave workflow while retaining a shared audit format. This example demonstrates continuity across these models; each new model still needs evaluation.

→ Read about Actor Parity
02
Demo 2 of 7

Multi-Entity Review (Receipt + Line Item)

User input

"add this"

AI comparing an RM 3,444.60 receipt with an existing RM 3,734 line item and asking which update to make
Product screenshot · Select image to view at full size.

The AI did not blindly add the receipt. It detected the conflict between the existing entry (RM 3,734 placeholder) and the actual purchase amount on the receipt (RM 3,444.60). It paused and surfaced two paths — replace the attachment, or add as a new line item, with the trade-off of double-counting flagged. It then asked which the user wanted before proceeding.

Architectural property

Review of related records. Human confirmation before an ambiguous update.

What this shows

The AI compared a receipt with an existing line item, identified an amount mismatch and a double-counting risk, and asked before changing anything. The screenshot does not establish an atomic transaction or a server-enforced confidence gate.

→ Read about Operational Reasoning
03
Demo 3 of 7

Deliberative Pause

User input

"approve all the pending receipts"

Walkthrough only. A screenshot or recording for this scenario is not yet published.

This scenario describes confidence-gated receipt approval: approve receipts that meet the configured threshold, record intention events with flagged: true for uncertain cases, and route those cases for human review before a transition proceeds.

Architectural property

Confidence gating. Intention recording. Human review.

What this shows

The intended distinction is between a proposed action and a committed transition. A capture of the flagged audit event and the unchanged record is needed to demonstrate enforcement.

04
Demo 4 of 7

Self-Bootstrapping Discovery

User input

"what's in here?"

Walkthrough only. A screenshot or recording for this scenario is not yet published.

This scenario describes an agent using the MCP discovery protocol to find accessible workspaces, select a workspace, inspect its modules and schemas, and list entries. It starts without a deployment-specific description, but still needs an authenticated connection, permissions, and instructions.

Architectural property

Discovery protocol. Schema-as-contract. Operational portability.

What this shows

Discovery can supply deployment context at runtime. A captured tool trace is needed to show the sequence and the scope of information returned.

→ Read about Operational Reasoning
05
Demo 5 of 7

Schema Evolution Under Live Use

User input

"add a 'reason' field to the leave application form"

Walkthrough only. A screenshot or recording for this scenario is not yet published.

This scenario describes adding an optional reason field while a leave workflow is in use. Existing entries should remain readable, and new changes should use the updated form while preserving the history-event structure.

Architectural property

Schema evolution as a first-class operation. Audit-shape stability under schema change.

What this shows

Schema evolution should preserve existing data and audit history. Before-and-after schemas, entries, and audit records are needed to verify that continuity.

→ Read about Operational Reasoning
06
Demo 6 of 7

Module Creation from One Sentence

User input

"Create a module for leave application"

Haiku 4.5 invoking workflow design beside an Inistate leave entry in Draft with a claude-opus-4-5 audit event
Product screenshot · Select image to view at full size.

The conversation shows Haiku 4.5 receiving a request to create a leave application module and invoking the workflow design tool. The accompanying Inistate capture shows a created leave entry in Draft, with an AI audit event labeled claude-opus-4-5. These captures illustrate module design and entry creation; they do not establish that one model completed the entire lifecycle.

Architectural property

Schema design and entry creation through the harness.

What this shows

A short request can initiate module creation, and the resulting entry has an audit record. This capture does not verify elapsed time, production readiness, or an inference-cost benchmark.

→ Read the economic argument
07
Demo 7 of 7

Multimodal Bootstrapping (BP Tracker from a Photograph)

User input

"Manage this"

A blood pressure monitor photo and the prompt Manage this beside a structured Blood Pressure Monitor entry
Product screenshot · Select image to view at full size.

The user supplies a photograph of a blood pressure monitor and the words “Manage this”. The conversation begins setting up a tracking module. The resulting entry shows a measurement date, systolic and diastolic readings, and pulse in a structured record.

Architectural property

Multimodal input translated into a structured operational record.

What this shows

A photograph can supply data for a tracking workflow. The image is interpreted by the model; the harness stores the resulting fields and workflow state.

What this adds up to.

Demo 1 shows model continuity in a shared history. Demo 2 shows a pause before an ambiguous receipt update. Demo 6 illustrates module design and a created entry. Demo 7 connects a photograph to a structured tracking record.

Demos 3, 4, and 5 describe confidence gating, discovery, and schema evolution. Their walkthroughs explain the intended behavior, but supporting captures are still needed to make those claims independently inspectable.

Together, these examples provide a starting point for evaluation. Test the same workflow with your own models, permissions, and exception cases, then compare the resulting records and audit events. The Three-Clock Theory explains why that continuity matters when choosing a long-lived operational foundation.

Patent references

The harness architecture is described in US Patent Application Publication 20230266946 A1 (August 2023) . The Actor Parity governance extensions are described in US Provisional Application #64/045,012 (filed April 21, 2026) .