List the steps, tools, and people involved. Agree on what AI may do and how you will check the result.
What You Keep
Your system should stay yours.
Your accounts, data, and decisions stay with your team. We document the work so you can use it, change it, and evaluate other tools. Deliverable ownership follows your agreement.
- Your team keeps Accounts + decisions
- Work records Status + evidence
- Vendors provide Replaceable infrastructure
Ownership route
Your accounts Systems and access
Your decisions Approval authority
Your records Work history and proof
Your team keeps the durable assets
One ownership story
Know what your team keeps and what we maintain.
See what we deliver, what your team controls, and which services come from outside vendors.
01 / 04 Map → pilot → control
Know what happens at each stage.
Diagnose the problem, agree on the change, then build and test it. Ongoing support preserves context and helps your team use the result.
Build and test one agreed task. Keep its code, work history, and instructions together.
Decide which tasks can run automatically, which need approval, and which must stop.
Receipts
workflow mapcontrolled pilotoperating control
02 / 04 Show what must stop
Your team decides which actions are allowed.
The plan shows the information AI uses, the work it can prepare, who approves it, and the record kept afterward.
Who owns what canvas
Your team decides which actions are allowed.
This example shows how a claim moves through review. AI can prepare the work; the responsible person approves consequential actions.
1. Map Claim intake packet before execution. Claims operations owner owns the operating path. The canvas makes the workflow, handoffs, and next decision legible before an agent or system acts. 2. Claim system triage can run when the rule is clear. Claim system triage coordinates with Coverage context summary; the map keeps AI assistance bounded to the work it can safely support. 3. Adjuster review stays with a person. Adjuster handles coverage uncertainty, fraud flags, payout, denial, and sensitive messaging. 4. No payout or denial authority is the stop condition. Stop before coverage decision, payout, denial, or fraud escalation without authority. 5. Claims queue receipt shows the receipt. Shows triage class, missing documents, adjuster state, and customer-contact trail. 6. Use the map as booking context for a workflow pilot. The map has enough owner, assistive work, system behavior, and decision context for a first run.
Workflow map Editable workflow
Run Wait Stop
Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.
Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.
Evidence
- allowed routing
- named authority
- stop conditions
- audit trail
03 / 04 Keep the durable assets
Keep the instructions and work history.
Your team keeps its account details, access rules, approvals, instructions, and work history. We document deliverables and reusable tools under the agreement. The handover explains how to remove access.
Public source example · pi-policy-os v1.0.5
Open the files. See what makes work transferable.
This is our published open-source package, not a client handoff. Inspect the real material behind each label.
01InstructionsREADME.md
pi install npm:@createsomething/pi-policy-osThe actual installation command, followed by the available commands, skills and prompt templates. A starting point someone else can follow.
Read the actual instructions ↗02Testspolicy-os-starter.test.ts
assert.ok(events.has('session_start'));
assert.ok(commands.has('policy-check'));Two assertions from the repository test. They check that the extension registers its session event and public command. This excerpt is test source, not a claim about a test run.
Read the actual tests ↗03OwnershipLICENSE
MIT License
Copyright (c) 2025 Create SomethingThe published MIT license permits use, modification and redistribution with its notice retained. CREATE SOMETHING retains copyright. Your commissioned deliverables follow your own agreement.
Read the actual ownership ↗04Recovery notesdebug-feedback-loop/SKILL.md
Reproduce → minimize → fix → verify → recordA summary of the published debugging procedure: capture the symptom, reproduce the failure, make a regression check, rerun the original check and record evidence and rollback notes. This is a method, not an application-specific rollback runbook.
Read the actual recovery notes ↗Source pinned to a published repository revision. Verify public distribution ↗
Receipts
workflow maptool contractpolicy rulesrunbookoperator brief
04 / 04 Change models after testing.
Built with OpenAI. Prepared for change.
We build primarily with OpenAI Codex. Your project keeps its data, code, tool definitions, instructions, tests, and recovery guide. A different model must pass the relevant checks before you switch. CREATE SOMETHING maintains the system layer; Cloudflare provides infrastructure and OpenAI provides intelligence.
Development tool and portable exit
The AI coding tool we use to build the project and help your team make the next change.
Your team keeps the business context, permissions, tests, work history, and recovery instructions.
The same tool definitions and test tasks can help compare Claude, open-weight models, and custom models.
What each part does
Substrate OpenAI
Our database system stores the records, tasks, approvals, and work history. APIs and MCP let approved software access it.
CloudflareCloudflare provides hosting and storage. We document who owns the account, who pays for it, and how to undo a release.
OpenAI provides the AI models and coding tools. Your rules determine which tools an agent can use and when it needs approval.
Start with the workflow
Bring the workflow, the accounts, and the decision owner.
We’ll diagnose the problem and agree on scope, ownership, and approvals before implementation. Support helps your team use the delivered changes.
- Owner
- Workflow owner
- Authority
- Owned stack boundary
- Proof
- Controlled path + decision states
- State
- review
- 01 / Workflow First workflow map
Objects, source systems, owners, handoffs, and failure points.
- 02 / Boundary Vendor and ownership boundary
What your team owns, what we deliver, and what vendors provide.
- 03 / Control Decision states
Auto-allow, approval-needed, and blocked states with reasons.