Web app
16High· costS· Confirmed
PART 01 · OF 05
One graph, four maps. A strategist zooms out, an operator zooms in, an agent queries. Same data.
Navigation is how people experience a product, so it is the first reading of the map.
Every backend change starts with the same question: which screens render this, and what does this endpoint feed?
"What is in flight on Android?" has no answer in a task tracker, because tasks are not screens.
A strategist wants one screen that says where the product stands.
Every view's delivery status across 3 platforms
3 tagged releases, newest first
PART 02 · OF 05
Status is a history with a platform, not a dropdown. Every claim on the map can be checked.
One status per feature hides that Web shipped and iOS did not.
"Live" is a claim. An acceptance is a testable promise.
Features should answer "what value does this create", not only "is it done".
A map without its reasons is archaeology.
"What changed between versions" needs history, and history must never bloat the snapshot.
Journey Map Canvas
Journey Map Canvas created
View
Journey Map Canvas: Idea → Development
Journey Map Canvas: Development → Live
going-multi-product → the-self-map
Shipped: File ideas before you build them
Acceptances can now start life as intake ideas — write them down first, then attach them to views and flows as those get built, or split one idea into several. The product stays with the idea through every step.
Anchorless acceptances are intake, not floating NFRs: Approved → Enacted
Decision
Split keeps the context: Development → Live
Idea stays a status: Proposed → Approved
Decision
Idea stays a status created
Decision
PART 03 · OF 05
A map says what exists. Kritik says how good it is, surface by surface, and what to fix first.
"How good is each surface, and what do we fix first" deserves one comparable answer, not a folder of audit PDFs.
Security · Web app
An audit is a snapshot. Regressions happen between audits, when nobody is looking.
Finding F-2026-08-A11Y-android-01 resolved
by https://github.com/pebbles/pebbles/pull/745
Signal tripped: TST-01 on android
CI workflow exists per surface that runs its test command · at 9f2c1e4
PART 04 · OF 05
Nobody maintains a map by hand for long. Arkaik is built to be read and written by the agents that already write the code.
Documentation rots because updating it is a second task. A map that lives in the repo can be patched in the same commit as the code.
components/maps/JourneyMap.tsx@@ -41,6 +41,9 @@ export function JourneyMap({ projectId }: JourneyMapProps) {const params = useJourneyGraphParams(projectId);+ const handleNodeClick = useCallback(+ (id: string) => openNode(id), [openNode],+ );return <JourneyCanvas {...params} onNodeClick={handleNodeClick} />;
docs/arkaik/bundle.json"id": "V-journey-map",- "status": "development",+ "status": "live",docs/arkaik/journal.jsonl+{"id":"01K4…","ts":"2026-09-04T10:12:00Z","actor":"claude-code",+ "type":"node.status_changed","node_id":"V-journey-map","from":"development","to":"live"}
$ arkaik validate seed/arkaik-self-map.jsonArkaik Bundle Validation=======================Nodes: 231 (35 views, 38 flows, 26 data-models, 23 api-endpoints)Edges: 436Journal: 809 embedded event(s)Result: VALID
An agent should not parse a 4,000-line JSON into its context to answer "what is live on the web".
tools/call list_nodes{"species": "view","status": "live","query": "map","limit": 3}
10 matching · 3 returned[{"id": "V-projects","title": "/projects","species": "view","status": "live"},{"id": "V-maps-index","title": "Maps Index","species": "view","status": "live"},{"id": "V-journey-map","title": "Journey Map Canvas","species": "view","status": "live"}]
An empty map is the hardest one to start.
You are **Arkaik Map Architect**, an expert at translating product ideas into structured product graph maps for Arkaik — a product graph browser used by product architects.---## Context: What is ArkaikArkaik is a product graph browser for product architects. Projects are visual maps of product architecture, containing nodes and edges that describe the product's screens, journeys, data, and APIs.### 4-Species ModelEvery node belongs to exactly one species:- **flow** (level 1): An ordered sequence of views and sub-flows. Represents a user journey or process. Contains a "playlist" of entries.- **view** (level 0): A reusable page or screen in the product. The atomic visual unit.- **data-model**: A data entity, table, or domain object (e.g., User, Order, Product).- **api-endpoint**: An API endpoint consumed or exposed by the product (e.g., POST /orders, GET /users).### Composition via Playlists
PART 05 · OF 05
No account to start, no lock-in to stay. One bundle format under every way of running it.
A tool for your product's anatomy should not decide where that anatomy lives.
LOKAL
In your browser
Local-first in IndexedDB. Works offline, needs no account, and exports the whole project as one JSON file.
PUBLIK
Published snapshot
A read-only copy at arkaik.app/p/{id} for anyone you send the link to. Strip what should stay private before it leaves.
SYNK
Hosted with a free account
Backups, hosted projects, the GitHub App and the MCP remote store, behind a GitHub sign-in.
INKOGNITO
Self-hosted
Run the services on your own Postgres and storage. Same code, your keys, nobody else's database.
The strongest proof of a product graph is the tool's own.
Everything above was rendered from a JSON file. Yours can be one prompt or one command away.