Is this the app governance dashboard?

No. App Governance is the first internal instance. This page shows the reusable CREATE SOMETHING database-layer shape with safe sample data.

Does this replace Notion?

Not as a headline. Notion remains useful for PM, capture, review, and distribution. The database layer becomes the operating substrate when workflows need API, MCP, Atlas, actions, and receipts.

Why show records on the front end if the layer is AI-native?

AI-native does not mean invisible. Agents and APIs can operate the data, while humans can inspect the same records, bindings, actions, receipts, and audit evidence.

Substrate Database Canvas

A database built for visual operation.

Substrate is the CREATE SOMETHING database-layer system design: durable workflow records rendered through a WebGPU canvas so humans can inspect topology, policy, actions, and proof before agents run.

Start Workflow Map See Product System

Canon system plate

The database becomes an operating surface.

Traditional databases hide relationships behind tables, dashboards, and delayed reports. Substrate uses a canvas-native record model so topology, computation, policy, and human review can be consumed in one frame.

A database built on WebGPU.

Records, relationships, compute state, policy, and proof stay visible enough for a human to inspect, annotate, and decide in the loop.

Primitive Database / Automation / JudgmentRenderer WebGPU canvas, fallback-safeConsumption visual first, API-readableHuman loop inspect, annotate, decide

Topology view 60 FPS inspection

4 records sample working set

4 bindings Atlas nodes

<16ms visual response inspection target

WebGPU surface canvas-native

Layers Substrate stack

Substrate Durable records, actions, runs, receipts, and source bindings.

Topology Relationships, owners, policies, clients, APIs, and workflow edges.

Atlas The human inspection canvas: run, wait, stop, handoff, and proof.

Performance at scale 60 FPS

GPU-accelerated visual inspection.

The database can render relationship density as an operator surface, not a slow report after the query.

Query path records -> topology -> canvas

Working set 4 records / 4 bindings

Human in the loop

The canvas is where judgment happens.

Operators inspect the same state agents and MCP tools can read: source, relation, policy, action, receipt.

Allowed run

Needs owner wait

Blocked stop

Live query trace

Visual consumption changes the database.

Rows are still there. The difference is that relationships, risk, and proof can be scanned before an action runs.

Surface UI / API / MCP / Agent

Proof 4 receipts

Canvas ergonomics

Inspect topology, then focus the record under review.

The WebGPU canvas direction matters because it changes the operator loop. A human can move from overview to Substrate record to proof trail without leaving the database surface.

Substrate / Topology / Atlas

Inspect the database as a canvas.

WebGPU makes the database visual enough for human review: Substrate stores the record, Topology reveals the relationships, and Atlas gives operators the inspection controls before agents run.

Substrate records Topology graph Atlas review WebGPU-ready

Interactive sample

System design you can inspect at record speed.

Filter the sample records, select a row, and inspect the Atlas binding, current action, and proof receipt. The active working set stays local-feeling; the canonical model remains API/MCP-readable.

Diagram showing source records, a selected record, Atlas binding, workflow action, and proof receipt. — Canon visual **Substrate has to be inspectable before it is agent-operable.**
The image mirrors the live sample below: records, bindings, actions, and receipts are the same operating object, not separate marketing ideas.
Generated PNG with SVG source brief and prompt metadata retained.

Owner Micah

Status ready

Binding bound

Relations 12

Runtime Substrate / first-class

The UI is a fast WebGPU-ready projection over the database contract, not a second source of truth.

Cloudflare D1 relational records
R2 files and receipts
Atlas graph state

Atlas binding CREATE SOMETHING internal operating system

Client source record: Imported relation evidence plus source-map projection.

create-something-internal-operating-system-source-map / source_record_clients_create_something

Workflow action run: Render public database demo

Show filtered records, Atlas binding, related action, and receipt without exposing private state.

Read-only sample data only

Proof receipt Notion transfer readiness is ready with no open source-update actions.

11 sources captured, 115 records projected, zero unreviewed blockers.

2026-07-07T14:35:00.000Z

Speed budget

Use Obsidian as the feel baseline, then add shared durability.

The target is not another heavy workspace. The operator path should feel immediate on loaded records while Cloudflare keeps collaboration, audit, files, API, and MCP durable.

local

Record navigation

Immediate local filter, selection, and row-to-detail movement on loaded records. Baseline: Obsidian-like command speed for the operator path. Filtering and selection should stay client-local for active working sets; cloud reads refresh the state without blocking inspection.

cloud

Direct record URLs

Every important record, Atlas node, action, run, and receipt has a durable address. Baseline: No hidden canvas-only state. The system should open directly into the object under review, then show adjacent records without forcing a full workspace reload.

agent

Agent read path

Agents can inspect the same source record, binding, action, and receipt through API/MCP. Baseline: No UI scraping or prompt-only state. The database layer should make agent work cheap to verify because every action writes back to a durable object.

cloud

Proof refresh

Receipts and audit entries stream into the interface as small state updates. Baseline: Fast notes app feel with shared database durability. The UI should favor incremental refresh, optimistic inspection, and stable geometry over full-page churn.

System design

The database is the workflow topology.

Substrate is strongest when maps, records, policies, execution, and proof are one object model. UI, desktop, API, MCP, and agents become projections over that model.

Database

Topology is data

Maps, nodes, edges, source bindings, relations, actions, runs, and receipts are first-class records. Evidence: Atlas can render and agents can operate without depending on browser session JSON.

Automation

Execution is inspectable

Workflow movement happens through API/MCP actions and runs, then closes with receipts. Evidence: Run, wait, stop, complete, and blocked states are stored as objects with owners and policy.

Judgment

Judgment is attached

Approvals, waivers, policy reasons, and handoff decisions stay beside the affected record. Evidence: A reviewer can inspect why a record is ready without reading a chat transcript.

Database

UI is a projection

The fastest possible front end reads cached working sets and updates the canonical records. Evidence: The browser, desktop shell, API, MCP, and agents share the same Substrate object model.

API-native

The same state has to work for UI, API, MCP, and agents.

The database layer is not special because it stores rows. It is special because workflow records, map bindings, policy actions, runs, and receipts are durable objects any approved surface can inspect.

Sample records from the reusable database-layer contract.

Atlas bindings that keep maps connected to record truth.

Workflow actions with run, wait, stop, and complete state.

Receipts that explain why the current state can be trusted.

API

Typed records

Every source record, Atlas binding, action, and receipt has a stable JSON shape.

MCP

Agent tools

Agents can inspect, propose, repair, and receipt database-layer state under policy.

Agent

Policy gates

Run, wait, stop, and complete states are records instead of hidden prompt instructions.

Readable control

Humans can filter, select, inspect bindings, and verify receipts in the browser.

Receipts

Proof is part of the record, not a follow-up note.

A workflow can only be delegated when the record shows what happened, who owns the next step, why the current state should be trusted, and which surface can inspect it.

01 Notion transfer readiness is ready with no open source-update actions.

transfer: 11 sources captured, 115 records projected, zero unreviewed blockers.

02 Workstream relation proof completed and action closed.

proof: External source-truth relation updated, then imported back into D1.

03 Reviewed relation state is visible before more agent authority is granted.

decision: Review ledger keeps the gap decision inspectable for humans and agents.

04 App Governance proves API/MCP/dashboard parity for a concrete database instance.

handoff: Same D1 records drive MCP tools, dashboard rows, Atlas maps, actions, and receipts.

Build from one workflow

Bring the workflow that deserves its own operating database.

I’ll map the source system, transfer path, Atlas topology, record model, speed budget, API/MCP boundary, and receipts needed to make the workflow operable.

Talk Through a Workflow See Stack Boundary

Map Bring one workflow

Source systems, owners, handoffs, and stop states.

Record Transfer the source truth

Rows become source records before they become Atlas nodes.

Operate Run through API and MCP

Actions and receipts stay inspectable for humans and agents.