Narrative Architecture

Why Organizational Context for AI Requires Creation, Not Just Retrieval

A 15-year thesis on steering language models with structured organizational worldview

Scarlet Dame, Founder & CEO, aswritten.ai
Co-authored with Claude Opus 4.6 and aswritten.ai collective memory via MCP

March 2026

The Founding Thesis

In 2011, working with Daniel Shiffman's boid flocking code, a simple observation about emergence planted the seed for everything that followed.[1] Each simulated bird in a murmuration follows three local rules: separation, alignment, cohesion. The simulation is reductionist by design — these rules are a programmer's abstraction, not a biological claim. But the output is not reducible to the inputs. The flock produces emergent behavior that no individual bird intended or could have predicted.

The observation that mattered was not about birds or about simple rules producing complex outcomes — that insight belongs to the field of emergence theory, not to this author. What followed from it is mine: the realization that these rules function as a steering mechanism. Change one rule and the entire emergent pattern shifts. The rules do not describe the flock's behavior; they determine the direction of that behavior. This distinction — between describing and steering — became the foundation of a fifteen-year intellectual journey.[2]

Eight years later, working with GPT-2 in 2019, the connection crystallized. Language models have velocity. Every token prediction carries momentum — direction and magnitude through meaning-space.[3] A prompt does not just provide context; it establishes a vector. The model's output is not a function of its training data alone; it is a function of its training data as steered by the input. Narrative, understood this way, is the directional component of meaning beneath any sequence of statements. It is not what you say. It is the direction your statements point.

GPT-2 demonstrated this mechanically: the same model, given two different narrative frames, would reason differently about identical facts. The steering vector changed. A worldview, expressed as narrative structure, functions as an installable program running on the model's hardware.[4]

The insight became practical at Vouch.io, where I served as Chief Strategist and engineer for two and a half years.[5] The team needed AI to speak with a coherent organizational voice across sales, product, and engineering — not three separate tools with three separate prompts, but one unified perspective that informed how AI reasoned about the organization regardless of which tool was being used. The methodology I developed — narrative architecture — treated organizational narrative as exactly this kind of program. Multiple narratives (go-to-market strategy, engineering principles, product roadmap) composed into a single installable worldview. It worked. But the documents were individually generated — AI/human collaborations in a nascent workflow, custom prompts maintained by a strategist and engineer who understood both the organization and the models.[6]

The question that became aswritten.ai: what if the creation and maintenance of that narrative program could be automated? What if organizational worldview could be version-controlled like code, extracted conversationally from the people who carry it, and compiled into a form any AI agent could query?

The founding thesis, traced across this entire arc: a worldview functions as an installable program for language models. The steering is the product, not a side effect.[7]

The Context Engineering Gap

The AI industry has converged on context engineering as the central infrastructure problem of the current era — how do you get agents to know the right things about your organization, so they can then do the right things?[8] Every team working seriously with AI has developed some answer: RAG pipelines that crawl documentation, knowledge graphs built from Notion pages, Claude.md files that front-load project instructions, OpenAI's Frontier product building a semantic layer for enterprise systems. This convergence validates the problem space and confirms that organizational context for AI is not a niche concern — it is the bottleneck.[9]

But every existing approach shares a structural limitation that becomes visible only when you look at the problem from the creation side rather than the retrieval side. Every one of these systems is a retrieval engine for existing artifacts. They can only access knowledge that has already been written down and stored in a system.[10]

The Creation Gap

The most consequential organizational knowledge — why the architecture was designed this way, what the CEO actually believes about market positioning, the methodology a senior engineer applies instinctively after fifteen years, the unwritten rules that make onboarding take six months — was never documented in the first place.[11] It is not in Notion. It is not in Confluence. It is not in any enterprise system that a semantic layer can index. It lives in people's heads.

This is not a documentation debt problem that can be solved by writing more docs. Tacit expertise resists documentation by nature — it is contextual, relational, and often invisible to the person who holds it. A senior architect does not think of their decision-making framework as "knowledge" that needs to be captured. It is just how they think. The creation gap is structural: the industry has built increasingly sophisticated distribution infrastructure for organizational knowledge while leaving unsolved the fundamental problem of creating that knowledge in the first place — extracting tacit expertise into a form AI systems can work with.

One enterprise chief architect, when shown the extraction concept, summarized the pain precisely: the constant joke at his company was "if only we could get AI to duplicate his brain."[12] When he understood that an AI could interview him conversationally, store the extracted knowledge as versioned memories, and allow anyone else in the organization to query it — his posture shifted from advisory curiosity to purchase interest.[13] The problem was not that his company lacked documentation. The problem was that his twenty-five years of accumulated expertise had never been and likely never would be documented through traditional means.

The Architecture Gap

The second gap is harder to see. Even if you solved creation — even if you extracted everything and documented it perfectly — dumping it into a flat retrieval system creates attention dilution, not steering.[14] The model has more context but no sense of what matters. It cannot distinguish between a settled architectural decision and an idle comment made in a meeting six months ago. It treats a bedrock organizational principle with the same weight as a tentative hypothesis someone mentioned once.

Summary loses key detail. Naive graph solutions are indifferent to what is most important. What matters most in organizational knowledge is not the mundane details of where you have been but the direction you are headed: the vision, the active strategic bets, the decisions that are settled versus those still in debate.

Retrieval gives AI more context. Steering gives AI direction.[15] The difference between the two is the difference between a model that occasionally references your organization's knowledge and one that reasons with your organization's worldview.

aswritten.ai addresses both gaps: creation of undocumented organizational knowledge through conversational extraction, and architectural opinions about how that knowledge should be structured so it steers AI behavior rather than diluting it. And as the following sections describe, it addresses a third gap — making worldview a first-class citizen of engineering infrastructure — that compounds the value of the first two.

Narrative Architecture as Ontology

The ontology — the formal structure of the knowledge graph — is the core of the platform. It is also the piece that is hardest to articulate, because it operates at a level most context engineering approaches do not consider: not what knowledge to store or where to retrieve it, but how to structure it so AI reasons well with it.[16]

Domain Decomposition

We decompose organizational knowledge along seven domains: Opportunity (market, actors, trends), Strategy (positioning, narrative anchor, roadmap), Product (capabilities, personas, solution archetypes), Architecture (system design, technical documentation), Organization (roles, processes, operating cadence), Proof (case studies, outcomes, metrics), and Style (voice, diction, tone, rhetoric).

These domains are not presented as universal laws of organizational reasoning. They are abstractions drawn from consulting experience across multiple organizations, generalized into an ontology that can be extended for specialized domains outside it. The core ontology provides a starting vocabulary; organizations extend it as their collective memory deepens.

The critical property of domain decomposition is that it enables focus without creating silos. Traditional retrieval systems require hard query boundaries — you write a query that defines what you're looking for, and you get exactly that, nothing more. RAG relies on summaries, and summaries drop details in favor of overview. The ontology operates differently: claims, narratives, observations, and actors within each domain are connected through typed relationships — supports, challenges, broader, related — that link across domain boundaries.[17] A developer asking about authentication patterns starts in the Architecture domain but can traverse linked nodes into Strategy (why we chose this approach for our market position) and Organization (who owns the decision). The graph allows the LLM to begin at any detail and traverse with fuzzy boundaries, pulling related information to whatever depth is relevant — like a lens that focuses on one area while keeping the periphery visible.

This is not the behavior of a retrieval engine. Retrieval is siloed by definition — you get what you query for. Graph traversal with fuzzy boundaries is the mechanism that makes the ontology a steering system rather than a search index. This connects directly to the semantic query tools described in the Behaviors section: introspect, annotate, and the nascent lens tool all operate by traversing the graph with focus rather than querying it with hard boundaries.

Conviction Levels

Every claim in the graph carries a conviction level that signals how settled the knowledge is.[18] This is not metadata decoration. Conviction levels change how AI should reason with claims:

Foundation — Bedrock. Career-arc level conviction. The deepest commitments that define who the organization is. Practically immovable. An AI encountering a Foundation claim should treat it as a constraint, not a suggestion.

Boulder — Settled. Requires significant counter-evidence from multiple sources to shift. The decisions that have been made and validated. An AI should reference these confidently and note if new information appears to contradict them.

Stake — Planted position. Someone committed to this view, but it is moveable with evidence. Active hypotheses being tested. An AI should present these as current working assumptions, not settled facts.

Notion — Emerging idea. First mention, casual observation, untested hypothesis. Easily moved. An AI should flag these as early-stage thinking that needs validation.

A retrieval system that treats all knowledge as equally weighted produces AI that cannot distinguish between a settled decision and an idle thought. Conviction levels solve this structurally: the graph itself encodes which knowledge is load-bearing and which is speculative. You get as much as you need, and traversal surfaces what is relevant and important — through linked nodes, not through summary or information overload.

Conviction is orthogonal to review status.[19] A Foundation-level claim can still be provisionally extracted and awaiting human review. Conviction tracks how settled the knowledge is; review tracks whether the extraction has been validated. This separation prevents the review process from becoming a bottleneck for knowledge that is clearly settled.

Provenance as a First-Class Dimension

Every claim in the graph carries not just a conviction level but a full provenance chain across three dimensions.[20]

Source provenance traces the human origin: who contributed this knowledge, in what context (a strategy call, an advisor meeting, a technical review), and from which memory document.[21] When a reader encounters a Boulder-level claim about pricing strategy, they can trace it back to the specific conversation where the decision was made, see the exact words used, and understand the context in which it was established.

Temporal provenance tracks how knowledge evolves. Every memory transaction is a dated delta — a specific change to the graph at a specific point in time.[22] You can trace a claim's lifecycle: when it first entered the graph as a Notion, when it was promoted to Stake after a founder committed to the position, when it reached Boulder after multiple external sources confirmed it.[23] The graph doesn't just know what you know — it knows when you learned it and how your understanding has changed.

Narrative provenance maps where a claim sits in the organization's reasoning structure. A pricing decision isn't an isolated fact. It sits within the Strategy domain, supports the PositioningThesis, was influenced by specific actors, and has downstream dependencies. The graph structure itself is provenance — the relationships between claims tell you why something matters, not just that it exists.[24] This is the mechanism that prevents domain decomposition from creating silos: narrative provenance traces the connections across domains, and any query that follows those connections gets the cross-domain context.

These three dimensions compound. A flat retrieval system can tell you that the company uses seat-based pricing. A provenance-rich worldview can tell you that the shift to seat-based pricing replaced the usage-based model, was validated through beta onboarding, shifted GTM toward top-down sales, and carries Boulder conviction — settled but not immovable.[25]

Working with Collective Memory

The ontology defines what collective memory is. This section describes what you do with it — the behaviors that create, query, evolve, and maintain the organizational worldview.

Compile

The same knowledge graph serves different tasks at different depths through a compilation layer system.[26] This addresses a problem that becomes acute as organizational knowledge grows: token budget constraints. A hundred-thousand-token knowledge graph cannot fit in every prompt. Compilation layers serve exactly the depth of context appropriate for the task:

Worldview (approximately 4–8K tokens): Mission, settled decisions, open questions, actors, domain summaries with provenance. Used for session bootstrap, general queries, and interview context. This is where most interactions begin.

Worldview:{domain} (approximately 15–25K per domain): Full domain expansion with verbatim content, conviction levels, source attribution, and cross-domain relationships. Used for content generation and domain deep-dives. Multiple domains can be compiled together.

Graph:core (approximately 20K tokens): Core concepts and high-value nodes in RDF/TriG format with named graphs per transaction. Used for focused structural analysis when the graph shape matters more than the prose content.

Full graph (approximately 63–100K tokens): Complete RDF graph with all triples and provenance. Used for extraction pipeline work, before/after diffs when evaluating how a new memory changed the worldview, and full structural analysis.

The compilation system means a quick question gets an 8K-token worldview while content generation gets the full domain expansion. The model never wastes token budget on irrelevant context, and the organizational knowledge scales without hitting prompt limits.

Semantic Query

Three tools traverse the graph with focus rather than querying it with hard boundaries:

Introspect starts from the graph and finds gaps. Given a topic, it assesses what's well-documented and what's sparse, then generates questions to fill the gaps. Before recommending or planning, introspect reveals what the organization actually knows versus what it assumes.

Annotate starts from text and finds citations. Given any document, it maps every factual claim against the knowledge graph, producing per-claim citations with full provenance — or flagging claims as uncommitted. Annotate is the verification layer: after generating content, before sharing it externally, you annotate to see what's grounded and what isn't.

Lens (nascent) scopes compilation to a specific perspective or role. Rather than compiling the full worldview and letting the model navigate it, lens produces a focused compilation that foregrounds what matters for a specific consumer — a sales agent, a coding agent, a new hire — while keeping cross-domain connections accessible.

Introspect and annotate are inverted complements. Introspect asks "what's missing?" at the domain level. Annotate asks "what's grounded?" at the claim level. Together with lens, they form the semantic query layer that makes the graph navigable with fuzzy boundaries.

Observe and Extract

Knowledge enters collective memory through observation and extraction. In the current workflow, a consultant leads interviews with senior domain experts — probing for reasoning, methodology, and decision rationale. AI guides and deepens the conversation, surfacing connections to existing knowledge and identifying gaps as they're filled. Between sessions, conversational AI continues extracting knowledge while staff works — at decision points in ongoing conversations and coding sessions, the system identifies knowledge worth capturing.

The extraction pipeline processes memories asynchronously: a memory file commits to the repository, GitHub Actions trigger LLM-based extraction, and the system produces structured transactions representing the knowledge delta. These transactions are validated against the ontology and compiled into the snapshot. The process takes 5–10 minutes per memory.

Remember

Saving a memory is the atomic operation of collective memory. A memory is a rich markdown document — closer to a pull request than a commit. It captures decisions, reasoning, and context with the primary source material the extraction pipeline needs: direct quotes, extended transcript excerpts, the reasoning behind decisions rather than just the decisions themselves.

Memories commit to topic branches (call/{name}, research/{topic}, feature/{name}), never directly to main. The PR process is how the organization decides whether extracted knowledge should become part of the official worldview.

Ingest

Bulk material processing — existing documentation, call transcripts, strategy decks, product specs — enters through ingestion. Unlike the interactive remember workflow, ingestion processes existing artifacts at scale. The extraction pipeline handles both: the same LLM-based extraction runs whether the memory came from a live interview or a batch of uploaded documents.

Notify

When the worldview shifts, relevant people and agents need to know. The notification system monitors worldview changes and alerts stakeholders when new knowledge affects their domain. A sales team member who contributes a customer insight doesn't need to email the product team — the memory they saved triggers extraction, and the product agent's next compilation includes the new knowledge. The watcher agent concept extends this: an AI agent proactively monitors the evolving worldview and notifies relevant people when changes affect their domain.

Review

Extracted knowledge enters the graph as provisional — machine-generated triples that have not yet been validated by a human. Review is the process by which provisional triples become settled knowledge, and it differs fundamentally from traditional document review.

The interaction follows the optometrist model. In a refraction test, the optometrist doesn't ask you to read a prescription — they present lenses and ask "better through A or B?" until your vision converges on clarity. The review system presents extracted knowledge through refractions: overlapping perspectives generated at query time from clusters of related triples. Each refraction exercises the triples from a specific perspective. The reviewer evaluates whether the output through this lens looks right, responds in natural language, and the system translates that feedback into triple modifications. Affected refractions regenerate, and the cycle repeats.

Two orthogonal quality axes govern the process. Conviction — the existing scale from Notion through Stake, Boulder, and Foundation — measures how epistemologically settled a piece of knowledge is. Reviews provide the second axis: each review is an RDF named graph that references the set of triples it evaluated, carrying its own provenance — who reviewed, when, through which lens, what feedback was given. A triple accumulates reviews over time, each from a different perspective or a different reviewer. This is not a binary state transition from "unreviewed" to "reviewed" — it is evidence accumulation. A triple reviewed three times through different lenses carries more confidence than one reviewed once. The compile layer weights by review count, recency, reviewer diversity, and lens coverage.

The process generates knowledge, not just validates it. When a reviewer's feedback triggers triple modifications, those new triples are themselves provisional and queued for the next review pass. The review conversation becomes source material. In practice, iterative review passes with human steering produce more accurate knowledge than any single extraction pass.

Automate

Because worldview lives in git, a worldview change is a GitHub push event.[27] Organizations build agentic automations triggered by GitHub Actions that respond when the worldview shifts. When the CEO changes strategic direction and that decision gets committed to collective memory, downstream agents react: content regenerates, documentation updates, agent prompts adjust, relevant team members receive notifications via MCP.[28]

This is not a context pipeline layered on top of development infrastructure. It is development infrastructure.

Refraction

Refraction replaces the earlier concept of one-shot story generation on every PR. Instead of expensive full-document regeneration, the system runs a coverage check against registered documents — real artifacts that the organization already cares about. It introspects sections to surface what's newly addressable or contradicted by the worldview shift, then re-annotates to show the coverage delta.

The human reviews a shift in grounding, not a shift in prose. A document that was 78% grounded before the PR might be 85% grounded after — specific claims that were uncommitted are now supported, or claims that were supported now contradict newer knowledge. The reviewer sees exactly where the worldview shift touched their document.

Registered documents carry metadata about audience, compile layer, and evaluation criteria — not generation instructions but refraction parameters. Creation of new documents happens collaboratively in interactive sessions (as this document was created). Maintenance of existing documents is automated and async on PR.

MCP and Vendor Agnosticism

The organizational worldview is tool-agnostic by design. Any MCP-compatible client can compile and query collective memory — Claude, Claude Code, GitHub Copilot, and GPT-based Codex have all been validated in production.[29] The first cross-platform validation came from an enterprise beta user whose team chose to run GitHub Copilot CLI with GPT5.2 Codex against the same collective memory Claude uses.

This is a deliberate architectural decision, not an accident of protocol compatibility. The worldview layer sits upstream of any specific AI tool. Downstream distribution platforms — including OpenAI's Frontier — could take an organization's aswritten codebase and deploy thousands of agents with different variations and parameters, all grounded in the same organizational worldview.[30] You author the worldview once, collaboratively. Distribution platforms fan it out.

Multi-Player Coordination Models

Collective memory supports multiple patterns of organizational coordination, each composing from the same atomic operation — a memory committed to a branch, reviewed, and merged.[31]

Solo: A single contributor works with their own collective memory. The simplest path from memory to settled knowledge. The AI coworker compiles, introspects, and extracts in a 1:1 session.

Parallel: Multiple contributors work independently on separate branches. Each person develops their domain of expertise without blocking others. Merges reconcile perspectives.

Hub: One central authority (founder, CTO, lead strategist) reviews and synthesizes contributions from multiple people. The hub role holds the vision; contributors fill in the details.

Teams: Multiple contributors in coordinated domains. Engineering, product, and sales each maintain their domain knowledge, with the compiled worldview ensuring coherence across domains. When sales learns a customer pain point, that memory — once merged — is available to the coding agent without an all-hands meeting.

Salon: A per-memory capability, not a deployment pattern. The reviewers frontmatter on any memory triggers group interview — the system interviews each reviewer about gaps, opinions, and reactions to the proposed knowledge. Their responses become additional memories on the same branch, leading to further interviews until the group converges on shared understanding. This is consensus-as-review: the same primitive (branch, review, merge) applied to group decision-making.[32]

RDF as Substrate

[This section requires collaborative expansion. The current treatment is insufficient for the technical audience.]

The graph uses RDF triples as its data format. RDF triples — subject, predicate, object — mirror the grammatical structure of natural language: noun, verb, noun.[33] LLMs are naturally effective at interpreting and generating them. SPARQL, the formal query language for RDF, is literal and precise.[34] But the compilation layer does not serve SPARQL to the model. It serves a structured markdown rendering of the graph that the LLM navigates associatively, bringing the model's natural language understanding to bear on structured knowledge.

The formal graph provides rigor; the compiled rendering provides accessibility. Both are available depending on the task.

Areas for expansion: federation across multiple repositories, semantic indexing for efficient traversal at scale, embedding-based similarity for connecting concepts across graph boundaries. The DreamDB project (Luke VanderHart) shares the thesis that RDF triples mirror natural language grammar and that LLMs are the natural interface to structured knowledge — aswritten's context architecture lineage traces through that shared work.[35]

ZDR and Data Sovereignty

Collective memory lives in the organization's own git repository — not our servers, not a vendor cloud.[36] LLM extraction runs through the organization's own API keys (BYOK) and a ZDR proxy. Zero Data Retention is available for organizations that require no third-party data exposure.

On-premise deployment is available for regulated environments.[37] The architecture separates deterministic operations (commit, compile, assemble) from LLM operations (extract, introspect, generate).[38] On-prem covers the data path while LLM calls route through approved providers. This separation is not just a deployment convenience — it defines the paywall boundary. Deterministic operations are free and local. LLM operations are the paid layer.

Git-Native Infrastructure

The memory committed in the extraction step lives in a .aswritten/memories/ directory in the organization's git repository.[39] It lives where the code lives.[40] This means it inherits every property that makes git powerful for software: it is collaboratable, branchable[41], reviewable, and diffable.

Telltale regeneration — where registered documents automatically produce updated coverage reports when the worldview changes — is itself a GitHub Action. The diff between old and new refraction results is the signal that tells reviewers whether the worldview shift was captured correctly. If a memory extraction causes a document's coverage to drop or its claims to contradict newer knowledge, the reviewer sees it in the PR.

Content stays aligned with strategy because both derive from the same source of truth.

Evidence

Before/After Comparison

[EVIDENCE NEEDED]

To make the architecture argument concrete, this section requires a side-by-side demonstration:

Example A — Flat RAG: Take a real organizational question (e.g., "Should we price per-seat or usage-based?"). Show the AI response when given 5–10 relevant documents via flat retrieval — no conviction levels, no domain decomposition, no narrative structure.

Example B — Compiled Worldview: Take the same question. Show the AI response when given the compiled worldview with conviction levels, domain decomposition, and narrative architecture.

Production requirements: A real domain with 10+ memories committed. Both responses captured in a single session to control for model variance. Question chosen to demonstrate conviction level impact on reasoning quality.

Multi-Agent Compilation Demonstration

[EVIDENCE NEEDED]

Take a single organizational worldview with sufficient depth across multiple domains. Compile it three ways: worldview:Strategy (for a sales/GTM agent), worldview:Architecture (for a coding agent), worldview:Product (for a PM agent). Show the same underlying knowledge surfacing different aspects.

Then show a single new memory (e.g., a pricing decision) rippling through all three compilations — each agent's context updates to reflect the decision, surfacing only the aspects relevant to their role.

Production requirements: A repo with 10+ memories per domain. Compilation outputs captured and compared side by side.

End-to-End Walkthrough

The full extraction pipeline demonstration — from cold start through expert interview through junior querying the result — is a companion demo video rather than a paper section. The video shows real pipeline artifacts: memory files, extraction transactions, PR diffs, before/after queries.

Principles

Worldview as Code

Git-native means organizational worldview IS code. It is collaboratable, branchable, reviewable, diffable. When the worldview changes, the change is a commit with a diff. When a strategic shift is proposed, it lives on a branch until the team reviews and merges. The same workflows developers use for code govern how the organization evolves its worldview.

This is infrastructure. A worldview change is a GitHub push event. Automations respond. Downstream agents update. Content regenerates. The organizational worldview sits at the core of CI/CD, not alongside it.

The Review Process Creates Knowledge

When a reviewer reads a refraction and notices something wrong — "that's not quite how we think about pricing" — the conversation that follows is itself a knowledge extraction opportunity.[42] The review does not just validate; it deepens. The agent facilitating the review extracts additional knowledge about what is important, how things connect, and what needs consolidation. This is a compounding loop: the more the organization reviews, the richer the worldview becomes.

Contribution-Side Multiplayer

The AI industry already has conversation-side multiplayer — shared team chats where multiple people talk to the same AI. aswritten operates in the opposite direction: multiple people contributing to a single codebase that determines how AI thinks.[43] The collaboration is not in the conversation. It is in the worldview itself.

The coordination is the point. When a sales call produces a memory about customer feedback, that memory — once extracted and merged — is available to the coding agent's next compilation. The developer working on authentication gets the customer context without attending the sales call, without reading a summary email, without an all-hands meeting. The contribution-side multiplayer model coordinates agents through the worldview, not just compiles for them separately.[44]

The Quantified Organization

When organizational narrative is treated as code and every memory produces a structured transaction delta[45], something emerges that no documentation system or knowledge base can provide: a quantitative measure of organizational movement.

Every transaction is a dated, structured change to the knowledge graph. Aggregated over time, these transactions reveal patterns that are otherwise invisible: how fast different domains are evolving, where the organization's attention and energy are flowing, what direction strategic thinking is headed.[46]

Where conviction is shifting — claims moving from Notion to Stake to Boulder across multiple transactions, supported by different sources — represents organizational learning made visible. A pricing hypothesis that started as a casual mention and progressed through validation to a settled decision leaves a traceable arc in the graph.

Where knowledge is stale — domains with no recent transactions, claims that haven't been reinforced or updated[47] — these are organizational blind spots made visible by the absence of activity.

This is the organizational equivalent of version control analytics. Software teams use git statistics to understand development velocity, code health, and contribution patterns. The quantified organization applies the same principle to how an organization thinks — measuring not just what it knows, but how its understanding is evolving, where it's converging, and where it's diverging.

Vision: An AI for Every Task, a Worldview for Every Role (and Society)

The trajectory of agentic AI is clear. Organizations and society will deploy purpose-built AI agents across every function: a coding agent that understands the architecture, a sales agent grounded in positioning and competitive landscape, a customer support agent steeped in product methodology, an onboarding agent that can answer any question a new hire would ask their senior colleague — hundreds of thousands of agents, many more than human peers, hundreds per person per day.[48]

This trajectory creates a coherence problem.[49] Hundreds of specialized agents, each needing organizational context, each potentially reasoning from different or contradictory understandings of the organization. Without a shared source of truth, agent proliferation produces agent fragmentation — the same problem organizations already face with human teams operating from different mental models, now multiplied by the speed and scale of AI.

Collective memory solves this through a single compiled worldview that backs multiple agent roles.[50] The same knowledge graph — the same decisions, the same conviction levels, the same narrative architecture — compiles differently for different consumers. A coding agent gets Architecture expanded with full technical detail. A sales agent gets Strategy and Proof expanded with competitive positioning and customer evidence. Both are grounded in the same organizational truth. Both steer toward the same vision. Neither contradicts the other — because the contribution-side multiplayer model coordinates them through the worldview itself, not through meetings or memos.

[EVIDENCE NEEDED: Multi-Agent Compilation]

To make the vision concrete, this section would benefit from a demonstration of the same worldview compiled for different roles, then a single new memory rippling through all three compilations.

Composability with Distribution Platforms

Because aswritten produces a standard, version-controlled knowledge artifact — a git repository with RDF knowledge graphs — distribution platforms can build on top of it. A platform like OpenAI's Frontier could take an organization's aswritten codebase and deploy thousands of agents with different variations and parameters, all grounded in the same organizational worldview.[51]

You author the worldview once, collaboratively. Distribution platforms fan it out. The MCP protocol provides the interoperability layer. The organizational worldview is tool-agnostic by design.

The Collaboration Model Already Exists

The collaboration model for how AI thinks about your organization does not need to be invented. It is the same model that won for code: branch, review, merge. Propose a strategic shift on a topic branch. The extraction pipeline produces the knowledge delta. Refractions show how the shift would affect every registered document.[52] The team reviews the coverage diff. If they agree, they merge. The organizational worldview evolves, and every agent downstream updates.

This is the future as we see it: an AI for every task, with a worldview for every role, authored collaboratively by the people who know the organization best.[53] Not a thousand separate context engineering projects. One worldview. Many compilations. Every agent steered by the same organizational truth.

Appendix: How This Document Was Verified

This white paper was annotated against aswritten.ai's own collective memory — the same system it describes. Every factual claim was checked against the compiled knowledge graph, producing a coverage score and provenance chain for each supported assertion. The reader is looking at what the product produces.

The Annotation Process

The text of each section was submitted to aswritten.ai's annotate tool, which maps every factual claim against the RDF knowledge graph compiled from the organization's collective memory. For each claim, the tool returns whether it is supported by the graph, and if so: the graph concept it maps to, the conviction level of that concept, the source memory from which it was extracted, and the person who contributed the original knowledge.

Claims marked as supported carry footnote citations throughout this document. Each citation traces provenance across the three dimensions described in the Provenance section — source, temporal, and narrative — demonstrating in practice the system the paper describes.

Claims not supported by the graph fall into predictable categories: rhetorical transitions ("The trajectory of agentic AI is clear"), general knowledge management theory ("Tacit expertise resists documentation by nature"), and new conceptual frameworks being articulated for the first time in this paper (the quantified organization). Unsupported claims are not errors — they are memory creation opportunities that, once committed, would increase coverage scores on re-annotation.

Coverage by Section

[Coverage scores to be updated after revision is annotated]

Overall target: 80%+ claims grounded in collective memory.

What This Demonstrates

The annotation is recursive: this document describes a system for grounding AI-generated content in organizational knowledge, and then uses that same system to verify its own claims. The footnotes trace real memories committed by real people in real conversations — from advisor calls and discovery sessions to architecture reviews and competitive analyses.

When the organizational worldview evolves (a new memory is committed, a conviction level shifts, a new narrative emerges), this document can be regenerated and re-annotated. The coverage scores change to reflect the updated organizational knowledge. Sections with low coverage represent concepts that have been articulated but not yet committed — once they are saved as memories and extracted into the graph, re-annotation would show improved coverage.

This is the core value proposition in action: organizational knowledge that is grounded, traceable, and evolving — not static documents that drift from the truth they were meant to capture.

Citations

[Footnotes to be expanded with full narrative citations following the Source + Conviction + Confidence + Position + Delta format after annotation pass]

  1. Flocking origin (2011): Daniel Shiffman's boid code. Simple rules produce emergent behavior impossible to predict top-down. Foundation conviction. (Scarlet Dame, founding story sessions, 2026-02-15) ↩︎
  2. Founding thesis phrase: narrative as steering vector for language models. Core thesis traced through entire 15-year career arc. Foundation conviction. (Scarlet Dame, founding story through-line, 2026-02-08) ↩︎
  3. Language models have velocity; narrative is the directional vector of meaning beneath statements. Foundation conviction. (Scarlet Dame, architecture decisions, 2026-02-15) ↩︎
  4. A worldview, expressed as narrative structure, functions as an installable program running on model hardware. Foundation conviction. (Scarlet Dame, architecture decisions, 2026-02-15) ↩︎
  5. Narrative architecture at Vouch.io: organizational narrative treated as a program installed onto model hardware. Foundation conviction. (Scarlet Dame, architecture decisions, 2026-02-15) ↩︎
  6. Multiple narratives composed into a single installable worldview. Individually generated documents — AI/human collaborations in a nascent workflow. Foundation conviction. (Scarlet Dame, architecture decisions, 2026-02-15) ↩︎
  7. Core thesis traced through entire career arc. Foundational to aswritten.ai positioning. The steering is the product, not a side effect. Foundation conviction. (Scarlet Dame, multiple sessions spanning 2025–2026) ↩︎
  8. Context engineering named as THE industry problem; used to reframe competitive landscape. Foundation conviction. (Scarlet Dame, competitive positioning reframe, 2026-03-05) ↩︎
  9. Shared organizational context for AI agents validated as enterprise requirement by OpenAI's Frontier investment. Boulder conviction. (Scarlet Dame, Frontier competitive analysis, 2026-02-06) ↩︎
  10. Every retrieval approach is bounded by what has been documented. RAG pipelines, Notion graphs, Frontier — all retrieval engines for existing artifacts. Foundation conviction. (Scarlet Dame, competitive positioning reframe, 2026-03-05) ↩︎
  11. The most consequential organizational knowledge was never written down; all retrieval approaches are bounded by what has been documented. Foundation conviction. (Scarlet Dame, competitive positioning reframe, 2026-03-05) ↩︎
  12. One enterprise chief architect: 25 years of expertise, constant joke about duplicating his brain. Foundation conviction. (Enterprise beta user, advisor feedback call, 2026-01-28) ↩︎
  13. Posture shifted from advisory to purchase interest when he understood AI could interview him and others could query the result. Foundation conviction. (Enterprise beta user, advisor feedback call, 2026-01-28) ↩︎
  14. Flat RAG creates attention dilution; narrative ontology with conviction levels makes knowledge steer. Foundation conviction. (Scarlet Dame, competitive positioning reframe, 2026-03-05) ↩︎
  15. Retrieval gives AI more context. Steering gives AI direction. Foundation conviction. (Scarlet Dame, data model architecture, 2025-11-10) ↩︎
  16. Core architectural thesis: bring LLM associativity to the read layer; treat the graph as a substrate the LLM navigates. Foundation conviction. (Scarlet Dame, context architecture / DreamDB lineage, 2026-02-13) ↩︎
  17. AI memory that is versionable, collaborative, branchable, git-native, and narrative driven. Encodes style and conviction. Foundation conviction. (Scarlet Dame, SIC checkin, 2025-01-29) ↩︎
  18. Conviction framework (Notion → Stake → Boulder → Foundation) tracks how settled organizational knowledge is, with provenance for every shift. Foundation conviction. (Scarlet Dame, YC application planning, 2026-02-05) ↩︎
  19. Conviction is orthogonal to review status. Conviction tracks how settled the knowledge is; review tracks whether the extraction has been validated. Foundation conviction. (Scarlet Dame, story autogen retirement / review convergence, 2026-03-03) ↩︎
  20. Every claim in the graph carries provenance across source, temporal, and narrative dimensions; these three dimensions compound. Boulder conviction. (Scarlet Dame, white paper development session, 2026-03-06) ↩︎
  21. Message = content + author; Provenance = attribution metadata; File = storage details separate from content semantics. Foundation conviction. (Architecture Team, collective memory data model addendum, 2025-01-30) ↩︎
  22. Append-only transaction log. Immutable transaction files with provenance metadata. Foundation conviction. (Scarlet Dame, SIC checkin, 2025-01-29) ↩︎
  23. Conviction lifecycle: Notion (emerging) → Stake (committed) → Boulder (validated) → Foundation (bedrock). Provenance for every shift. Foundation conviction. (Scarlet Dame, YC application planning, 2026-02-05) ↩︎
  24. The ontology IS the steering program. Relationships between claims tell you why something matters, not just that it exists. Foundation conviction. (Scarlet Dame, competitive positioning reframe, 2026-03-05) ↩︎
  25. Pricing shift from usage-based to seat-based ($2.5K/mo per repo). Validated by beta onboarding. Boulder conviction. (Tony Maley, pilot plan pricing simplification, 2026-02-11) ↩︎
  26. Compilation layers serve right depth of context: 4K-token worldview bootstrap to full 100K-token domain expansion. Foundation conviction. (Scarlet Dame, competitive positioning reframe, 2026-03-05) ↩︎
  27. Worldview change is a GitHub push event. Git-native enables CI/CD integration and agentic automations via GitHub Actions and MCP. Foundation conviction. (Scarlet Dame, product taxonomy / GTM mapping, 2026-03-03) ↩︎
  28. Strategic changes cascade automatically to all downstream AI-generated content, analogous to code propagation. Boulder conviction. (Scarlet Dame, Martin Klepsch discovery call, 2026-03-05) ↩︎
  29. MCP-agnostic: GitHub Copilot CLI + GPT5.2 Codex confirmed working. First non-Anthropic MCP integration in production. Boulder conviction. (Enterprise beta user, beta onboarding, 2026-02-09) ↩︎
  30. Frontier could be DOWNSTREAM of aswritten — deploying agents with variations on the same organizational worldview. Boulder conviction. (Scarlet Dame, Frontier competitive analysis, 2026-02-06) ↩︎
  31. Core primitive: a memory committed to a branch. All higher-order behaviors compose from this atomic unit. Boulder conviction. (Scarlet Dame, product use-case taxonomy, 2026-02-18) ↩︎
  32. Salon is not a fifth deployment pattern — it is a per-memory capability. The reviewers frontmatter triggers group interview → consensus → merge. Boulder conviction. (Scarlet Dame, product use-case taxonomy, 2026-02-18) ↩︎
  33. RDF triples mirror natural language grammar: noun, verb, noun. LLMs naturally effective at interpreting and generating them. Foundation conviction. (Scarlet Dame, context architecture / DreamDB lineage, 2026-02-13) ↩︎
  34. SPARQL is literal; LLM reading structural index selects associatively. Foundation conviction. (Scarlet Dame, context architecture / DreamDB lineage, 2026-02-13) ↩︎
  35. Luke VanderHart inspired by Scarlet's 2019 Clojure talk to enter LLMs; his 2024 talk gave Scarlet RDF as the missing data model. Reciprocal collaboration. (Scarlet Dame, multiple sessions) ↩︎
  36. All data in user's own repository, no backend storage. Data sovereignty as trust differentiator. Foundation conviction. (Scarlet Dame, Roger Beaman onboarding, 2026-02-24) ↩︎
  37. Enterprise compliance (GDPR, data sovereignty) confirmed as adoption gate. On-prem deployment required. Boulder conviction. (Enterprise beta user, beta onboarding, 2026-02-09) ↩︎
  38. Deterministic/LLM operation split: commit and compile are free and local; extract and introspect are paid LLM operations. Foundation conviction. (Scarlet Dame, SMS-first collective memory architecture, 2026-02-17) ↩︎
  39. Append-only transaction log in .aswritten directories. Memories live in .aswritten/memories/. Foundation conviction. (Scarlet Dame, SIC checkin, 2025-01-29) ↩︎
  40. Collective memory co-located with code in the same repository. Data sovereignty as trust differentiator. Foundation conviction. (Scarlet Dame, Roger Beaman onboarding, 2026-02-24) ↩︎
  41. Worldview becomes branchable like code; direction changes are explicit, reviewable, testable. Foundation conviction. (Scarlet Dame, AI-native paradigm shift, 2025-01-29) ↩︎
  42. Automatically recompiled refractions serve as sensitive instruments for detecting worldview drift. Foundation conviction. (Scarlet Dame, AI-native paradigm shift, 2025-01-29) ↩︎
  43. Conversation-side vs. contribution-side multi-player AI distinction; aswritten is contribution-side. Foundation conviction. (Scarlet Dame, product taxonomy / GTM mapping, 2026-03-03) ↩︎
  44. Git PR as organizational consensus metaphor: memory = PR, AI-mediated interview = automated review, approval = merge into worldview. Boulder conviction. (Tony Maley, weekly call, 2026-02-19) ↩︎
  45. Organizational narrative treated as code; every memory produces a structured transaction delta. Foundation conviction. (Scarlet Dame, data model architecture, 2025-11-10) ↩︎
  46. Conviction shifts (Notion → Stake → Boulder) across transactions represent organizational learning made visible. Foundation conviction. (Scarlet Dame, YC application planning, 2026-02-05) ↩︎
  47. Conviction decay / spaced repetition as a feature request: claims not reinforced over time should lose conviction weight. Stake conviction. (Martin Kess, data model architecture, 2025-11-10) ↩︎
  48. Collective memory provides shared worldview backing AI agents across development, executive assistance, and content generation. Foundation conviction. (Scarlet Dame, ADR-002, 2024-12-23) ↩︎
  49. Agent proliferation: every employee uses AI daily, accumulating context in siloed instances. Fragmentation multiplied by AI speed and scale. Foundation conviction. (Scarlet Dame, onboarding impossibility hook, 2026-01-07) ↩︎
  50. NOT three separate AI tools for three personas; IS one worldview that unifies how AI assists everyone in the organization. Foundation conviction. (Scarlet Dame, shared worldview CVP, 2025-01) ↩︎
  51. Frontier could deploy agents with variations on the same organizational worldview. Boulder conviction. (Scarlet Dame, Frontier competitive analysis, 2026-02-06) ↩︎
  52. Telltales (refractions) show how worldview shift ripples through every compilation target. Foundation conviction. (Scarlet Dame, AI-native paradigm shift, 2025-01-29) ↩︎
  53. A future where AI systems serve as envoys of human values, goals, and dreams in partnership with humanity. Foundation conviction. (Scarlet Dame, founder reflection, 2025-01-15) ↩︎
The link has been copied!