thale
System Map · AI Integration
How it works →
Two production systems, node by node

The ecosystem

A capture arrives from a phone, a chat app or a folder. It's read — handwriting, speech, PDFs — classified against a vocabulary that changes, and drafted into a finished note. A person approves it. It's filed as plain markdown, embedded, clustered into topics, and served as a browsable 3D map, with a content-hashed mirror into Postgres running nightly underneath. Thirteen of the 516 nodes are a language model.

11
Workflows
516
Nodes
503
Connections
13
AI nodes
109
Documented

Two engagements: a personal knowledge system, and an organisational signal layer. Neither client is identified and no instance is reachable from here. Every diagram is the real canvas — positions and wiring read off the platform, not redrawn — and node descriptions marked • are the builder's own comments rather than anything written for this page.

How it works

Capture, data, analysis, interface, backup

Six stages. Each one is a separate workflow, or several, and the handoff between them is deliberately a file or a row rather than a call.

Capture
A photo, voice note, PDF, typed line, dropped pin or checklist. One gesture, no decisions at the moment of capture — because the friction of filing is what kills the habit.
Telegram Capture
Phone Capture Webhook
↓ file lands in a watched folder
Read
Vision models read photographed pages including marginalia; speech is transcribed; PDFs and links are extracted. What the capture is gets established before anything tries to classify it.
Inbox Watcher
↓
Analyse
Sorted against a living controlled vocabulary — proposing new tags only when existing ones genuinely don't fit — then drafted into a complete note with a title, summary, substance and a line on why it might matter.
Inbox Watcher
↓ written as a row in the review queue
Review
Nothing enters the vault unapproved. The draft is read and answered: yes, no, or edited. AI proposes; the human disposes — and that boundary is enforced by code, not convention.
Serve Map (approve route)
↓ approval triggers filing
Data
Written into the vault as plain markdown the owner holds outright — readable in any editor, with or without this system. Then embedded, and clustered into topics that become real pages rather than labels.
Filing
Map Regeneration
↓
Interface
A navigable 3D map that redraws itself as the library grows, plus the review queue, the approve path and a weekly digest — all served directly out of the automation platform rather than a separate application.
Serve Map
Waggle Dance
↓ and underneath all of it, continuously
Backup
A nightly incremental mirror of every note into Postgres, content-hashed, so a run that syncs nothing and a run that syncs everything can be told apart. Verified by diffing identities in both directions rather than comparing counts.
Supabase Backup
Health
Faults are signed by shape rather than exact text, counted rather than repeated, and escalated on a doubling cooldown — so a persistent fault says a bigger number rather than saying the same thing 214 times.
Error Handler × 2

The second engagement, the signal layer, runs the same shape against an organisation rather than a person: read the org's structure on a schedule, diff it against the last run, and report what changed into a chat channel.

How the parts connect

Four calls and seventeen files

The nine workflows of the knowledge system hardly call each other at all. They're joined by files.

There are four direct calls in the whole system. Everything else is coupled through 17 files on a Drive, 13 of which more than one workflow touches — the rebuild and the web server alone share ten. One workflow writes a file; another notices.

That's a deliberate trade. A file handoff survives a workflow being edited, republished or failing halfway, and any stage can be run on its own with real data. The cost is that the coupling is invisible on any single canvas — which is exactly why it's drawn here.

queue row approve writes the note nightly mirror graph.json rebuild Telegram Capture Phone Capture Inbox Watcher Serve Map Filing Supabase Backup Waggle Dance Map Regeneration Error Handler The vault 17 shared files bound as the failure route by all seven
Direct call — one workflow executes another File handoff — one writes, another notices

The two signal-layer workflows sit apart from this entirely: a schedule, a read of the organisation's structure, a diff against the last run, a message. Same shape, different subject.

Composition

Where the model actually sits

The interesting number isn't how much AI is in here. It's how little, and how deliberately placed.

Thirteen AI nodes, and only eight of them are a call — six agents plus a vision read and a transcription. The other five are the model bound to an agent, wired in on a second port rather than in the main line.

Models get exactly one kind of job: judgement about content — reading a photographed page, transcribing speech, classifying against a vocabulary that changes, drafting the note, grouping notes into topics a person would recognise.

Everything that writes, deletes, renames, schedules, locks, deduplicates or separates domains is deterministic code with an explicit condition. That's why a bad model response produces a refused run rather than a damaged vault.

Explore

Every workflow, every node

Open one to see its real canvas. Drag to pan, scroll to zoom, hover any node to read what it does. Filtering narrows the list and dims the diagram to match.

Reading the shape

What the counts say

Guard density

78 conditional nodes — one in every seven.

Most check a precondition and refuse: does the response carry the field it should, is the rebuild lock free, has this capture already been queued, would this rebuild retire more topics than it keeps.

Web surface

32 webhooks and 72 response nodes, nearly all in one workflow.

The map, the review queue, the approve path and the digest are served straight out of the automation platform — no separate app, no separate deploy.

Storage

80 Drive operations, 13 Sheets, 3 Postgres. Notes are plain markdown the owner holds outright; Postgres carries a content-hashed mirror of all of them, verified by identity in both directions rather than by matching counts.

Glue

134 code nodes, 101 of them opening with a written explanation of what the step is for and, often, which incident produced it. Those comments are the descriptions on this page.

Next

What's being built now

Both systems are live and in daily use. These are the next pieces, in order.

Incremental clustering

Topic clustering re-reads the entire corpus on every rebuild, so cost and memory both climb with every note ever filed.

The Postgres mirror already knows which notes changed. Reading only those turns a seventeen-minute step into a query, and flattens a curve that otherwise compounds forever.

Capture by email

A forwarding address, so anything read in a mail client joins the same pipeline as a photograph — with whatever the sender types above the forward treated as their own commentary on it.

Provenance

Every filed note traceable back to the capture that produced it, so an incident can be answered rather than reconstructed.

Self-monitoring

A layer holding explicit expectations about the systems' own behaviour — what should have run, how long real work takes — reporting only the divergences. Silence only means something once something is expected.

Anything irreversible is allowed to say no. A refused rebuild leaves a stale map; a bad one destroys the structure underneath it.

What it is built on

Counted from the live instance, not written from memory. Every figure below is the result of walking the workflows, so it can be checked against the maps above.

Models

External services called

Credentials in use