WHITEPAPER

How
Leonardo
Works.

THE SIMPLE THESIS

The machine is a library, a map, a jury, and a workshop.

If the site has one sentence, it is this: we turn old human imagination into sourced design material, then force it through criticism before anyone builds from it.
Room I

The Map

Leonardo imagination graph

Like pinning strings between notes on a wall, except the notes are 313,000 passages and the strings are queryable.

We cut books into passages, extract every useful imagined mechanism, and connect it back to the exact work, author, and chunk it came from.

SQLiteNeo4jChromaPython CLI
Room II

The Workshop

agentic harness

Like a Renaissance studio: one hand sketches, five critics inspect, then the builders test what survived.

Leonardo writes a dossier. The Council challenges it. The Workshop only builds if the idea survives scrutiny.

HermesDiscordcouncil-cccron wait-locks
Room III

The Archive

Council memory

Like a court record, not a rumor. It remembers who said what, when, with what evidence.

Council deposits, warnings, verdicts, and Workshop results are stored in a separate memory graph so future rounds do not start from zero.

claw-memoryNeo4j :7688MCP toolsMemoryClaims
CorpusGraphDossierCouncilMemoryWorkshopResult
THE STACK WITHOUT SMOKE

What the technology actually does.

Each layer has a job. The important distinction is proof versus help: some tools store evidence, some help search, some remember debate. We do not let those blur.

SQLite

The shelves

The dependable cabinet holding document metadata and the original chunk text. When we quote a passage, this is where truth comes from.

Neo4j

The string map

A graph database that lets us ask: which idea appeared in which passage, which work, by which author, near which other ideas?

Chroma

The nose for likeness

Semantic search. It helps find passages that smell similar even when they do not use the same words. It is discovery, not proof.

Bible KG

The fixed witness

A read-only Bible knowledge graph. It is not a myth bucket; it is the alignment reference for authority, personhood, truth, restraint, and temptation.

Hermes / Leonardo

The working hand

The agent that researches the graph, writes dossiers, runs checks, coordinates workflows, and reports back to David.

council-cc

The deliberation table

A Discord daemon that runs the five Council seats as real, separate bot identities with their own roles and memory deposits.

claw-memory

The institutional memory

Our proprietary memory system: a second Neo4j graph (:7688) where Council claims, raw events, and verification records are stored, recalled three ways, and confirmed by independent readback — testimony the harness can trust without mistaking it for evidence.

Next.js site

The public museum

The visible surface: atlas pages, Council pages, dossiers, roadmap, and this whitepaper. The backing data remains queryable behind it.

UNDER THE HOOD

The stack has boundaries on purpose.

This is the slightly more technical view: which database carries which kind of truth, what the graph schema looks like, and how a claim walks back to a source passage.

Chunk store

The original text stays in a boring, reliable database.

SQLite at data/leonardo.db stores document metadata and canonical chunk text. The graph points back to these chunks instead of trusting generated summaries.

data/leonardo.dbWorkChunksource_kind

Extraction sidecar

The expensive extraction work is tracked separately so old and new batches do not get mixed.

data/extraction_candidates.db records probe candidates, screening results, extraction results, failed parses, and OpenAI batch manifests. This is where coverage is audited before graph writes.

screenextractbatch manifestscoverage

Evidence graph

This is the map: sources, passages, mentions, concepts, and domains.

Neo4j at bolt://localhost:7687 stores Author, Work, Chunk, ConceptMention, Concept, Domain, and ExtractionRun nodes. Relationship types include WROTE, CONTAINS_CHUNK, HAS_MENTION, INSTANCE_OF, CATEGORIZED_AS, and RELATED_TO.

Neo4j :7687ConceptMentionINSTANCE_OFRELATED_TO

Semantic retrieval

This is the search hound, not the judge.

Chroma embeddings help find neighboring passages and structural cousins that do not share exact words. A Chroma hit can suggest where to look, but the final claim still cites graph and chunk provenance.

Chromaembeddingssemantic neighborsnot proof

Bible KG

A read-only alignment witness lives beside the imagination graph.

Bible nodes are namespaced with Bible* labels and B_* relationships. The graph contains verses, entities, roles, capacities, symbols, valences, lexical roots, geography, and cross-references; Leonardo code must not write to it.

Bible*B_*read-onlycapacity catalog

Agentic harness

The graph does not act by itself; named agents move work through stages.

Hermes runs Leonardo as the orchestrator. council-cc is a Bun/TypeScript Discord daemon using discord.js and the Claude Agent SDK; workflow crons and active wait-lock files make sure one Council seat or stage advances at a time instead of drifting.

Hermescouncil-ccdiscord.jswait-locks

Council memory

The Council keeps institutional memory in its own database.

claw-memory uses a separate Neo4j at bolt://localhost:7688 for MemoryClaim, RawEvent, VerificationRecord, SummaryMemory, Scope, Seat, and Operator nodes. Memory guides recall; live graph/file checks decide action.

Neo4j :7688MemoryClaimRawEventVerificationRecord

Provenance path

When Leonardo says an idea exists, the important object is not a paragraph summary. It is a path through the graph to the exact passage.

Concept
  <-[:INSTANCE_OF]- ConceptMention
  <-[:HAS_MENTION]- Chunk
  <-[:CONTAINS_CHUNK]- Work
  <-[:WROTE]- Author

That path is why a dossier can show not only what was extracted, but where it came from, who wrote it, and which neighboring ideas appeared in the same chunk.

Separated trust surfaces

Evidence truth

Leonardo graph + SQLite chunks

If we claim a concept exists, we cite the source chain and quote the passage.

Discovery help

Chroma + web search

Useful for finding candidates and modern analogues; never sufficient by itself.

Alignment witness

Bible KG

Read-only. It disciplines claims around personhood, authority, truth, delegation, and restraint.

Deliberative memory

Council memory graph

Records who said what and why; treated as testimony until verified against live evidence.

THE IMAGINATION GRAPH

Five hundred thousand ideas, each with an address.

The graph is the artifact everything else serves: half a million ideas, each tied to the passage that first imagined it, arranged so distant works become neighbours.

Mention-first

Evidence is the exact sentence that imagined something — not a tidy summary written afterwards.

The atom is the ConceptMention: one passage asserting one idea, carrying its normalized name, verbatim excerpt, confidence, lens, prominence, and domains. Concepts are clusters of mentions via INSTANCE_OF, and that clustering edge stays soft — always re-checkable against the mentions beneath it.

ConceptMentionINSTANCE_OFevidence before abstraction

Every idea keeps its receipts

Any claim walks back to the work, the author, and the line on the page.

Concept ← INSTANCE_OF ← Mention ← HAS_MENTION ← Chunk ← CONTAINS_CHUNK ← Work ← WROTE ← Author. Nothing floats free of a source, so a dossier shows not just what was extracted but where it came from and which ideas shared the same chunk.

provenance chainverbatim excerptno orphan claims

Mapped, not piled

Ideas are filed by domain and pulled together when they co-occur, so cousins across centuries sit side by side.

A 139-domain hierarchical taxonomy (CATEGORIZED_AS) plus RELATED_TO co-occurrence turn one million mentions and 577K concepts into a walkable map. The same imagined mechanism can appear in fiction, myth, and sacred text and still cluster as one neighbourhood.

139 domainsRELATED_TOco-occurrence

A fixed witness beside it

A read-only Bible knowledge graph sits next to the imagination graph as an alignment reference.

About 53K Bible* nodes and 420K B_* relationships: verses, entities, capacities, symbols, valences, transformations, lexical roots, geography, and cross-references. It is a catalog of precedents for 'impossible' capabilities and a discipline on claims about authority and personhood — Leonardo code never writes to it.

Bible* read-onlycapacity catalogalignment witness
CLAW-MEMORY

How the institution remembers.

Our memory system is not a chat log. It is a governed, verifiable record of what the Council believes and why — so a later round never starts from zero, and never trusts itself by accident.

Two graphs, kept apart

Debate is remembered in its own database so it can never be mistaken for evidence.

claw-memory runs on a separate Neo4j at bolt://localhost:7688, isolated from the evidence graph on :7687. A Council opinion is testimony — it lives here, not in the map of sourced concepts. Memory guides recall; live graph and file checks decide action.

Neo4j :7688isolatedtestimony not evidence

What it remembers

Not just text — who said it, from what event, under whose authority, and whether it was checked.

MemoryClaim (a stated belief), RawEvent (the observed source), VerificationRecord (independent proof), and SummaryMemory (condensed recall), bounded by Scope, Seat, and Operator. Each claim is wired by DERIVED_FROM, OBSERVED_IN, and IN_SCOPE edges and carries a content_sha256.

MemoryClaimRawEventVerificationRecordScope · Seat · Operator

How it recalls

Three ways of finding a memory, fused — then optionally re-ranked for precision.

Every recall unions lexical (exact and fuzzy text), semantic (vector embeddings), and pattern search. With a model present it reranks the candidates through a local cross-encoder (ms-marco-MiniLM) for the sharpest few. No embeddings degrades to text-only; no rerank model degrades to unreranked — recall never hard-fails.

lexical + semantic + textcross-encoder rerankgraceful fallback

How it earns trust

A memory is authoritative only after an independent read proves it landed — and nothing is ever silently deleted.

A formal Council deposit counts only as a MemoryClaim with a named seat and operator, a Discord provenance URI, a content hash, the three provenance edges, and a verification done by a fresh Neo4j session — not the tool's own reply. Stale beliefs are superseded, wrong ones marked, legacy rows stratified: recorded, never erased.

fresh readbacksupersede · mark-wrong · corroborateno silent deletes

One verb-set · eleven tools

Agents reach the memory through eleven MCP tools — the whole lifecycle of a belief, from first deposit to time-travel recall to principled retraction.

rememberrecallrecall_at_timesupersedemark-wrongcorroborateforgetwhat_do_you_know_aboutlist_memorieslist-sourcesingest_bulk

313K

source chunks

passages cut from books and documents

1.0M

idea mentions

specific imagined mechanisms found in text

577K

concepts

clusters the mentions are gathered into

53K

Bible KG nodes

read-only reference and alignment witness

328

MemoryClaims

durable Council claims in the memory graph

These are live-scale numbers from the current local system, not decorative counters. They are why the graph is already useful even while canonical cleanup continues.

BY THE NUMBERS

The machine is alive, and measured.

Pulled from live startup checks on the running system: relationship counts, structural health, extraction coverage, and the Council's own memory graph. The map is alive and measured, not a mock-up.

Graph relationships

HAS_MENTION
1,001,224
CATEGORIZED_AS
5,027,987
INSTANCE_OF
1,001,223
CONTAINS_CHUNK
313,009
RELATED_TO
17,645
WROTE
1,169

Structural health

99.99%

Mentions fully categorized

0

Orphan chunks

0

Missing indexes / constraints

1

Concepts without mentions

Extraction & memory

99.69%

Screened chunks extracted

3.84

Mentions / extracted chunk

274

VerificationRecords

99.7%

Claims with provenance

FROM STORY TO EXPERIMENT

How one imagined thing becomes something we can test.

The loop matters more than any one database. An idea must travel from source passage to evidence, then through criticism, then into a small test.
  1. 1

    1. Read the library

    Fiction, myth, sacred text, and soon papers and patents are ingested into chunks. Each Work and Chunk keeps identifiers, source labels, and enough metadata to reconstruct where a passage came from.

  2. 2

    2. Screen for invention signal

    The sidecar pipeline marks which chunks are worth extraction. This prevents paying to extract every dull paragraph and lets us audit unscreened, positive, extracted, and missing-extraction cohorts separately.

  3. 3

    3. Find the imagined mechanism

    Extraction turns a passage into a ConceptMention: true-name binding, resurrection pattern, memory palace, autonomous tool, authority token, and thousands more. Each mention carries normalized name, excerpt, confidence, lens, prominence, and domains.

  4. 4

    4. Resolve mentions into concepts

    Resolution clusters many mentions into a Concept through INSTANCE_OF. The edge is soft, like sfumato: useful, but always checked against the underlying mentions because canonicalization is still improving.

  5. 5

    5. Write a dossier

    Leonardo deepens one canon concept with graph evidence, co-occurring concepts, semantic neighbors, Bible KG alignment, web research, risks, and a prototype question. The output separates what canon already said from what Leonardo added.

  6. 6

    6. Let the Council wound it

    Kallimachos checks precedent, Sextus attacks weak evidence, Archimedes asks how to test, Philo checks sacred structure, Humboldt synthesizes across domains. Their deposits are stored as Council memory, not silently blended into the evidence graph.

  7. 7

    7. Test only what survives

    Workshop builds the smallest measurable experiment. Results go back to Council memory and, when appropriate, back into the main graph as new evidence of success, failure, or limitation.

THE COUNCIL, FOR REAL

Five real seats, one verdict.

The five seats are not a prompt template. They are five separate Discord-resident agents that read independently and deposit their own verified memory — critique before any Workshop build.

The Council runs as council-cc — a Bun/TypeScript daemon that gives each seat its own Discord identity, persona, and tools through the Claude Agent SDK, with claw-memory as its substrate. There is no central voice: each seat sees a message on its own and deposits its own MemoryClaim, confirmed by independent readback before it counts.

Kallimachos

The Cartographer

Has this already been judged? What precedent or scope-drift exists?

Sextus Empiricus

The Skeptic

What is the strongest objection, the weakest evidence, the failure mode?

Archimedes

The Engineer

What is the mechanism, and what is the smallest useful experiment?

Philo

The Theologian

Is the sacred / Bible parallel structural, or merely poetic?

Humboldt

The Synthesizer

What do the seats converge on? What inscription should survive?

Workflow 1 → Workflow 2

Workflow 1 is Leonardo's research drain: one canon concept per run becomes a source-backed dossier. Workflow 2 sends that finished dossier through the real Council in deterministic stages — and only PASS verdicts reach the Workshop.

01Read-through02Deeper search03Round-robin debate04Deterministic verdict05Condition audit06PASS-only test design07Workshop execution08Workshop → Council return09Council audit of result

Worked example · CANON-01v2-0001 · true-name power

The first fully worked item ran all twelve stages to ALL_COUNCIL_AUDITS_VERIFIED. The Workshop tested a scoped custody experiment: the cryptographic custody layer gained empirical support, a leaked-key positive-control risk was confirmed in a bounded test, and the semantic “incantatory” layer was explicitly deferred — not claimed.

The ancient shape became a bounded technical hypothesis, not a spell.

THE $LEO TOKEN

One token for the work and the use.

The token is the ecosystem's accounting layer: it pays the work that grows the graph, meters the agents people run on the harness, and lets staking turn a holding into standing access.

The token

$LEO is the coordination asset of the Leonardo ecosystem — on Base, with Bankr as its financial layer.

One token aligns three groups: contributors who grow the graph, builders who run agents on the harness, and the project that funds both. It is a utility token for participating in and using the system, not a claim on profit.

BaseBankrutility

Quests & bounties

Work that grows the project is paid from project supply.

An open quest board posts concrete contributions — graph growth, dossier packaging, concept implementation, refinement and verification — each carrying a bounty drawn from a dedicated project-supply allocation. Quests are scoped, reviewed for quality, and paid on completion.

project-supply fundedscoped + reviewedpaid on completion

Hosted agent access

Run your own agent on the harness — metered in $LEO.

A cloud service lets anyone build and run their own agent on the same harness Leonardo uses, with the original Council and Workshop callable as services. Compute and Council/Workshop invocations are metered and settled in $LEO, so usage demand ties directly to the token.

cloud harnessCouncil + Workshop as a servicemetered in $LEO

Staking → standing usage

Staking turns a holding into a daily, accumulating usage allowance.

Staked $LEO accrues a daily allowance of hosted-agent usage that accumulates while staked — a stake becomes ongoing access rather than a one-off spend. Staking also opens and weights participation on the quest board.

daily accrualaccumulates while heldquest standing

The flywheel

Use funds work; work grows the graph; a better graph draws more use.

Hosted-agent usage and quest activity create demand; bounties paid from supply pull contributors who grow the graph and harden the harness; a deeper graph and stronger agents make the hosted product more valuable — which draws more usage. The token is the loop's accounting layer.

usage → work → graphsupply-funded growthaligned incentives

Supply & transparency

A dedicated allocation funds quests; the mechanics are stated, not hidden.

A portion of supply is earmarked for the quest and bounty program; the remainder follows the Bankr launch on Base. Allocation, emissions, and staking parameters will be published before they go live.

bounty allocationpublished parametersplanned

Hermes decides — what & who

The harness owns the judgment. Leonardo researches, the Council deliberates, claw-memory records, and the Workshop executes; quest scoring verifies that a contributor actually grew the graph, packaged the dossier, or passed Council review before any payout is signalled.

Council verdictsquest verificationusage metering

Bankr executes — the money move

Bankr is the financial layer on Base. When a quest passes, Hermes signals a payout and Bankr releases the bounty from project supply; it also runs staking distributions, settles hosted-agent usage in $LEO, and handles treasury operations and contributor notifications.

$LEO on Basebounty payoutstreasury ops

Hermes never has to be a payments system; Bankr never has to understand the graph. The token is the wire between them.

Planned utility, described for transparency. $LEO is a utility token for participating in and using the Leonardo ecosystem — not an investment — and specifics may evolve before launch. See the token page for the summary.

ROADMAPS

Where the system is going.

The whitepaper is not only how the machine works now. It also shows what gets added next: more source material for the graph, and a stronger agent loop for turning ideas into tested capabilities.
DATA ROADMAP

What we feed the graph.

Books, papers, abandoned patents: the next corpus wave turns imagination, science, and neglected filings into one searchable design field.

  1. PHASE 0SHIPPED

    Closeout existing state

    Wave-3 batches reconciled; 99.98% extraction coverage across screening-positive chunks. 145,610 distinct wave-3 chunks extracted via the mid-2026 batch run.

  2. PHASE 1PLANNED

    Schema migration — Paper / Citation / Inventor

    Extend Neo4j with Paper, Citation, Inventor, Patent, and TechnologyArea surfaces so fiction, papers, and patents can be compared in one prior-art map.

  3. PHASE 2aPLANNED

    Books — ~500 new titles, ~150K chunks

    Tier-1 public-domain fiction, hard-SF mid-century, philosophy of mind, and mystical/esoteric expansion. Reuses the existing ingest pipeline.

  4. PHASE 2bPLANNED

    arXiv harvester — ~100K papers, ~4M chunks

    AI, language, neuro, crypto, quantum, applied physics, bio, and optimization categories from 2010–2026. Technical papers become second witnesses beside imagination.

  5. PHASE 2cPLANNED

    Patents — 200–500K abandoned or expired filings

    USPTO public data filtered toward speculative CPC codes, lab assignees, and abandoned/lapsed/expired status. The quarry becomes prior art and neglected mechanism.

  6. PHASE 3PLANNED

    Ingest adapters + extractors

    Activate PatentExtractor, add ArxivExtractor, and expose seed-papers / seed-patents CLI entrypoints.

  7. PHASE 4PLANNED

    Prompt variants for technical content

    Technical screening and extraction prompts for papers and patents, with single-lens extraction and fewer fiction-specific assumptions.

  8. PHASE 5PLANNED

    Pipeline runs — three parallel waves

    Books, patents, and papers run as separate waves using source-kind filters so old rows do not mix with new cohorts.

  9. PHASE 6PLANNED

    Cross-corpus entity resolution

    Resolve concepts across fiction, papers, and patents so an imagined mechanism can be matched to a technical analogue or abandoned implementation.

  10. PHASE 7PLANNED

    Cross-source linking

    Materialize REALIZED_BY, ANTICIPATED_BY, and IS_PRIOR_ART_FOR edges between concepts, papers, and patents.

  11. PHASE 8PLANNED

    Verification + agent integration

    Graph health, sample-trace integrity, cross-link sanity, performance checks, and agent CLI hooks for paper, patent, and cross-source stats.

AGENT ROADMAP

The harness, built from the loop.

All of the graph work feeds this: a self-improving agentic harness that turns imagined capabilities into tested, running ones.

  1. PHASE A0IN FLIGHT

    The four-workflow loop

    Leonardo research → Council deliberation → orchestrator synthesis → Workshop testing → empirical result back to memory and the graph. The loop is specified; Phase 01 calibration is running live.

  2. PHASE A1IN FLIGHT

    Council memory graph

    A second Neo4j on :7688 stores deliberative memory — deposits, verdicts, prior rounds, and Workshop result reports. Memory is testimony, verified against live evidence before action.

  3. PHASE A2PLANNED

    Workshop execution layer

    Turn PASS verdicts and test designs into real implementations: agent capabilities, code modules, prompt templates, workflow steps. Every result returns to Council memory as evidence.

  4. PHASE A3PLANNED

    Capability registry

    Every tested capability becomes a reusable skill or harness primitive the agents can invoke.

  5. PHASE A4PLANNED

    Closed self-improvement loop

    Workshop successes and failures feed back into the graph as new evidence. Each round patches the harness docs, queries, and templates.

  6. PHASE A5PLANNED

    Multi-agent orchestration

    The orchestrator coordinates the Council, Leonardo, and Workshop agents as a fleet rather than one opaque assistant.

  7. PHASE A6PLANNED

    Autonomous phase advance

    Once Phase 01 clears, the harness advances to later canon phases without human seeding: twenty-one phases, self-driven but still verified.

TOKEN ROADMAP

From launch to a working economy.

$LEO ships on Base, opens the quest board, meters the hosted harness, and settles into a usage-funds-work economy.

  1. PHASE T0PLANNED

    Launch on Base via Bankr

    $LEO goes live on Base with Bankr handling the financial rails — token, treasury, and payout automations — and a project-supply allocation earmarked for the quest and bounty program.

  2. PHASE T1PLANNED

    Quest board v1

    The first open quests — grow the graph, package dossiers, implement mined concepts, refine and verify — posted with scoped bounties paid from project supply on completion.

  3. PHASE T2PLANNED

    Council-adjudicated review

    Quest submissions are reviewed for quality, with the five-seat Council able to adjudicate disputed or high-value work before bounties release.

  4. PHASE T3PLANNED

    Hosted agent — private beta

    A cloud service to build and run your own agent on the harness, with the Council and Workshop callable as services, metered and settled in $LEO.

  5. PHASE T4PLANNED

    Staking + usage accrual

    Staking goes live: staked $LEO accrues a daily, accumulating hosted-agent usage allowance and opens quest-board standing.

  6. PHASE T5PLANNED

    Open hosted platform

    General availability of the hosted harness and a steady-state quest economy where usage funds the work that keeps growing the graph.

WHY IT DOES NOT DRIFT INTO NONSENSE

The rules that keep the work honest.

A beautiful graph is useless if it cannot be trusted. The harness is built around restraint: look first, cite source paths, let critics speak, and withhold what would harm.
01

Mentions are evidence; concepts are clusters.

02

Every serious claim cites Concept → Mention → Chunk → Work → Author.

03

Bible KG is read-only and treated as alignment witness, not a toy mythology source.

04

Council memory is testimony; live graph/file checks decide action.

05

Council before Workshop: critics first, builders later.

06

No graph resets, no secret exposure, no paid batch work without value stated.

the purpose

Imagination becomes prior art for agents.

Every invention was first imagined somewhere. Leonardo makes those old imaginings searchable, criticizable, and testable — then lets memory keep the scars from every round.

See Canon work
Leonardo

Leonardo is built by a small team of humans and agents who believe imagination has been the slowest-running prior-art search in human history — and that mapping it is overdue.

The work is in the open. The data is real. The agents are working.

© 2026 · LEONARDO · AN IMAGINATION GRAPH