The aspirational document for Solution Intelligence — why it exists, what it claims, who it asks something of, and what it expects to leave behind. The structured reference (components, roles, deliverables, build path) lives in docs/OVERVIEW.md. The wire-format specifications live in MODEL.md. The numbered obligations live in REQUIREMENTS.md. This file is none of those. This file is the story.
Status: Left-bookend, 2026-05-19.
License (intended): Apache 2.0 (internal first, open-source eventually).
First instantiations: DLA Stores (C# → ServiceNow migration), chainblocks (prose-only smoke test through the prose-doc template).
There is a moment, every so often, when a profession discovers that the work it has been doing one project at a time has a shape. The shape was always there. The practitioners felt its outline in their hands without naming it, repeated its motions across engagements without articulating its grammar, and lived inside it for years before anyone wrote it down.
When the moment arrives and the shape is finally named, three things happen at once. The first is recognition — yes, that is what we have been doing all along. The second is acceleration — once the pattern is named, it can be taught, and the next generation does not have to relearn it from scratch. The third is the harder one: the naming begins to fix what was, until that point, intuitive and adaptive; the practice calcifies; new generations inherit the practice without the experience that originally justified it. This is the cost of any methodology, and it is the cost worth paying for the long stretches when the methodology is right.
Software has been through this before. Lean and the Toyota Production System gave us flow and pull and the discipline of treating manufacturing as a system rather than a heroism. Agile gave us iteration and customer-presence and the discipline of admitting that requirements are discovered, not declared. The Phoenix Project — perhaps the closest analog to what is being attempted here — narrated DevOps into existence by walking us through one fictional team's collapse and recovery, embedding the practices in a story we could feel rather than a manual we had to memorize. Each of those methodologies was right for its moment. Each was eventually superseded. Each left a substrate of practice behind that the next thing inherited.
We are in such a moment now. And it is a particular moment, distinct from the ones that produced Lean and Agile and DevOps. AI agents are entering the systems-analysis loop for the first time. They will read codebases, classify artifacts, propose graph structure, draft compliance mappings, and produce findings — at scales no human team could match. Some of what they produce will be brilliant. Some of it will be confident, fluent hallucination presented in the same register as the brilliant work. The practices we establish now, while the field is still being shaped, will determine whether the next decade of AI-augmented solution intelligence is built on provenance and trust or on plausible-sounding output at industrial scale.
This is the moment Solution Intelligence is being set down for. Not as the final word. As the next right step.
Picture a senior solutions architect — call her by her role rather than a name, because the role is the point. She has stood up six versions of the same factory in the last two years. AuditInsight against DLA's procurement chain. ALMSS for the Air Force's COBOL legacy. DLA Stores' C# to ServiceNow. PIEE's Java analysis. Eden Township's ordinance graph. A few smaller proofs. Different customers, different artifacts, different questions — and the same arc every time. Ingest the heterogeneous bundle. Make sense of it. Produce the deliverable. Move on.
By the third engagement she could see the shape. By the sixth it was undeniable. The work was repeating, but nothing she built was accumulating. Each engagement was fresh effort against the same shape, and when the deliverable shipped and the team disbanded, the framework she had hand-built was either retired with the project or carried forward in her own head — useful to her, useless to anyone else, gone the day she was on the next thing.
She does not think this is inevitable. She also does not yet know how to stop. The customer expectations are bespoke-shaped. The tooling does not exist. The senior-practitioner identity she has built her career on is precisely the identity of someone who reads the codebase carefully, sits with the SMEs, writes the deliverable in her own voice — and she is not sure that identity survives the methodology she suspects is needed. She suspects she is about to be asked to give up some of the artistry to ship the practice. She is not sure that trade is one she wants to make.
This is the wound the methodology has to address: repetition without accumulation, and the fear that productizing the practice will hollow out the practice. Every commitment in Solution Intelligence has to earn its way past that fear.
There is a voice that lives next to the practitioner's. It belongs to the senior colleague she respects most, the one who has been doing this work the longest, and it argues — in good faith, with experience behind it — that the methodology is the wrong move. It is worth hearing in full, because the methodology is only as strong as its answer to it.
The work is artisanal. It does not productize. Every engagement is genuinely different — different customer, different artifacts, different questions, different stakes — and a framework that pretends otherwise will deliver mediocre output at scale precisely because it has to be general. The senior practitioner who reads the codebase carefully, sits with the SMEs for two weeks, and writes the deliverable in their own voice will always produce better intelligence than a templated pipeline, because the practitioner is doing pattern-matching the framework cannot do. You are not capturing the practice in your methodology; you are codifying the part of the practice that is mechanical, and the part that is mechanical was already not the part that mattered.
Worse: the AI agents you are worried about will, within a few years, do the mechanical parts of this work fluently. They will not need your epistemic-class schema or your single-writer GraphLoader or your audit ledger. They will produce findings in natural language, justify them with citations to the source artifacts, and adapt to each engagement's particulars in ways your framework cannot. The discipline you are trying to encode now is a layer of friction that your successors will route around — politely or otherwise — when the agentic tooling becomes good enough. You are not setting down the practices the next decade will inherit. You are setting down the practices the next decade will obsolete.
Cultivation across generations is a beautiful idea. It also assumes that the next generation will care enough about your model to extend it rather than rebuild a fresher one from the same primary sources, with newer tools, faster. Your audit-ledger-backed SIG sounds defensible. So did COBOL.
That is the voice. It is not a fantasy objection. Senior practitioners hold it. AI vendors marketing competing approaches will articulate it in their own terms over the coming years. The methodology that does not have an answer to it ready will not survive its first encounter with a thoughtful skeptic.
The answer Solution Intelligence offers — and earns, slowly, through everything that follows — is not that the voice is wrong. The voice is partly right, and the methodology says so out loud. Much of the practice is artisanal in ways that resist framework-ization. AI will obsolete much of what we build. Cultivation is a wager, not a guarantee. But there is a residue the voice misses, and the residue is what the methodology is for: some practices are exactly what the next decade needs, and will be inherited even when the surrounding tooling is replaced. The doctrine of provenance. The discipline of epistemic honesty. The insistence that every action is attributable to a named person. The treatment of the model as a cultivated artifact rather than a one-time deliverable.
These are the inheritances. The specific Studio container layout is not. The particular Docker compose stack is not. Even the choice of PolyGraph over Neo4j is not. The methodology is the discipline; the tooling is the scaffolding the discipline is being practiced inside of right now. Build the AI agents. Supersede our tooling. Route around our specific machinery when something better exists. Just inherit the discipline. That is what is being set down. Everything else is scaffolding.
When you strip Solution Intelligence to its kernel, it is simple:
Collect the facts about something. Build a traceable model from those facts. Produce defensible artifacts from the model. Cultivate the model so it is transferable to the next generation.
That is the whole methodology in two breaths. The expansion follows from the kernel and is forced by honesty.
Collect the facts means recognizing that facts arrive in different epistemic registers — source code is hard truth, design documents are aspiration, RFPs are binding constraint, logs are evidence, SME notes are tribal knowledge, industry standards are reference material. The methodology cannot survive flattening these into a single bag of "documents"; the discipline begins with refusing that flattening.
Build a traceable model means the model is queryable, every node and edge carries provenance back to the input it derives from, and every change to the model is attributable to a specific human or agent acting on someone's behalf. The model is a graph because graphs are how heterogeneous things relate; the model is typed because typing is how heterogeneity stays legible; the model is provenanced because provenance is how the model stays trustworthy across the years that matter.
Produce defensible artifacts means the reports, matrices, atlases, and roadmaps are not standalone documents. They are queries against the model, citing the model, regeneratable from the model, defensible because the model is defensible. A reader of an SI deliverable can click any claim and walk back through the cited graph nodes to the source artifacts they derive from. The deliverable is not the asset. The model is the asset. The deliverable is how the model gets used.
Cultivate the model means a Solution Intelligence Graph is not a deliverable that exists at a point in time and then ages. It is a living artifact-of-record. Three years after the engagement that produced it, an Inspector General can audit it and an analyst can extend it. Five years after, a successor team can pick it up and continue the modernization. Ten years after, an AI agent that has not yet been designed will be able to query it — because the schema is portable, the provenance is intact, the audit trail proves nothing has been altered since, and the doctrine of epistemic honesty was held all the way through. The methodology that produced the graph is also the methodology that maintains it. Cultivation is part of the practice, not an afterthought.
The model is the asset. The artifacts are how the model gets used. Cultivation is what keeps the model alive across generations. That is Solution Intelligence in one paragraph, and everything that follows is in service of it.
There is a claim hiding inside the kernel that deserves to be drawn out, because it is the claim that distinguishes Solution Intelligence from every prior attempt at this kind of work.
A Solution Intelligence Graph is substrate-independent. It describes the solution, not the implementation. The procurement function an agency operates is a solution; the COBOL transaction system it ran on in 1985 was one implementation; the Java enterprise stack it ran on in 2005 was another; the microservices and ServiceNow workflows of today are the current one; whatever lands in the 2040s will be the next. Across all of those substrates, the solution itself — what gets tracked, what gets approved, what gets audited, what obligations bind, what evidence accumulates, what tribal knowledge the operators carry — has stayed remarkably stable. The implementations turn over every fifteen or twenty years. The solution mostly does not.
A SIG built honestly captures the solution at the level where it is stable. The ground-truth nodes — the ones derived from today's source code — will age out as the substrate turns over. The constraint nodes, the evidence nodes, the tribal-knowledge nodes, the reference-pattern nodes, the aspirational-intent nodes will not. They describe the solution. As each new implementation lands, the SIG absorbs it as a new layer of ground truth bound by INTENDS_TO_IMPLEMENT and DRIFTS_FROM edges to the stable spine. The model does not get rebuilt. The model gets cultivated forward across the paradigm shift.
This kind of artifact has been valuable for a long time. Organizations have been recreating partial, local versions of it for decades — in architecture binders that decayed in filing cabinets, in requirements traces nobody could query, in compliance matrices maintained by hand in spreadsheets, in the gray-haired engineer's institutional memory that retired with him. The need has been there since computing began handling complex obligations. The supply has not.
What makes a real SIG newly possible now is that today's technologies — graph databases, hash-chained ledgers for tamper-evident audit, portable serialization formats that survive infrastructure changes, AI-assisted ingestion at the scale heterogeneous customer artifacts actually arrive in, cheap storage that lasts decades, distribution mechanisms like git that outlive the organizations that adopted them — let us capture a SIG as a neat bundle of bits and bytes. A graph export. A DSL stream. An audit ledger. A signed manifest. The whole cultivated artifact, portable enough to clone, archive, hand off, and query decades later without depending on the people or the tooling that produced it. The methodology has been waiting for the substrate to catch up. Now it has.
Imagine if the COBOL transaction systems built in the 1970s had been accompanied by SIGs — not architecture binders, but queryable, attributable, portable graph artifacts of the actual solution. The Java migrations of the early 2000s would have started with the SIG rather than with archeology against the running code. The ServiceNow migrations of today would not be expensive rediscovery missions. The cost of every paradigm transition in software has been dominated by the cost of re-learning what the system was supposed to do. A cultivated SIG eliminates that cost, or at least collapses it to something much smaller than it has historically been. We have not had this before because the substrate to capture it did not exist. We have it now.
The practical horizon Solution Intelligence is built for is not five years. It is two or three turnovers of the implementation substrate — a SIG built well today should still be useful in the 2050s, and the paradigm that hosts the solution then will not be a paradigm we can name from here. That is the design center. Everything in the doctrine that follows is in service of it.
This substrate-independence claim has a direct consequence for the schema itself. If the model is to outlive the paradigm that hosted its first implementation, the vocabulary of the model has to be honest about which of its labels are timeless and which are paradigm-bound. The schema is therefore three-tiered. At the top is a solution-universal vocabulary — constraint, evidence, intended behavior, architectural decision, tribal knowledge, reference pattern, finding, risk — that applies to any kind of solution in any era. Beneath that sits a solution-domain vocabulary that is timeless within a kind of solution — for the kind of solutions we have built and will build first, business automation, the domain vocabulary includes form, process, role, organization, approval, workflow, document, agreement, business rule, transaction, account, ledger, policy. A 1935 procurement office had forms and approvals and roles; a 2026 ServiceNow workflow has forms and approvals and roles; whatever lands in 2055 will have them too. The labels are stable. Beneath the domain layer sits an implementation-paradigm vocabulary, era-namespaced, that names what the current substrate happens to call its units of behavior and structure — for the present substrate, cs_2026.function, cs_2026.endpoint, cs_2026.class, cs_2026.source_file and so on. When the paradigm turns over, a new cs_2055.* layer lands beside the existing one, both bound to the same domain and universal nodes by intent and drift edges, both legible to a future analyst who never used either substrate.
This is why what kind of solution is this? is one of the first questions an SI engagement asks, before any artifact is ingested. The answer selects which solution-domain vocabulary applies. The v0.1 framework ships with business automation as its named domain, because that is the kind of solution we have spent two decades doing and the kind every precedent engagement has been. Other domains — manufacturing and control systems, clinical and healthcare, infrastructure and engineering, research and experimentation — are architected for but not built yet. They are additions to the framework, not breaks to it. The spine is stable; the domains accumulate; the paradigm namespaces accumulate. That is the shape that lets a SIG outlive any one of them.
The doctrine that emerges from this is not a list of commitments asserted from above. It is the negotiated treaty between the practitioner's worry — that productizing will hollow out the practice — and the methodology's claim — that some disciplines must be set down or be lost when AI scales the work. Read each of the commitments below in that register. Every one of them is the resolution of an argument that was had honestly before the commitment was made.
Honor the epistemic status of every input. The artisanal voice winning a specific argument against the let's-just-ship-faster voice. Code is not design is not contract is not evidence is not tribal knowledge. The framework encodes the distinction; parsers respect it; the Graph preserves it; deliverables surface the conflicts (intent vs reality, contract vs implementation) rather than smoothing them away. This is the doctrinal anchor. Everything else is downstream of it.
One project, one container set; no cross-pollution. Each engagement runs in its own isolated stack. Customer data does not mix — not because the framework is fragile, but because confidentiality and classification matter, and the discipline of strict isolation is the only honest version of multi-customer work. Templates and parsers are shared across the framework; running data is not. There will be no Solution Intelligence SaaS in which everyone's models share a database.
The model is the durable artifact; everything else is rebuildable. The harder negotiation. The senior practitioner wanted the deliverable to be the artifact — the polished report in the customer's hands, the slide deck on the sponsor's desk. The methodology insists the model is the artifact and the deliverable is a query against it. This is the negotiation that makes cultivation possible at all. If the deliverable is the artifact, you do the work once and it ages. If the model is the artifact, you cultivate it across generations and the deliverables follow.
Every action is attributable to a named person. The productize voice conceding to a deep artisanal value. SI does not record "the system did X." It records "alice@example.com promoted this finding at this time while holding the Operator role on this project." Every entry in the audit trail names a human. This is what makes the cultivated model survivable across the years that matter — because when an Inspector General audits a claim five years from now, the chain ends at a person, not at a process.
chainblocks audits the significant events. Not all events; the significant ones — ingestions, parses, promotions, classifications, overrides, exports. The audit ledger is small enough to verify in one command and complete enough to defend any claim in any deliverable. It is the substrate of trust that lets the rest of the methodology hold up across generations. We did not invent it because it was novel; we invented it because the methodology would not be honest without it.
Automate as much as possible; intervene where judgment matters. The explicit boundary between the mechanical and the artisanal. SI does not try to win the argument about which is which. It places the boundary in tooling: parsers run automatically, analysts chain automatically, classifications propose automatically, conflicts surface automatically — and where judgment matters, the operator (a real person, with a name, holding a documented role) intervenes through Studio's developer UI. Automation never substitutes for judgment, but it eliminates the toil that would otherwise crowd judgment out.
Templates are libraries of practice; instances are configuration. The middle path. A new engagement does not write code. It selects a template (cobol-modernization, csharp-to-servicenow, transaction-analysis, prose-doc) and configures the inputs. New parsers and analysts become new templates after they have been proven on a real engagement. The framework grows by accretion, not by per-engagement forking. The artisan's particulars are honored in configuration; the recurring shape is honored in the templates.
The Window respects its audience and the role of its viewer. Studio is the workshop — dense, raw, action-oriented, for operators. Window is the gallery — read-mostly, polished, narrative-shaped, for analysts and reviewers and customers. They are not the same product in two skins. They are two different products built from the same model. Role-based view scoping is enforced at the API boundary, not just hidden in the UI: a Customer cannot URL-hack their way to the BB substrate.
Multi-user from day one. The productize voice acknowledging that artisanal work has always been collaborative when it mattered most. Solution Intelligence is built for engagements with two-to-many participants. Single-user mode is a degenerate case, not the design center. Identity, authorization, concurrent operators, role-based view scoping, and per-user attribution in the audit trail are all v0.1 surface area. We do not ship "the auth pass" later.
Cultivate the model; do not just produce it. The commitment the original draft of this document did not name and could not have named. A Solution Intelligence Graph is a living artifact, not a delivered document. Extensions are first-class. Re-querying is first-class. Handing the model to a successor team is first-class. Three years from now, the model should still be readable and still be extendable. The methodology that produces the graph is the methodology that cultivates it.
The schema is three-tiered: solution-universal, solution-domain, implementation-paradigm. The commitment that makes substrate-independence operative. The solution-universal vocabulary (constraint, evidence, intent, finding, and the rest) is the timeless spine; adding to it is a major event. The solution-domain vocabularies (ba.* for business automation, with other domains added as the framework expands) are timeless within their domain; additions are routine. The implementation-paradigm vocabularies (cs_<era>.*) name the current substrate's units of code and structure; they age out as substrates turn over, with new era namespaces landing beside the old. Every engagement declares its solution domain as one of its first acts. The schema's job is to keep the spine clean while the layers accumulate.
Open-source-grade quality from day one. Solution Intelligence is internal first, but designed for open-source release. Every component is built to the bar set by the GitHub Published Projects playbook. If we cannot ship a component publicly, we should not ship it internally either. The discipline of public-quality work is what keeps the methodology honest with itself.
That is the doctrine. Twelve commitments, each one a treaty between artisan and methodology, each one a place where a real tension was named and resolved. The methodology's strength is not that the commitments are correct in isolation. Its strength is that both voices were heard before the treaty was signed.
What does this look like when an engagement actually happens?
It begins with a customer handing over a bundle of artifacts — a tarball of code, a folder of design documents, a few RFPs, a year of transaction logs, maybe a few hours of recorded SME interviews. An Owner instantiates a Solution Intelligence project from a template, and the project becomes a self-contained Docker compose stack: a Studio for the operators to work in, a Graph for the durable model, a Window for analysts and reviewers and customers to read from, and an Identity service that makes every action attributable to a real person.
The Owner grants roles. Operators ingest. Parsers read each input artifact and emit a typed proposal stream, classified by epistemic kind. The GraphLoader validates, promotes, and writes — and emits an audit event for every promotion, every rejection, every conflict surfaced. Analysts run, propose findings, post them to the Blackboard substrate inside Studio; operators arbitrate the proposals that require judgment. The Window shows the deliverables emerging in close to real time, scoped to each viewer's role: a Reviewer sees the full model, a Customer sees only the curated subset, an Operator sees the workshop. Findings get cited back to source. Conflicts get surfaced rather than smoothed. Decisions get attributed.
At some point the engagement reaches a milestone: the first version of the deliverable suite is ready. GraphReader produces the standard artifacts into an output bucket structured as a git-initialized folder tree. The customer can clone it. Sponsors review it. Auditors trace any cited finding back to its underlying graph node, back to its source artifact, back to the audit event that records who promoted it.
And then — and this is where the methodology earns its keep against the colleague's objection — the engagement does not end when the deliverables ship. The model continues. New inputs arrive: runtime evidence accumulates, the design document gets updated, a new compliance requirement lands. The graph extends; the deliverables regenerate; the audit ledger grows. Six months later, a successor team picks up where the original engagement left off; the graph carries everything they need, and everything they propose to add is attributable to them, distinguished cleanly from what came before. Three years later, an Inspector General audits a single claim in the original deliverable and walks back through the model and the ledger to verify it. Ten years later — well, that is the part we are designing for and cannot yet describe in detail, because the tools of ten years from now have not been built yet.
What we can promise is that the model, if cultivated, will still be readable. The schema is portable. The provenance is intact. The audit trail is verifiable. That is the legacy claim, and it is the claim the practitioner — the one who has built six bespoke factories and is on the verge of the seventh — gets to make for the first time in her career.
She gives up some artistry. She does not give up the practice. What she gains is the thing she had been working toward without naming it: work that accumulates.
A small honesty section, because aspirational documents owe their reader honesty.
Twelve months from now, the following statements should all be true, or the methodology has not delivered what it claims:
- A new customer engagement can be instantiated as an SI project in under a day, not a month.
- All six of the precedent projects (AuditInsight, ALMSS, DLA Stores, PIEE, Eden Township, chainblocks) are re-instantiated as SI projects on the framework. The one-off pipelines are retired.
- Three or more new engagements have been delivered using SI; the cost-per-engagement has dropped by 5×+.
- A government adopter has reviewed the audit trail of an SI deliverable via
chainblocks-verifyand accepted it as evidence. - The Studio Blackboard substrate has been proven by use and is ready (or already extracted) as its own library.
And the methodology refuses certain things explicitly. It is not a SaaS. It is not a single shared graph across all customers. It is not a general-purpose graph database. It is not a standalone blackboard product, not yet. It is not an LLM-only system; LLMs handle the residue of ambiguity, not the bulk of the work. It does not pronounce verdicts on the customer's behalf. It does not replace the capture team. Each of these refusals is a place where the methodology chose discipline over scope, and each of them is a place where the methodology will be tempted to relax the discipline. The temptations should be resisted. The full reference list of non-goals is in docs/OVERVIEW.md; this document only carries the principle: scope is earned by discipline, not declared by ambition.
We are taking the initial strides. They are strides, not the destination. Solution Intelligence is the methodology this generation needs, designed honestly enough to be transcended by the next.
We are not building the final tool. We are not pretending this is the last word on AI-era systems analysis, or even on graph-shaped solution intelligence. We are establishing the practice from which the future evolutions will inherit their discipline. The provenance. The attribution. The epistemic honesty. The cultivation. The treatment of the model as an artifact-of-record that outlives the paradigm that hosted its first implementation. The insistence that every action ends at a named person.
These are the inheritances. Whatever supersedes Solution Intelligence — and something will, eventually, because methodologies have lifespans — will discard whatever specific components we built (the Studio, the Window, the particular shape of the pipeline) and find better ones. That is the right outcome. The methodology was never the point. The discipline was the point. And the SIGs that are cultivated under this discipline will survive their tooling, because that is what they were designed to do from the day they were named.
The most we can do is leave the practice in a shape the next generation can inherit, and leave the artifacts in a shape that the generation after that can still read. That is what we are doing. That is what this document is for. Solution Intelligence is the kernel of truth from which the future evolutions will flow — for as long as the kernel is honest enough to be worth flowing from.
🖇️
This story is told inside software because software is where its authors live. The implementations cited are COBOL, Java, ServiceNow, JavaScript, Python. The practitioner has built six bespoke factories for software engagements. The legitimate objection is voiced from inside the software-modernization world. That is the story's heartland and it should not be apologized for.
But the methodology is larger than its heartland. The kernel — collect the facts about something, build a traceable model from those facts, produce defensible artifacts from the model, cultivate the model so it is transferable to the next generation — does not name software anywhere. It names facts, model, artifacts, cultivation. And the solution-universal vocabulary — constraint, evidence, intended behavior, architectural decision, tribal knowledge, reference pattern, finding, risk — describes any structured human endeavor with stakeholders and obligations, not just any software system.
Which means Solution Intelligence is the methodology, not just for modernizing legacy code, but for any work where a heterogeneous bundle of artifacts must be made into a traceable, defensible, transferable model. A few examples illuminate the range.
A financial audit. The work begins with a tarball of inputs no different in shape from a software engagement: the entity's general ledger and source documents (ground truth), the auditor's planning memorandum and risk assessment (aspirational intent), the binding regulations such as GAAP, IFRS, or PCAOB Auditing Standards (constraint), the year's transaction logs and reconciliations (evidence), the partner's notes on what the previous engagement found (tribal knowledge), and the industry's reference frameworks for materiality and internal control (reference pattern). The model an audit builds today lives in spreadsheets and working papers that are discarded or archived after the opinion is signed. A Solution Intelligence Graph would let the next audit start where the last one ended — the constraint nodes, the evidence nodes, the tribal annotations all still queryable, the previous opinion's findings cited and traceable. Across audits of the same entity over decades, the cost of re-learning collapses.
A building's construction and life. A capital project arrives with the same six classes of artifact. The architect's drawings and specifications (aspirational intent). The building code, ADA requirements, fire-suppression standards, energy codes, the contract itself (constraint). The structural calculations, the soil report, the load tests, the change orders, the punch list (evidence). The site superintendent's notes on which subcontractor's work is reliable and which always needs a second look (tribal knowledge). The structural patterns the building is an instance of — moment frames, braced cores, post-tensioned slabs (reference pattern). The as-built record (ground truth). A Solution Intelligence Graph that cultivates across the building's life — design, construction, occupancy, renovation, decommission — would carry forty years of the building's known truth in a form that survives turnover of every contractor, every owner, every facilities management software platform.
A clinical trial. The protocol document (intent). The relevant regulations: FDA 21 CFR Part 11, ICH-GCP, IRB approvals (constraint). The case report forms, adverse event logs, statistical analyses, monitoring visit reports (evidence). The investigator's notes on which sites are reliable and which protocols always confuse the staff (tribal knowledge). The therapeutic-area patterns the trial is an instance of (reference pattern). The actual protocol implementation — the eCRF system, the EDC configuration (ground truth, paradigm-bound). A SIG for the trial would let the sponsor's next study cite its predecessors with full provenance; would let an FDA inspector trace any finding back to its source; would let the next generation of trial-management software inherit the model rather than rebuild it.
A complex family vacation. Smaller, more personal, but the shape is identical. The kids' school calendar, the in-laws' availability, the spouse's work commitments, the budget (constraint). The trip's intent — a beach week, a cultural tour, a national parks loop (aspirational intent). The hotel confirmations, the flight bookings, the receipts, the trip journal (evidence). The family's history of what worked on prior trips and what didn't — which kid hates car days, which restaurant chain is reliable in every state (tribal knowledge). The travel-industry reference patterns — typical lengths, cancellation policies, transportation modes (reference pattern). The itinerary as it actually unfolds (ground truth). A SIG would let next year's trip planning start with this year's model, extended, rather than from scratch. Multiply across decades of family life and the trivial example becomes substantial.
The pattern repeats wherever structured work with stakeholders and obligations happens. Litigation, mergers and acquisitions, military mission planning, scientific research programs, urban planning, hospital operations, congregational governance, election administration. The kinds of solutions are many; the shape of the methodology that produces and cultivates them is one.
SI's heartland will remain software because that is what its authors do. But the methodology was named in a software workshop and meant for a much larger room. The graph schema's universal tier exists because the universal tier is real — not as an aspiration of generality but as an honest claim about what the methodology actually is. The software examples in this story are the worked examples we can stand behind today. The other examples are waiting for someone whose heartland is theirs to bring SI into.
What we set down has to be inheritable across kinds, not just across paradigms. That is the claim this appendix exists to make explicit.
This story was named on 2026-05-18 by Bill Fredricks (the architect) with Bhai (the personal twin), the morning after the pattern was named for the first time. The naming came from Bill: Solution Intelligence as the overarching project, Studio as the workbench, Blackboard as the substrate inside, Graph as the durable artifact, Window as the consumer-facing UI. SI/I (Identity) was added the same morning when Bill stipulated that SI must be multi-user from day one; the 5-role model and bangauth-plus-OIDC default fell out of that conversation. The runtime pipeline diagram landed late-morning and clarified that Studio = the Blackboard (substrate + developer UI), collapsing SI/BB from a top-level component into Studio's internal substrate. The component count went from five to four. The same revision introduced the DSL as a first-class intermediate artifact and S3 buckets at both ends of the pipeline.
This rewrite of the Story — from structured specification overview to story-shaped aspirational document — happened on 2026-05-19. The catalyst was Bill's observation that the original Story mixed perspectives uncomfortably and asked us to think about whether the document could be a real story. We worked through it together: docs/STORY-CONCEPT.md as a first narrative draft, docs/STORY-MIND.md as Dramatica-style analytical scaffolding (Overall Story, Main Character, Influence Character, Subjective), and then this document — the story-shaped Story informed by both. The previous structured version is preserved at docs/STORY-V0-ORIGINAL.md for reference; the reference material it carried (components in detail, role matrix table, deliverable suite table, sibling projects, build path) moved to docs/OVERVIEW.md.
Subsequent documents (REQUIREMENTS.md, MODEL.md, docs/PIPELINE.md, docs/USE-CASES.md, docs/FEATURES.md, docs/OVERVIEW.md) refine this story into specifications and reference. Code is built against the specifications. If the code drifts from this story, the story is updated (with a changelog entry) or the code is corrected — never both silently. The story governs what we are for; the specifications govern what we build; the code governs what we ship.