The influence map
The register as a graph: 25
influences, 14 recorded relations between them, and 18 places where a pattern from an
anchor work lands in the estate. Computed, not drawn — every node and every edge on this
page is a field in data/influences.json, so
the graph cannot disagree with the entries it is made of.
This is the site's own G³ demonstration in miniature. The influences that produced the estate's graph thinking — Luhmann's slip-box, the Semantic Web's edges, Bush's associative trails — are here as nodes in a graph, which is either a satisfying loop or a slightly circular one, and the honest answer is that it is both. The open question is whether this page eventually belongs on the graphs sibling instead.
The lineage
Influences are not independent, and the interesting structure is between them: what nests under what, what composes with what, and which idea led to which. Colour is tier — traced, stated, discovered.
graph LR bret_victor["Bret Victor"]:::traced wardley["Simon Wardley and Wardley Maps"]:::traced semantic_web["Tim Berners-Lee and the Semantic Web"]:::traced graphs["Graphs"]:::traced owasp["OWASP and the security community"]:::traced flow["Flow, and coding in the zone"]:::traced open_source["Open source and its licences"]:::traced luhmann["Niklas Luhmann and the Zettelkasten"]:::traced popper["Karl Popper and falsifiability"]:::traced torvalds["Linus Torvalds"]:::traced design["Design, with a capital D"]:::traced design_canon["The wider design canon"]:::traced csikszentmihalyi["Mihály Csíkszentmihályi"]:::traced cathedral_bazaar["The Cathedral and the Bazaar"]:::stated david_rice_keynote["David Rice — Upon the Threshold of Opportunity"]:::stated music_and_band["Music, and playing in a band"]:::stated diverse_distributed_teams["Diverse and distributed teams"]:::stated vannevar_bush["Vannevar Bush and the memex"]:::discovered bret_victor -->|supplies the mechanism| flow wardley -->|a map is a claim| popper semantic_web -->|feeds| graphs david_rice_keynote -.->|nests under| owasp owasp -->|the formative case| diverse_distributed_teams csikszentmihalyi -.->|nests under| flow flow ---|composes with| bret_victor flow ---|composes with| csikszentmihalyi cathedral_bazaar -.->|nests under| open_source torvalds -.->|nests under| open_source vannevar_bush -.->|nests under| luhmann luhmann -->|the same claim, on paper| graphs design_canon -.->|nests under| design music_and_band -->|hypothesised origin| flow classDef traced fill:#e7f3f1,stroke:#0f766e,color:#10302c; classDef stated fill:#fdf3e3,stroke:#b45309,color:#3b2708; classDef discovered fill:#eef1fb,stroke:#3b4c9e,color:#1c2445;
The diagram renders in your browser from the fence above. If the module does not load, the fence stays readable as text and every edge it draws is also listed in the table below — a picture that can fail should never be the only copy of the thing.
The 7 entries with no recorded relation
They are not in the diagram, because a column of unattached boxes made it four times taller while saying nothing. Standing alone is a fact about the register rather than about the influence: an edge is only drawn where a field in the register records one, and several of these are unconnected simply because the briefing document that would connect them has not arrived. Where a lineage is plausible but undocumented — Kevin Kelly's technium and Wardley's evolution axis are the obvious pair — the edge is deliberately not drawn, because guessing one here would be the same failure as inventing a trace row.
Anders Ericsson & deliberate practice Bruce Schneier Neil Peart & Rush Kevin Kelly's books Simon Sinek — the golden circle Christopher Alexander Team Topologies & Cynefin
Every recorded relation
Influence → principle → estate
The other projection, and the one that makes an entry falsifiable: each influence distilled to one transferable principle, and every place a pattern from its anchor work is claimed to land in the estate. Rows marked absent on the entry pages are not here — this is what is built, not what is specified. The gaps are on the entries.
Tim Berners-Lee & the Semantic Web
Meaning should be machine-readable, so that independent parties can exchange it without agreeing on a schema first.
| Pattern | Where it lands in the estate | Version |
|---|---|---|
| Machine-readable meaning as the target — a graph a machine can act on rather than a document it can only parse | The estate's graph substrate and the concept document that sets out its thinking | v0.4.0 |
| Meaning derived from connection between things | The edge-first graph model the estate's ontology work is built on | v0.4.0 |
| Personal data under the person's own control (Solid pods) | Encrypted vaults, keyed by their holder — compared to pods explicitly, as complementary architectures with different threat models | v0.6.17 |
Flow, and coding in the zone
Clear goals, immediate feedback and a challenge matched to skill produce the zone — so a methodology's job is to protect those three conditions, not to optimise throughput.
| Pattern | Where it lands in the estate | Version |
|---|---|---|
| Immediate feedback as a precondition of the state | The estate's development methodology, whose stated core principle is preserving developer flow state | v1.2.1 |
| Clear goals — the person always knows what they are trying to do next | The methodology's structure: work proceeds in units small enough to hold in one head | v1.2.1 |
| Challenge matched to skill | The division of labour between person and model — generation delegated, judgement retained | v1.2.1 |
| Programming named as a flow-inducing activity, with the criteria applied | The Joy-of-Programming argument, which cites Csikszentmihalyi directly and works through the criteria | — |
Karl Popper & falsifiability
A claim earns its status by being refutable. If nothing could show it to be wrong, it is not saying anything.
| Pattern | Where it lands in the estate | Version |
|---|---|---|
| A claim must be refutable to be worth making | Wardley mapping as practised here — a map is a claim about position and movement, refutable by pointing at a misplaced component | — |
| State the conditions under which you would be wrong | The risks register's falsifiable-statement discipline — an accepted risk with a named acceptor and a named mitigation | — |
| The demarcation applied to inspiration itself | This site's trace tables. An influence entry is written so that it can be checked against the repositories and found wrong | — |
| Publishing the refutations, not only the claims | Partial. The gaps are published as build specs and the absent rows are kept, but no claim on this network has yet been retracted in public | — |
Design, with a capital D
Design is not decoration applied after engineering — it is how the thing works. Start from what the person is trying to do and work backwards to the simplest interaction that does it.
| Pattern | Where it lands in the estate | Version |
|---|---|---|
| Design is how it works, not how it looks | The estate's Designer role definition, which is built on the formulation and extends it to coherence between internal structure and external experience | — |
| Start from the user's intent and work backwards (the Ive principle) | The NotebookLM case-study brief, in a section named for the principle, with the MP3-to-CD story as the worked example | v0.7.4 |
| Good design is invisible — you notice it by reverting and feeling the loss | The Jonathan Ive test: is it simpler? would reverting feel worse? — a mandatory validator for every UI change | v0.7.4 |
| Simplicity as subtraction — the feature removed rather than the feature added | Implied by the Ive test's first half and not separately enforced. Nothing records what was taken out of a change | v0.7.4 |
The wider design canon
Every element must earn its place. Hierarchy, affordance and proportion are properties of any designed thing — an API and a CLI included, not only a screen.
| Pattern | Where it lands in the estate | Version |
|---|---|---|
| Less, but better (Rams) as a working principle rather than an aesthetic | The Designer role definition, applied to API surface rather than to visual design | — |
| Code as inhabited space — is it navigable, is it comfortable | The same role definition's criteria for reviewing structure | — |
Christopher Alexander
Code is a space that people inhabit. A pattern is a named solution to a recurring problem in a context — and a language of patterns is what lets a place be built by many hands and still be coherent.
| Pattern | Where it lands in the estate | Version |
|---|---|---|
| Code as a space developers inhabit — judge it by navigability and comfort | The Designer role definition's review criteria | — |
The graph, as data
/map/graph.json carries the same nodes, edges and
landing rows in one file, regenerated on every release. Each entry's own rows are also published
per-entry at /register/<slug>/trace/trace.json.