Most client intakes produce a written summary and a folder of files. Ours produces a typed knowledge graph. The intake conversation is the corpus; myKG runs a two-pass pipeline over it; the output is a locked-schema graph of the client's world (people, orgs, goals, intents, preferences, risk tolerance, resources). The summary comes out of the graph, not the other way around.
The base schema does the load-bearing work. Thirteen locked classes (Person, Persona, Community, Market, Context, Goal, Intent, Preference, RiskTolerance, Resource, Organization, Relationship, Artifact) form a backbone every client intake extends without renaming. Pass 1 induces a client-specific ontology on top of that backbone. Pass 2 extracts confidence-scored typed instances against the locked schema. The result is a graph shaped like every other client's graph, populated with this client's actual world.
The graph is not the deliverable. It is the substrate everything else in the engagement stands on. The rubric can query it. The report can walk it. Agents working across the engagement can read the same nodes and mean the same thing. That is what earlier intakes could not deliver. A conversation ended and became notes; the notes did not compose with anything.
How to apply it. Treat the discovery call as pass one of an ontology induction. Design intake questions to elicit typed content the base schema can hold. Score confidence explicitly. Let the summary write itself out of the graph, and hand the graph forward as the primary artifact. The next post shows what the graph starts to buy when it composes with the REA value-flow ontology.