Organizational Context:
A Technical Research Survey

1. The Problem, Stated Precisely

1.1 What current systems store vs. what organizations know

A typical 30-person software business runs on 8–15 systems of record: CRM, project management, documentation, chat, email, calendar, billing, support desk, file storage, design tools, code hosting. Each is a well-designed store of entities within its own domain: the CRM knows about deals, the tracker knows about tickets, the wiki knows about pages.

What no system stores is the connective tissue:

• The deal in the CRM was won partly because of a technical spike documented in a ticket that no longer links to it.
• The architecture decision in the wiki was made in a meeting whose recording expired, in response to an incident whose postmortem lives in a different tool, under pressure from a client whose complaint thread is in email.
• The "obvious" reason a feature was cut exists only in the memory of two employees, one of whom has resigned.

Formally: systems of record capture entities and (some) state transitions, but rarely capture relationships across system boundaries, almost never capture rationale (the why of a state transition), and structurally cannot capture counterfactuals (options considered and rejected: often the most valuable context for future decisions, and the first thing lost).

1.2 Context loss as a structural property, not a discipline failure

The standard diagnosis is behavioral: "people don't document." The standard remedies: wikis, documentation sprints, knowledge bases, have failed consistently enough, for long enough, that a structural explanation is warranted:

1. Documentation is a separate act from work. Any capture mechanism that requires work about the work competes with the work itself and loses. This is an incentive-compatibility problem, not a tooling problem, and it predicts precisely the observed failure mode: wikis are best populated during slow periods and most stale exactly when the organization is changing fastest, when context is being generated at the highest rate.
2. CRUD semantics destroy history by design. An UPDATE is an erasure. A row that says status = 'churned' does not know it once said status = 'expansion_candidate', or when, or why the assessment changed. The dominant persistence pattern of enterprise software is destructive overwrite of state, which is the exact opposite of memory.
3. Foreign keys stop at system boundaries. Within one product, referential integrity is enforced by the database. Across products, "integration" means webhook-driven data copying: which duplicates entities while discarding relationships, because the receiving system has no schema slot for "this ticket exists because of that email."
4. Rationale has no home. No mainstream enterprise schema has a first-class Decision entity with links to its inputs, alternatives, participants, and downstream consequences. Architecture Decision Records (ADRs) are the closest widely-adopted practice, and they are (a) confined to engineering, (b) manually authored, and (c) prose: searchable but not traversable.

1.3 Why LLMs convert this from annoyance to binding constraint

Before capable reasoning models, context loss was tolerable because the only consumers of context were humans, who compensate through hallway conversation, oral tradition, and institutional memory embodied in tenured staff. LLMs change the economics in both directions:

• Demand side: a reasoning system that could answer "why did we structure the Acme contract this way, and does that reasoning still apply to the Initech deal?" is now buildable: if the reasoning trace exists somewhere machine-readable. The model is no longer the bottleneck; its input is. This is the core claim of the "context engineering" reframing that displaced "prompt engineering" during 2024–2025: the hard problem is assembling the right context, not phrasing the request.
• Supply side: LLMs make previously-uneconomical capture economical. Structured extraction from meetings, threads, and documents: entity mention detection, decision extraction, relationship inference, was a hard NLP research problem in 2015 and is a well-behaved engineering problem now. The automatic generation of context as a byproduct of work, which §1.2(1) establishes as the only incentive-compatible capture mode, became technically feasible only recently.

The conjunction is the research opportunity: the first moment in which context is simultaneously consumable by machines and capturable by machines.

2. Theoretical Foundations

The problem is not new; the organizational-theory literature studied it for decades under different names. Three bodies of work matter most, and each contributes a design constraint.

2.1 Organizational memory (Walsh & Ungson, 1991)

The canonical framework defines organizational memory as stored information from an organization's history that can be brought to bear on present decisions, and locates it in five internal "retention bins": individuals, culture, transformations (procedures/systems), structures (roles), and ecology (physical setting), plus external archives. Two implications survive translation to 2026:

• Memory is distributed and heterogeneous by nature. Any system claiming to be organizational memory is actually claiming to be a sufficiently good index and integration layer over memory that remains partly in humans. Design constraint: the goal is not total capture (impossible) but maximal linkage: knowing that a decision was made and who carries its rationale is valuable even when the rationale itself was never externalized.
• Retrieval, not retention, is the historical failure point. Organizations retain enormous amounts; they fail to bring retained information to bear at decision time. Design constraint: capture architecture is worthless without a retrieval architecture evaluated at the moment of decision, which is why §6 treats retrieval as co-equal with storage.

2.2 Transactive memory systems (Wegner, 1987)

Wegner's studies of couples and small groups showed that groups develop directory knowledge: knowing who knows what, that lets the group function as a memory system larger than any member. Organizational translation: much of what looks like "organizational knowledge" is actually metaknowledge about the location of knowledge, and it degrades catastrophically with turnover because directories are held in heads.

Design constraint: an organizational context system should explicitly model person↔knowledge-domain edges ("Priya is the authority on the payment reconciliation logic") as first-class, automatically-inferable relationships: inferable from authorship, review activity, meeting participation, and ticket resolution patterns, because the directory is cheaper to capture than the knowledge and captures much of its routing value.

2.3 The knowledge-management failure record

The 1995–2010 KM wave (expert systems, corporate wikis, "knowledge repositories") is the graveyard this project must explain its difference from. The consistent post-mortem findings: capture required unpaid extra work (violating §1.2(1)); repositories decayed because nothing enforced freshness; and stored knowledge lacked the context needed to judge its current applicability: a document from 2019 doesn't announce which of its assumptions have since been invalidated.

Design constraints derived: (a) capture must be a byproduct of work or it will not happen; (b) every context assertion needs temporal validity semantics (§5.3), not just a creation timestamp; (c) staleness must be computable: the system should be able to answer "what stored context has been contradicted by later events?"

2.4 Conway's law as a context corollary

Conway's observation: system designs mirror the communication structures of the organizations that produce them, has an underappreciated converse for this project: the communication structure is itself recoverable from the artifacts. Who talks to whom, through which artifacts, about which entities, is latent in the event stream of any organization operating digitally. An organizational context system is, among other things, a continuously-updated empirical map of the organization's real (rather than org-chart) structure: which is one of the concrete "organizational intelligence" outputs that traditional BI cannot produce (§7).

3. A Formal Working Definition of Organizational Context

We propose defining organizational context as a typed, bitemporal, provenance-attributed property graph constructed over an immutable event log, with the following components. This definition is a hypothesis (H1 in §8), not a settled result.

3.1 The four-layer model

Layer 4: DERIVED CONTEXT      inferred relationships, summaries, embeddings,
         (recomputable)        directory edges, staleness flags, metrics
─────────────────────────────────────────────────────────────────────────────
Layer 3: SEMANTIC GRAPH       typed entities + typed relationships + decisions,
         (curated + inferred)  with bitemporal validity and provenance
─────────────────────────────────────────────────────────────────────────────
Layer 2: EVENT LOG            immutable, append-only record of everything
         (ground truth)        that happened, who did what, when, in what
─────────────────────────────────────────────────────────────────────────────
Layer 1: ARTIFACTS            documents, messages, recordings, code, files , 
         (raw material)        stored, addressable, never the primary index

The critical architectural commitments encoded here:

• The event log is the ground truth; the graph is a view. Layers 3–4 must be recomputable from Layers 1–2. This is the event-sourcing insight (§5.1) applied to context: if the semantic model turns out wrong, and in a research project it will, repeatedly: a rebuild must be possible without data loss. Systems that make the graph primary and the events incidental cannot revise their ontology; systems that make events primary can.
• Artifacts are referenced, not primary. A meeting recording is Layer 1; "Decision D-2041 was made in meeting M-118 by persons P-3, P-7, superseding D-1990" is Layer 3. Retrieval that returns artifacts ("here are 6 documents mentioning Acme") is search; retrieval that returns Layer-3 structures with Layer-1 citations is context.

3.2 The entity/relationship type system (minimal viable ontology)

Rather than adopting a heavyweight ontology, we hypothesize (H2) that a small core is sufficient and that domain-specific extension should be data-driven:

Entity types (core): Person, Organization, Project, Artifact, Event (meeting/incident/milestone), Decision, Commitment (promises made: to clients, between teams, with due-state), Question (open unknowns; the inverse of knowledge), Process (recurring way-of-working).

Relationship types (core): participated_in, authored, references, caused_by, resulted_in, supersedes, depends_on, responsible_for, knows_about (the Wegner directory edge, §2.2), contradicts.

Two deliberately unusual inclusions:

• Decision as first-class, with mandatory slots for inputs (edges to the entities/artifacts that informed it), participants, alternatives considered (even as free text), and supersession chain. The supersession chain is what makes "why is the system like this?" answerable as graph traversal rather than archaeology.
• Question as first-class. Organizations do not only know things; they knowingly don't know things, and losing track of open questions is a distinct and expensive failure mode ("didn't we decide to revisit this after the pilot?"). A Question entity with raised_in, blocks, and answered_by edges makes organizational uncertainty queryable.

3.3 Assertions, not facts

Every edge in Layer 3 is an assertion with: source (which event/extraction produced it), method (human-stated | system-observed | model-inferred), confidence, and bitemporal validity (§5.3). This matters because Layer 3 will be substantially model-populated, and model-inferred edges must be (a) distinguishable, (b) contestable, and (c) bulk-revocable when an extraction model is found to have a systematic error. A context layer that cannot distinguish "the CEO said this" from "GPT-class model inferred this from a Slack thread" will be distrusted, and distrust of memory is organizationally worse than absence of memory.

4. The Capture Problem

Capture is the make-or-break subsystem, per §1.2(1) and §2.3. We taxonomize capture modes by their marginal cost to the user:

4.1 Capture taxonomy

The strategic claim (H3): a system must maximize the first three modes and use the fourth surgically; any design leaning on the fifth reproduces the KM failure record. Solicited capture is the underexplored middle: its unit economics work only when the system knows when to ask (at natural boundaries: project close, decision detection, offboarding) and asks questions whose answers have high option value. Offboarding interviews are the canonical missed opportunity: the single highest-context-density event in an employee lifecycle, almost universally captured as HR formality rather than knowledge transfer.

4.2 The extraction pipeline, technically

For the Extracted mode, the pipeline decomposes into now-standard components with organizationally-specific twists:

1. Entity mention detection + linking (entity resolution). The hard version is not detecting "Acme" but resolving that "Acme," "the Acme deal," "that pharma client," and "Rajesh's account" corefer: across documents, months, and authors. Entity resolution over organizational text is materially easier than open-domain ER because the candidate set is small (the org's own entity registry) and closed-world assumptions mostly hold, but temporal drift (the same name meaning different things in different eras: "the platform" pre- and post-rewrite) requires resolution to be time-conditioned.
2. Decision/commitment extraction. Detecting that a decision occurred in a transcript, extracting its content, participants, and stated rationale. Precision matters more than recall here (§3.3's trust argument): a missed decision is the status quo; a hallucinated decision attributed to a named person is a trust catastrophe. Design implication: extracted Decision entities should launch in a proposed state requiring one-click confirmation by a participant: which doubles as a solicited-capture touchpoint for the "alternatives considered" slot.
3. Relationship inference. knows_about edges from behavioral evidence (authorship density, review patterns, answer patterns); caused_by edges from temporal + referential proximity; contradicts edges from semantic comparison of assertions over the same entity. Each inferred edge type needs its own precision evaluation and its own confidence calibration; treating inference as one undifferentiated capability is how systems earn distrust.
4. Consent and scope boundaries. Extraction over communications is surveillance if scoped wrong. The defensible line, we hypothesize, is: extract from work artifacts in shared spaces (meetings with recording consent, project channels, documents), never from private channels/DMs; make every extraction attributable and visible to its subjects; and give individuals contestation rights over edges about them (knows_about especially, since it drives routing). This is not only ethics: a system perceived as surveillance will be routed around, destroying capture coverage, i.e., the ethical failure is a data-quality failure.

4.3 The adoption wedge: the honest version

Byproduct capture (the zero-cost, high-reliability mode) requires that work happen in the system. This is the same all-in-one adoption problem that has defeated most "operating system for your business" products: the value of the context layer is downstream of adoption breadth, but adoption of an unproven system is downstream of demonstrated value. The KM literature's lesson plus the product graveyard's lesson combine into the sharpest critique of this entire research program, treated fully in §9.1. The mitigation hypothesis (H4): begin with one workflow whose native output is already high-context-density per event (client delivery: projects, decisions, commitments, meetings, billing), prove context value within that vertical slice, and expand via the Instrumented mode rather than demanding migration.

5. Data Architecture

5.1 Event sourcing as the memory substrate

Event sourcing: persisting an append-only log of domain events as the system of record, with current state as a derived projection, is the storage discipline whose semantics match organizational memory: nothing is overwritten, every state is explainable as a fold over history, and new projections (new "ways of understanding the past") can be built retroactively. For a context system this last property is decisive: retroactive reinterpretation is a core requirement, because the ontology (§3.2) will evolve, and only an event-sourced substrate lets 2027's ontology be applied to 2025's events.

Costs, honestly: event sourcing raises engineering complexity (versioning of event schemas, projection rebuild operations, eventual consistency between log and views) and is routinely over-applied. The position here is narrow: the context substrate should be event-sourced; ordinary transactional workflows within the product can remain CRUD with change-data-capture feeding the log, which delivers most of the memory benefit at a fraction of the complexity. Purism about event sourcing everywhere is an architecture-astronautics failure mode this project should explicitly avoid.

5.2 Graph representation: property graph over a relational spine

The recurring question: "relational or graph database?", is mostly a false dichotomy at organizational scale. The realistic data volumes for the target segment (10–200 person organizations; order of 10⁵–10⁷ events/year, 10⁴–10⁶ entities, 10⁵–10⁷ edges) are comfortably within PostgreSQL range, and the operational cost of a second database engine is the single most common self-inflicted wound in graph-flavored startups. The working position (H5):

• Relational spine: entities and assertions as tables (with the assertion metadata of §3.3 as columns), edges as a typed adjacency table, recursive CTEs for bounded traversals, pgvector for embedding search: one operational system.
• Graph semantics, not necessarily a graph engine. The property-graph model (typed nodes/edges with attributes) is adopted at the schema level; a dedicated graph engine (Neo4j-class, or an RDF store with SPARQL) is justified only if measured query patterns demand unbounded-depth traversal or graph algorithms (centrality, community detection) at interactive latency. This is an empirical question the reference implementation should instrument, not presuppose.
• RDF/OWL considered and deprioritized: formal ontology stacks buy inferencing and interoperability at severe ergonomic cost, and organizational context's schema volatility (§5.1) fights OWL's design center. Property-graph pragmatism with an explicit assertion model captures the needed semantics.

5.3 Bitemporality: the non-negotiable

The single most important: and most commonly omitted, temporal property: every assertion carries two independent time dimensions:

• Valid time: when the assertion was true in the world ("Priya was responsible for reconciliation from 2025-03 to 2026-01").
• Transaction time: when the system learned/recorded it (possibly months later, possibly revised).

Bitemporality is what makes three essential query classes possible: "what was true as of date X" (state reconstruction), "what did we believe as of date X" (decision audit: judging past decisions by information available at the time, not by hindsight), and "what did we learn between X and Y" (context diff). Datomic and XTDB demonstrate practical bitemporal engines; in a Postgres spine it is implementable as four timestamp columns plus disciplined query patterns. The AI-relevance is direct: an agent asked "should we revisit the pricing decision?" must reason over what was believed when the decision was made versus what is believed now: the delta is the answer: and unitemporal stores cannot express the question.

5.4 The current-state / historical-context distinction

LLM-facing retrieval must sharply distinguish state ("the Acme contract is worth ₹40L, active, renewal in March") from context ("it was priced 20% below rate card because of the 2025 delivery slip; the discount rationale was recorded as one-time"). State questions want the latest valid assertions only; context questions want supersession chains and rationale. Collapsing these: the default behavior of naive RAG over a document dump, produces the classic failure of confidently answering current-state questions from stale documents. Architecturally this means retrieval carries a temporal mode parameter, and Layer-4 summaries are always generated per-mode, never as mode-blind blobs.

6. The Reasoning Layer: Retrieval and Agent Memory

6.1 Why vanilla RAG is insufficient, specifically

Retrieval-augmented generation over an organizational document dump fails on four measurable dimensions, each with a known partial remedy:

1. Semantic similarity ≠ contextual relevance. The document most similar to "why did we lose the Initech renewal" is probably the Initech contract; the relevant context is a support-ticket cluster, a missed commitment, and a pricing decision: related by causation, not vocabulary. Remedy: graph-constrained retrieval, vector search to find entry points, then typed-edge traversal (caused_by, supersedes, contradicts) to assemble the causal neighborhood.
2. Multi-hop questions. "Which current commitments were made by people who have since left?" is a three-hop typed query trivially expressible over Layer 3 and essentially inexpressible as embedding search. Remedy: text-to-graph-query as a retrieval tool alongside vector search, with the LLM planning tool use.
3. Temporality-blindness. Chunk stores don't know which chunk supersedes which. Remedy: §5.3–5.4; retrieval defaults to latest-valid state, exposes history on request.
4. No provenance. RAG citations point at chunks; organizational trust requires assertions traceable to events and people (§3.3). Remedy: retrieval returns assertions-with-provenance; generation is instructed to cite assertion IDs.

The composite retrieval architecture is therefore hybrid by construction: SQL (state), vector (semantic entry), graph traversal (causal/structural), temporal filters (mode), fused per-query by a planning step.

6.2 Agent memory: read policy and write policy

Recent agent-memory systems (MemGPT-lineage hierarchical memory; Zep/Graphiti-style temporal knowledge-graph memory) establish the pattern of an LLM agent with structured external memory it both reads and writes. The organizational setting adds two constraints mostly absent from personal-assistant memory research:

• Read policy = access control. The context graph spans the organization; no individual (and no agent acting for one) should retrieve beyond their scope. Retrieval must be permission-filtered at the assertion level, which interacts nastily with derived summaries (a Layer-4 community summary may leak assertions its reader couldn't access individually: the inference-control problem from statistical databases, reborn). This is an open problem (Q7, §8), not a solved checkbox.
• Write policy = the trust boundary. Agents will propose Layer-3 writes (extracted decisions, inferred edges). The §3.3/§4.2 discipline applies with force: agent writes land as low-confidence proposals in a review lane, and the acceptance rate of agent proposals becomes both a quality metric and a trust dial the organization controls.

6.3 What "reasoning over an organization" concretely enables

To keep the program falsifiable, the target capability set should be enumerated as query classes, roughly ordered by difficulty:

• C1: State with provenance: "What's the status of X and how do we know?"
• C2: Rationale reconstruction: "Why is X the way it is?" (supersession-chain traversal)
• C3: Decision-time reconstruction: "What did we know when we decided Y?" (bitemporal)
• C4: Cross-boundary synthesis: "What patterns connect our three churned clients?" (graph + generation)
• C5: Contradiction surfacing: "What current beliefs conflict with recent events?" (proactive)
• C6: Counterfactual advisory: "We're structuring the Initech deal: what from Acme applies?" (analogy over context)

C1–C3 are engineering over §5's architecture. C4–C6 are research. A reference implementation that reliably delivers C1–C3 with honest provenance would already exceed deployed enterprise AI norms; C5 is where "organizational intelligence" stops being a metaphor.

7. Measurement: Context Debt and Organizational Intelligence Metrics

If context is an asset, its absence must be quantifiable, or the program is unfalsifiable and unsellable in equal measure. We propose context debt as the gap between the context an organization generated and the context it retained in queryable form, and define candidate metrics: each computable from the architecture above, each a hypothesis to validate against outcomes:

Two research-grade cautions. First, several of these are Goodhart-able (decision traceability ratio invites ritual rationale-stuffing); metric design must anticipate gaming, e.g., by weighting traceability by later retrieval of the rationale. Second, the causal claim that context metrics predict organizational outcomes (onboarding speed, decision reversal rates, client retention) is exactly that: a claim, testable only longitudinally, and the reference implementation should be instrumented for that longitudinal study from day one rather than retrofitted.

8. Open Research Questions and the Hypothesis Register

Consolidating the hypotheses embedded above, as the register the Kendriala implementation exists to test:

9. Counterarguments This Program Must Survive

A research framing earns credibility by stating what would kill it. In descending order of lethality:

9.1 The adoption wedge may be a contradiction, not a challenge

The claim "context emerges as a byproduct of work happening in the system" contains its own hardest precondition: work must happen in the system. Every prior "one system for the whole business": with very few exceptions, each of which took a decade, under-delivered against exactly this, and the failure is structural: best-of-breed tools win each individual workflow, so the integrated suite is worse at everything except integration, and integration value arrives only after adoption breadth that the per-workflow inferiority prevents. H4's wedge strategy is a mitigation, not a refutation; the honest statement is that this program's binding risk is product adoption, not data architecture, and any presentation of the research that hides this behind graph-theory novelty is self-deception. The instrumented-capture mode (§4.1) is the serious hedge: if the context layer can reach useful density federating over existing tools rather than replacing them, the wedge problem relaxes substantially: at the cost of boundary losses that should themselves be measured.

9.2 Surveillance gravity

A system that models who knows what, who decided what, and who committed to what is one management-request away from becoming a performance-monitoring apparatus, whereupon (§4.2(4)) participants sanitize their behavior and the capture stream degrades into theater. The consent architecture is a necessary but not sufficient defense; the sufficient defense, if one exists, is probably structural: e.g., contractual/product guarantees that individual-level context is not exposed in evaluative aggregations. Whether such guarantees survive customer pressure is an open organizational-design question the research should treat as in-scope, not as legal fine print.

9.3 Context rot and maintenance economics

Graphs decay. Inferred edges go stale; entity registries drift; yesterday's ontology misfits tomorrow's business. The KM wave died partly of maintenance costs, and a context graph is more maintainable than a wiki only if staleness detection (§5.3, contradicts edges, context half-life metrics) genuinely automates the gardening. If curation labor scales linearly with graph size, the system reproduces the wiki failure with better data structures.

9.4 "The model will eat this"

The bear case from the frontier: context windows grow toward 10⁷–10⁸ tokens, retrieval-free ingestion of "the whole company" becomes feasible, and the elaborate graph machinery is obsoleted by brute-force attention over raw artifacts. Partial rebuttals: (a) the event log and artifacts are the input either way: Layers 1–2 remain necessary; (b) provenance, access control, and bitemporal semantics are requirements no context window satisfies; (c) cost/latency economics of full-corpus attention remain punitive at organizational refresh rates. But the design implication is real and should be embraced: invest most heavily in the layers that survive every model-capability scenario (1–2, plus the assertion/provenance discipline), and treat Layer-4 machinery as replaceable. A research program is healthier when it knows which of its components are load-bearing across futures.

10. Relationship to the Reference Implementation

Kendriala operationalizes this program as a working system for founder-led organizations, beginning from the client-delivery vertical (H4) on an event-sourced relational spine (H5) with the §3 four-layer model. Its architectural decisions are registered as hypotheses (H1–H5), its extraction quality and capture-mode mix are instrumented as first-class metrics (§7), and its roadmap is sequenced by query class (C1→C6). Findings: including negative results, particularly around H3/H4 where the prior literature predicts failure, will be published as subsequent working papers in this series.