Narrative Architecture

Why Organizational Context for AI Must Be Created

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

Scarlet Dame, Founder & CEO, aswritten.ai
Co-authored with Claude and the Aswritten perspective via MCP. Revised July 2026.

The Founding Thesis

In 2012, 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 and 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.

The pilot customer's 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 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 perspective 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, cite, 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:

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

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

claim: Asserted, still validating. 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: Easily moved. First mention, casual observation, untested hypothesis. 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 principle-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 decision-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 a claim after a founder committed to the position, when it reached decision status 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 perspective 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 decision conviction, settled but not immovable.[25]

Working with the Perspective

The ontology defines what the perspective is. This section describes what you do with it: the behaviors that create, query, evolve, and maintain the organizational perspective.

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 to 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 to 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 to 100K tokens): Complete RDF graph with all triples and provenance. Used for extraction pipeline work, before and after diffs when evaluating how a new memory changed the perspective, 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.

The honest limit lives at the top of that range. Compiling the full graph is where the architecture strains as a perspective grows: past a certain size the full-graph layer no longer fits a single prompt, and the fixed layer boundaries can either over-serve a narrow question or under-serve a broad one. The current read path already moves in the direction the plan is headed: rather than serving a fixed layer, it returns focus-relevant knowledge at witness depth plus a collapsed map that the model expands on demand, so depth is driven by the question rather than by a preset tier. The trajectory is to make the whole read path demand-driven this way, with semantic indexing and embedding-based similarity retrieving the relevant subgraph directly rather than compiling a layer and letting the model navigate it. That indexing work is not yet built.

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.

Cite 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. Cite is the verification layer: after generating content, before sharing it externally, you cite to see what's grounded and what isn't. The tool is named for what the user actually wants. "Annotate" describes a system action; "cite" describes the outcome the user is after, verifying where claims come from.

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 cite are inverted complements. Introspect asks "what's missing?" at the domain level. Cite 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.

Two of these three are shipped and one is not. Introspect and cite run in production today. Lens is nascent: the compile path can already scope by domain, but role-scoped compilation that foregrounds exactly what a given consumer needs is still being built, and until it lands, a coding agent and a sales agent both navigate a broader compilation than either strictly requires. The near-term plan is to make lens a first-class query alongside introspect and cite, so a role is a compilation target rather than a filter the model applies after the fact. (uncommitted: lens's shipped-versus-planned status is described from the current architecture, not committed to the perspective.)

Observe and Extract

Knowledge enters the perspective through observation and extraction. The input is conversations and transcripts: the moments where an organization actually thinks. The default mode is self-serve capture in the user's own AI. You open a chat with the AI you already use about what just happened, and it drafts a memory while you correct its framing in the same conversation. A consultant-led session is one mode among several: a facilitator leads interviews with senior domain experts, probing for reasoning, methodology, and decision rationale, while 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.

Extraction runs synchronously inside the remember tool call. When a memory is saved, the system extracts it into structured transactions representing the knowledge delta, validates them against the ontology, and compiles them into the perspective, all in the same call (approximately two to three minutes). The memory file and its transaction file commit together atomically: if extraction fails, nothing commits, so there are no orphaned files.

Naming what is unsettled here is part of the discipline this paper is meant to demonstrate. The two-to-three-minute synchronous extraction is honest about its cost: it holds the tool call open while an LLM does real work, and that latency is a deliberate trade for atomicity over speed. The near-term plan is to keep extraction synchronous (the atomic commit is worth the wait) while narrowing the window through targeted extraction that processes only the delta a memory introduces rather than recompiling broadly. Bulk ingestion of large document sets remains the case where extraction strains: a batch of long transcripts is slower and less precise than a focused conversational memory, and improving ingestion precision at scale is open work. (uncommitted: the extraction-latency trade and the targeted-extraction plan are described here from the current architecture, not yet committed to the perspective as decisions.)

Remember

Saving a memory is the atomic operation of the perspective. 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 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 perspective.

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 same extraction runs whether the memory came from a live interview or a batch of uploaded documents.

Notify

When the perspective shifts, relevant people and agents need to know. The notification system monitors 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 perspective 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 claim, decision, and principle, 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.

The honest limit is that review is human-in-the-loop by design, and that makes it the manual step in an otherwise automated pipeline. Extraction is machine work; deciding whether extracted knowledge is right is not, and it does not want to be. The plan is not to remove the human but to lower the cost of each pass: refractions that target exactly the triples a memory changed, so a reviewer evaluates a focused delta rather than re-reading a domain, and the evidence-accumulation weighting that lets clearly-settled knowledge move without waiting on review it does not need. The trajectory, longer term, is a perspective settled enough that a deployed agent can review incoming knowledge against it and escalate only the genuinely contested triples to a human, the same principled-escalation contract the deployed agents already run.

Automate

Because the perspective lives in git, a change to it is a GitHub push event.[27] Organizations build agentic automations triggered by GitHub Actions that respond when the perspective shifts. When the CEO changes strategic direction and that decision gets committed to the perspective, 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 perspective shift, then re-cites 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 perspective 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 perspective is tool-agnostic by design. Any MCP-compatible client can compile and query the perspective. 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 GPT-based Codex against the same perspective Claude uses.

This is a deliberate architectural decision, not an accident of protocol compatibility. The perspective 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 perspective.[30] You author the perspective once, collaboratively. Distribution platforms fan it out.

Multi-Player Coordination Models

The perspective 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 perspective. 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 perspective 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 (built by a contracted architect) 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

The perspective 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.

Refraction regeneration, where registered documents automatically produce updated coverage reports when the perspective changes, is itself a GitHub Action. The diff between old and new refraction results is the signal that tells reviewers whether the perspective 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

Planned demonstration

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

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

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

Production requirements: A real domain with 10 or more 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

Planned demonstration

Take a single organizational perspective 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 (for example, 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 or more 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 and after queries.

Principles

Worldview as Code

Git-native means organizational perspective IS code. It is collaboratable, branchable, reviewable, diffable. When the perspective 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 perspective.

This is infrastructure. A perspective change is a GitHub push event. Automations respond. Downstream agents update. Content regenerates. The organizational perspective 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 process: the more the organization reviews, the richer the perspective 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 perspective 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 perspective, 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 claim to decision 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]) 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.

The perspective 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 perspective itself, not through meetings or memos.

Planned demonstration · multi-agent compilation

To make the vision concrete, this section would benefit from a demonstration of the same perspective 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 perspective.[51]

You author the perspective once, collaboratively. Distribution platforms fan it out. The MCP protocol provides the interoperability layer. The organizational perspective 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 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 perspective evolves, and every agent downstream updates.

The vision does not stop at the organization. The same architecture that lets a company install its worldview onto model hardware lets a person do it. A perspective is individually ownable: an installable identity, held in your own repository, that grounds the agents acting in your name. Deployed agents are where present state and long-term vision meet. Today an agent grounded in the perspective can answer a teammate's question with citations back to who decided, and escalate to a human when a question reaches past what the perspective has settled.[54] The trajectory is agents that act on your behalf across more of the work, always carrying the citations their recipients can check, always escalating at the edge of the settled. The perspective as program on model hardware, authored once and deployed many times, is the through-line from the flocking observation to here.

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 perspective. Many compilations. Every agent steered by the same organizational truth.

Appendix: How This Document Was Verified

This white paper was cited against Aswritten's own perspective: the same system it describes. Every factual claim was checked against the compiled knowledge graph, producing a provenance chain for each supported assertion. The reader is looking at what the product produces.

The Cite Process

The text of each section was submitted to the cite tool, which maps every factual claim against the RDF knowledge graph compiled from the organization's perspective. 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 raise grounding on a re-cite.

Re-Verification

The cite tool reports, per claim, whether the perspective grounds it, with what conviction, and from which source. When the organizational perspective evolves (a new memory is committed, a conviction level shifts, a new narrative emerges), this document is re-cited against the updated graph. Claims that were uncommitted become supported once the underlying knowledge is saved; claims that were supported can surface as contradicted when newer knowledge supersedes them. The document does not drift from the perspective it describes, because every regeneration re-checks it against the current graph.

What This Demonstrates

The verification 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.

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 cite tool's source, conviction, and constellation format after a verification pass.]

  1. Flocking origin (2012): Daniel Shiffman's boid code. Simple rules produce emergent behavior impossible to predict top-down. principle 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. principle conviction. (Scarlet Dame, founding story through-line, 2026-02-08) ↩︎
  3. Language models have velocity; narrative is the directional vector of meaning beneath statements. principle conviction. (Scarlet Dame, architecture decisions, 2026-02-15) ↩︎
  4. A worldview, expressed as narrative structure, functions as an installable program running on model hardware. principle conviction. (Scarlet Dame, architecture decisions, 2026-02-15) ↩︎
  5. Narrative architecture at Vouch.io: organizational narrative treated as a program installed onto model hardware. principle conviction. (Scarlet Dame, architecture decisions, 2026-02-15) ↩︎
  6. Multiple narratives composed into a single installable worldview. Individually generated documents, AI and human collaborations in a nascent workflow. principle 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. principle conviction. (Scarlet Dame, multiple sessions spanning 2025 to 2026) ↩︎
  8. Context engineering named as THE industry problem; used to reframe competitive landscape. principle 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. decision 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. principle 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. principle conviction. (Scarlet Dame, competitive positioning reframe, 2026-03-05) ↩︎
  12. The pilot customer's chief architect: 25 years of expertise, constant joke about duplicating his brain. principle conviction. (The pilot customer, 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. principle conviction. (The pilot customer, advisor feedback call, 2026-01-28) ↩︎
  14. Flat RAG creates attention dilution; narrative ontology with conviction levels makes knowledge steer. principle conviction. (Scarlet Dame, competitive positioning reframe, 2026-03-05) ↩︎
  15. Retrieval gives AI more context. Steering gives AI direction. principle 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. principle 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. principle conviction. (Scarlet Dame, SIC checkin, 2025-01-29) ↩︎
  18. Conviction framework (notion to claim to decision to principle) tracks how settled organizational knowledge is, with provenance for every shift. principle 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. principle 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. decision conviction. (Scarlet Dame, white paper development session, 2026-03-06) ↩︎
  21. Message = content + author; Provenance = attribution metadata; File = storage details separate from content semantics. principle conviction. (Architecture Team, perspective data model addendum, 2025-01-30) ↩︎
  22. Append-only transaction log. Immutable transaction files with provenance metadata. principle conviction. (Scarlet Dame, SIC checkin, 2025-01-29) ↩︎
  23. Conviction lifecycle: notion (emerging) to claim (committed) to decision (validated) to principle (bedrock). Provenance for every shift. principle 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. principle conviction. (Scarlet Dame, competitive positioning reframe, 2026-03-05) ↩︎
  25. Pricing shift from usage-based to seat-based, validated by beta onboarding. decision conviction. (An industry advisor, pilot plan pricing simplification, 2026-02-11) ↩︎
  26. Compilation layers serve right depth of context: from an 8K-token worldview bootstrap to a full 100K-token domain expansion. principle conviction. (Scarlet Dame, competitive positioning reframe, 2026-03-05) ↩︎
  27. A perspective change is a GitHub push event. Git-native enables CI/CD integration and agentic automations via GitHub Actions and MCP. principle 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. decision conviction. (An industry advisor, discovery call, 2026-03-05) ↩︎
  29. MCP-agnostic: GitHub Copilot CLI plus GPT-based Codex confirmed working. First non-Anthropic MCP integration in production. decision conviction. (Enterprise beta user, beta onboarding, 2026-02-09) ↩︎
  30. Frontier could be DOWNSTREAM of aswritten, deploying agents with variations on the same organizational perspective. decision 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. decision 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. decision 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. principle conviction. (Scarlet Dame, context architecture / DreamDB lineage, 2026-02-13) ↩︎
  34. SPARQL is literal; LLM reading structural index selects associatively. principle conviction. (Scarlet Dame, context architecture / DreamDB lineage, 2026-02-13) ↩︎
  35. DreamDB (built by a contracted architect) shares the thesis that RDF triples mirror natural language grammar and that LLMs are the natural interface to structured knowledge. Reciprocal collaboration. (Scarlet Dame, multiple sessions) ↩︎
  36. All data in user's own repository, no backend storage. Data sovereignty as trust differentiator. principle conviction. (Scarlet Dame, customer onboarding, 2026-02-24) ↩︎
  37. Enterprise compliance (GDPR, data sovereignty) confirmed as adoption gate. On-prem deployment required. decision 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. principle conviction. (Scarlet Dame, SMS-first perspective architecture, 2026-02-17) ↩︎
  39. Append-only transaction log in .aswritten directories. Memories live in .aswritten/memories/. principle conviction. (Scarlet Dame, SIC checkin, 2025-01-29) ↩︎
  40. Perspective co-located with code in the same repository. Data sovereignty as trust differentiator. principle conviction. (Scarlet Dame, customer onboarding, 2026-02-24) ↩︎
  41. Perspective becomes branchable like code; direction changes are explicit, reviewable, testable. principle conviction. (Scarlet Dame, AI-native paradigm shift, 2025-01-29) ↩︎
  42. Automatically recompiled refractions serve as sensitive instruments for detecting perspective drift. principle conviction. (Scarlet Dame, AI-native paradigm shift, 2025-01-29) ↩︎
  43. Conversation-side vs. contribution-side multi-player AI distinction; aswritten is contribution-side. principle 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 the perspective. decision conviction. (An industry advisor, weekly call, 2026-02-19) ↩︎
  45. Organizational narrative treated as code; every memory produces a structured transaction delta. principle conviction. (Scarlet Dame, data model architecture, 2025-11-10) ↩︎
  46. Conviction shifts (notion to claim to decision) across transactions represent organizational learning made visible. principle 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. claim conviction. (An industry advisor, data model architecture, 2025-11-10) ↩︎
  48. The perspective provides a shared worldview backing AI agents across development, executive assistance, and content generation. principle 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. principle conviction. (Scarlet Dame, onboarding impossibility hook, 2026-01-07) ↩︎
  50. NOT three separate AI tools for three personas; IS one perspective that unifies how AI assists everyone in the organization. principle conviction. (Scarlet Dame, shared worldview CVP, 2025-01) ↩︎
  51. Frontier could deploy agents with variations on the same organizational perspective. decision conviction. (Scarlet Dame, Frontier competitive analysis, 2026-02-06) ↩︎
  52. Refractions show how a perspective shift ripples through every compilation target. principle 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. principle conviction. (Scarlet Dame, founder reflection, 2025-01-15) ↩︎
  54. Perspective-grounded agents escalate on four types: situation not covered, principle contradiction, claim tension, and ungrounded recipient input. This principled escalation is the trust contract that makes delegation possible; the agent escalates in the same channel where the work is happening. decision conviction. (Scarlet Dame, goal-directed agents session, 2026-04-08) ↩︎