# BUILT TO BE INHERITED
:number V
:accent #5a8e00
:message Write so a stranger can resume, sell, or sunset your work.
:epigraph Knowledge is Power · Legacy is Wealth · Built to Last.
:drawn-from The owner's-manual format · SimNap OS · Assets & Continuity · CRCKBL · The Canonical & Collapse Registry

## THESIS

Every document in the source library answers a question most documentation never asks: *what happens to this if I am not here?* Not as morbidity — as engineering requirement. A solo portfolio has a bus factor of one on every asset, and the manuals treat that number the way an architect treats gravity: not a reason to stop building, a constraint to design against.

The design answer is a format. Each of the twenty-nine projects carries an owner's manual in the same uniform structure — identity, classification, core concept, feature inventory, architecture, ecosystem role, history, current state, monetization, competition, vision, roadmap, risk, preservation, ranking, next actions, canonical summary — audited, truth-tagged, and written for a reader who was not in the room. The format *is* the inheritance. Code describes what a system does; the manual preserves what it is *for*, what it is worth, and what to do with it — the three things a successor cannot recover from the repository.

Inheritance here means more than heirs. The same document that would let a family act on an asset also lets a buyer diligence it, a licensee trust it, a collaborator onboard to it, or the author himself resume it after two years away. Continuity is one property with many beneficiaries, and it is cheapest to build in from the start — every manual written while the knowledge is fresh, every asset carrying its own instructions like a seed carries its own genome.

The exhibits move through the format's hardest cases: how to mothball a project without killing it, what a continuity record must contain beyond passwords, how to make a live system's output usable by someone who cannot operate the system, and how provenance itself becomes sales collateral.

[[figure:manual-anatomy]]


## CONTEXT — HOW TO READ THIS VOLUME

This volume is the reason the library exists in book form rather than in a private folder. Everything before it makes a system trustworthy while its author is present. This one asks the colder question: what happens to it when he is not.

The exhibits are the machinery of handover — the manual written for a successor rather than a user, the license that survives the licensor, the continuity switch, the estate framed as a namespace rather than a pile of repositories. Each one converts something that lived in one person's head into something a second person can operate without permission.

The discipline generalizes below the estate. The same instinct that writes a succession document also writes the README that lets a future self return after eighteen months away. Inheritance is not a morbid topic; it is the strictest possible test of documentation, and any project that passes it is easier to work on today.

## EXHIBIT A — MOTHBALLED WITH DIGNITY
:source SimNap OS — Canonical Owner's Manual

SimNap OS is a scheduled, self-prompting cognitive runtime — an "autonomous dream-cycle" system with 109 tables and 60 edge functions [CONFIRMED] — and it is currently, deliberately, off. The most recent migration unscheduled every cron job; the AI router throws a kill-switch error on every call, from a named line in a named file. The manual reports the resulting state exactly: the app loads, auth works, billing works, dashboards render, and no autonomous cognition runs. [CONFIRMED]

Then the sentence that defines this entire volume — the dossier's stated purpose: to preserve the architectural intent, the reactivation policy not yet written, and the strategic position, *so the project can be restarted, sold, licensed, or inherited without losing context.* [OBSERVED] Most dead projects are abandoned; this one is *parked*, with the keys labeled and the manual in the glovebox. Mothballing is a legitimate final state — but only if it is documented as one.

## EXHIBIT B — WHAT A CONTINUITY RECORD ACTUALLY CONTAINS
:source Assets & Continuity — Inheritance & Continuity Plan

The portfolio maintains a standing inheritance protocol — a trigger that hands operational control of the core assets to the founder's successors, with the mechanism itself withheld to the estate channel. [OBSERVED] The instructive part is the specification of what the documentation must cover, because almost none of it is credentials:

**Buyer recognition** — what a legitimate inquiry looks like versus a lowball or a squatter; heuristics, not scripts. **Renewal discipline** — the calendar, the registrar access, the payment fallbacks; a single missed renewal could be a six-figure event. **Patience instructions** — explicit guidance that certain assets are patient capital: hold years, not quarters; do not panic-sell on a soft offer. **Named contacts** — who is warm, who is active, who is merely known. **Sunset triggers** — the conditions under which an asset should be released rather than renewed forever. [OBSERVED]

Passwords let a successor *access* an estate. Judgment — encoded as heuristics, patience rules, and sunset conditions — is what lets them *steward* one. The record exists to transfer the judgment.

[[figure:inheritance-branches]]


## EXHIBIT C — OUTPUT A SUCCESSOR CAN USE
:source CRCKBL — Domain Miner · Assets & Continuity

CRCKBL is the portfolio's most operationally complex system: a lifecycle-aware drop-catching pipeline ingesting zone-file diffs on the order of tens of thousands of deletions a day, enriching survivors with DNS and registry signals, and ranking imminent-drop targets through a tiered alert ladder with two dozen scheduled jobs and a forty-thousand-domain watchlist. [CONFIRMED]

The continuity plan does not pretend a successor will operate that. Instead it specifies a *simplified daily output format* the heirs can act on without running the infrastructure — and notes that even if the engine goes offline entirely, the recent signal history retains value on its own. [OBSERVED] That is the general principle: complex systems owe their successors a simple artifact. Design the heir-readable export first, and the system around it second, because the export is the part with the longer half-life.

## EXHIBIT D — PROVENANCE AS THE PRODUCT SURFACE
:source The Canonical — Owner's Manual · Collapse Registry — Owner's Manual

The portfolio's public catalog replaces spreadsheet-grade listings with an architectural narrative: holdings organized into named namespaces, each with a documented thesis and presented chain of title — the manuals' phrase is moving the asset class up a tier in perceived legitimacy. [INFERRED] Its multi-tenant sibling renders a prepared narrative, a related-asset ladder, and an offer flow for each of forty names from one codebase. [CONFIRMED]

The insight is that inheritance-grade documentation and sales-grade documentation are the same document. Provenance, thesis, classification, prepared narrative — a successor needs exactly what a buyer needs, because both are strangers trying to trust an asset they did not build. Write once, and the record works in every direction: diligence upward, inheritance downward, licensing sideways.

## EXHIBIT E — A FLOOR IS THE MOST INHERITABLE THING YOU OWN
:source The owner's-manual format · BLDBL provenance chains · The Collective Master Library · Volume VII

Inheritance and substrate are the same discipline seen from two ends of a life. A feature set is inherited as a maintenance burden: someone must learn what it does, why it does that, and which customers would notice if it stopped. A floor is inherited as an asset, because its value is written down in the things standing on it and in the provenance each part carries back to where it came from. [CONFIRMED]

That is the practical reason the manuals describe position rather than inventory. "This carries six verticals and one event table" survives a decade of forgetting. A list of screens does not. The heir does not need to reconstruct intent from code — the floor's tenants document it by existing.

It also raises the ceiling on who can inherit. A well-documented substrate can be resumed by a stranger, sold to an operator, contributed to a commons, or handed to a nonprofit as a working system rather than a codebase to rescue. Volume VII argues that this last option is worth designing for on purpose, and Volume VII's own coda is what an inheritance looks like when you arrange it while you are still here.

## PRACTICE

**Adopt a fixed manual format and apply it to everything.** Identity, concept, current state, worth, risks, next actions, canonical summary — the sections matter less than their uniformity. A successor who has read one of your manuals can navigate all of them; that navigability is the asset.

**Write for the reader who was not in the room.** No unexpanded jargon on first use, no context that lives only in your head, no "obviously." The test: could a competent stranger, holding only this document, decide what to do with the thing — resume, sell, license, or sunset — and then begin doing it?

**Park projects; never abandon them.** When work stops, spend one honest session writing the mothball record: exact current state, why it stopped, what reactivation requires, where the kill switches are. The difference between a dead project and a dormant asset is that session.

**Encode judgment, not just access.** Beyond credentials, write the heuristics: what a real opportunity looks like, what patience means per asset, what conditions justify letting something go. Successors inherit your assets by default; your judgment only transfers if you write it down.

**Design the heir-readable export.** For any system only you can operate, define the simple daily artifact a non-operator could act on. If the system dies, the artifact survives; if you die, the artifact is the system.

**Put sunset clauses in writing.** Naming the conditions for release is not pessimism — it is the final act of stewardship, and it frees your successor from the guilt of guessing.
