Business ownership, approval authority, source accounts, data rights, and final operating decisions.
Stack Boundary
Know what you own before any tool acts.
Your team should be able to see who owns the accounts, where secrets live, which actions can run, which decisions need approval, what stops, and what evidence travels with the handoff.
Source records, Atlas bindings, actions, approvals, runs, receipts, and operator views stay in the owned system.
Hosted services, APIs, uptime, product limits, and platform-specific capabilities.
How the stack becomes a service
The stack should read like a handoff, not a vendor diagram.
The story stays simple for a non-technical team: map the boundary, pilot one safe workflow, then control the risky actions only when live work needs it.
Name the workflow, source accounts, decision owner, first action boundary, and evidence needed before delegation.
Turn one repeated handoff into scoped actions, durable state, receipts, and a runbook only after the safe path is clear.
Classify live actions as auto-allowed, approval-needed, or blocked with a reason before the workflow touches risk.
Boundary canvas
A stack boundary becomes useful when it shows what must stop.
The story canvas turns vendor roles into an operating map: source data, allowed routing, assistive work, human judgment, stop conditions, and the audit trail.
Stack boundary canvas
The workflow boundary decides what tools are allowed to do.
This read-only map shows the stack promise in workflow terms: tools can route and prepare, but payout, denial, fraud, and sensitive decisions stop for named authority.
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 7 nodes / 7 edges
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.
What your team keeps
You keep the receipts, not a mystery stack.
The technical stack can change. The durable asset is the workflow boundary: source accounts, scoped access, allowed actions, stop states, approval owners, runbooks, revocation paths, and evidence.
One workflow, source systems, owners, handoffs, and failure points.
What your team owns, what CREATE SOMETHING owns, and what vendors provide.
Tools, resources, auth scopes, allowed actions, and transport limits.
Auto-allow, approval-needed, and blocked states with reasons.
Recovery, release evidence, rollback notes, and operator handoff.
The visible state in Substrate, Dify, or a client-owned application.
Platform conviction
Model-opinionated in practice. Model-portable by design.
CREATE SOMETHING builds primarily with OpenAI Codex. The durable client asset is data, MCP contracts, harnesses, skills, prompts, policy, evals, receipts, routing, fallback, and recovery—not access to one model.
The primary environment for setup, demonstration, repository work, and agent-operable delivery.
The workflow boundary, organizational context, approval rules, evals, receipts, and recovery path stay inspectable and portable.
The same contracts and golden tasks can evaluate Claude, compatible harnesses, open-weight executors, and custom models.
Owned system and active stack
Substrate owns the system. Three external platforms earn one role each.
Substrate is the owned database and operator layer. OpenAI provides the primary agent environment, Dify provides visible agent applications, and Cloudflare provides the runtime. Their contracts remain inspectable and replaceable.
Substrate OpenAI
The CREATE SOMETHING database and operator layer owns source records, Atlas bindings, workflow actions, approvals, runs, receipts, and API/MCP access.
CloudflareWorkers, D1, Durable Objects, queues, and edge routes keep the workflow deployable while account ownership, billing, and rollback evidence stay explicit.
DifyVisible agent surfaces, repeatable server cards, and operator-facing automation when the workflow needs packaging with approval states attached.
The primary reasoning and agent environment stays surrounded by scoped tools, approval behavior, evals, and traceable context instead of hidden authority.
Start with the workflow
Bring the workflow, the accounts, and the decision owner.
CREATE SOMETHING will map the stack boundary, define the first controlled path, identify what can be assigned, and show what stays visible to the operator before implementation starts.
- 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 I deliver, and what vendors provide.
- 03 / Control Decision states
Auto-allow, approval-needed, and blocked states with reasons.