System cartography — schema-first maps and typed graphs
The class of problem
Before the build, the map.
Before you can build in an unfamiliar domain — or trust a large corpus — you have to know its shape, and most teams jump straight to a tool or a vendor pick without ever mapping the surface. The class is decision-under-unfamiliarity: scoping a landscape, or making a messy corpus answerable, before committing to a build.
What it is
Three related artifacts: a cartography method that catalogs an unfamiliar domain before any build, and two typed graphs that make a corpus queryable. The class is schema-first structure: define the node and edge types before touching the data, parse a real corpus into exactly those types, then query across the result. Each artifact applies that method to a different kind of corpus, and at a different stage of maturity.
Where it generalizes
All three are instances of the BI / knowledge layer — cataloging a domain or corpus so it is queryable: the discovery step before a data or vendor decision, the scoping pass over an unfamiliar stack, the retrieval substrate under a knowledge product.
The front of the pipeline
The map is the deliverable — not a recommendation.
The /mapit method produces a universe map: a wide-net triage catalog of every component, vendor, and technology in an area, written before any build decision is made. The output is a dated document per area.
Wide net, held wide
The catalog stays wide — nothing is filtered out prematurely — while still flagging what fits. The map exists to establish the full surface of options first.
Scored against real constraints
Each entry is scored against the constraints that actually apply to the work: the hardware on hand, the standing license posture, and the domains already in play.
The decision is a later step
Deciding which component to adopt is a separate, later step. The map makes that decision possible; it doesn't make it.
Structure in the document
The lightest-weight of the three artifacts and the only one with no graph behind it: the structure lives in the document's schema — component, vendor, technology, score — rather than in a database.
The corpus, typed
The schema is the design.
A typed knowledge graph over a career-evidence corpus, built on KuzuDB — and a sibling spike that tests whether the approach transfers to a different corpus and a different engine.
Typed nodes, versioned types
Nodes are typed — mechanisms, domains, career phases, through-lines, meta-patterns, and evidence — and the schema itself is versioned: the type definitions evolve under version control rather than drifting implicitly.
Disposition, apart from method
The central modeling choice separates the invariant from the method. A disposition — the underlying invariant a mechanism expresses — is modeled as a distinct thing from the method that expresses it, so the same disposition can be traced across different domains and across time.
Disposition-preserving ingestion
The parser reads the real corpus and lands each item as the node type the schema declares — without flattening the disposition/method distinction the schema is built to hold.
De-identified corpus
No client data is present in the graph; the mechanisms and evidence are abstracted from their original engagements.
What's in the graph
COMPOUNDS_WITH cross-domain relationships as first-class edges The query that justifies the structure
A cross-domain probe: find the cluster mechanisms that span three or more domains across both past and present. It returns 10 such mechanisms in 24 ms. Over a flat document set the same probe would require manual cross-referencing; here it is a single traversal, because the cross-domain relationships are first-class edges.
The sibling — dev-tel-graph
Same method, different corpus, different engine
A graph layer over a personal telemetry vault, built on a different graph engine than mechanism-graph's KuzuDB. It exists partly as a test: does the typed-graph approach transfer across both the corpus and the underlying store? At spike stage — enough to exercise the method, not a finished artifact.
spike stageWhat they share
Define the types. Parse the corpus. Query the result.
The schema-first method is the through-line. In each case the result is queryable, not a diagram.
| Artifact | Corpus | Where the structure lives | Stage |
|---|---|---|---|
| galaxy-map | an unfamiliar technology domain | a document schema — component, vendor, technology, score | in use; multiple universe maps produced |
| mechanism-graph | a career-evidence corpus | a typed KuzuDB store | full corpus ingested; schema versioned; probe gate met at 24 ms |
| dev-tel-graph | a personal telemetry vault | a typed store on a different engine | spike stage |
The three sit at different points on one axis: galaxy-map maps an unfamiliar domain before a build; mechanism-graph and dev-tel-graph make a known corpus queryable after the fact.
What comes next
A public retrieval demo
mechanism-graph plus a vector-retrieval layer is the candidate next step — the typed graph as the retrieval substrate under a public demo. It is not yet built.
candidate · not yet built