Sketches

the native app program · 2026-11-10

One page per structure we are building or following: the apps, the plane, the data switch, the message channel, the grant, the loops. Drawn in the design system so each can be captured into its cycle's record and read by the team without the transcript.

Communicating decisions, opinions, structures and patterns to the team is a requirement of the process, not an afterthought; this is why the cycle pages are documented the way they are. Some of these sketches will be replaced or joined by Mark's own drawings.

c130Native App (program)

The three apps and the planescene

What runs where after the roadmap: the sensor and the native app on the endpoint, the control plane with its web app and two databases, and the people on each side.

The program mapdiagram

Eight cycles and a naming cycle, the four gates between them, and what each waits on.

c131Native App V1

The app map and its two statesdiagram

Five pages and the tray; local (editable) and connected (read-only), and the sentence the app says in each.

The DataNozzlediagram

A page asks a repository, the repository asks the nozzle, the nozzle picks one of three sources. One switch for the whole process, never a per-page flag.

c132Native Design Prototyping

The design loop for native screensstrip

Brief, mock, experiment, refine, push, with the media that can carry each step now that there is no DOM.

c133Remediation Training

A training is four thingsstrip

Trigger, lesson, check, record: a finding becomes a lesson and completion becomes proof in the audit log.

The record: one event, three readsdiagram

From the policy's detection to one small event in the plane's audit log, and the three places that read it: the finding, Reports, the operator's inbox.

c134Control Plane Web App

One image, two deploymentsdiagram

The UI over the Go app over Postgres and ClickHouse, run by us as SaaS or by the customer from one Docker image; endpoints connect, people sign in.

c135Component Cleanup

The scorecardmatrix

Every layer component against Mark's five checks, with its cousins and its resolution.

c136Mechanic Access

A grant and its five statesdiagram

Purpose, level, scope, window, who, record; none, requested, active, revoked, closed.

c137App Messaging

Overseer, ports, citizendiagram

Two parties, four ports between them, one schema for every message, and the citizen's hand on the delivery.

c138

Developer mode and its gatesdiagram

What the sensor serves today and what it does not, the nozzle that carries it, the pages that show it, and the three gates between a customer and its cost.

c139

An update and its statesdiagram

Nine states from up to date to managed elsewhere, three preferences, one trace, and the same page in two eras: build partners now, a structured rollout later.

c144

Theatre modediagram

Three kinds of tour your agent can give; in theatre, a story of AI going wrong is played on synthetic data, between a switch turned on and off together, and every beat is a test of the dashboard.

c146

One file, three sources, one checkdiagram

config.yaml comes from one of three places; every change to it, the person's or an agent's, passes one check; an agent drafts the whole file and the person applies it.

c147

The common tonguediagram

One finding, minted where the activity happened; the machine, the person and the plane each append their own events to it, and the record never changes.

c0Call My Name (qnative)

The naming mapmatrix

Six things to name, from the native app to the SaaS address, against the mental models a customer already holds.