A Design Case Study
This is a case study of a system being built, not a retrospective of one that succeeded. It contains no outcome claims, because there are no outcomes yet: only design decisions, each registered against the hypotheses of Working Paper 001, and an instrumentation plan that determines what we will be able to honestly claim later.
This framing is deliberate. Most enterprise software case studies are written backwards: outcomes first, then a narrative constructed to explain them. The result is unfalsifiable marketing. A design-phase case study inverts this: commitments are recorded before results exist, so that when results arrive, they can confirm or embarrass the design. Both are useful. Only one is possible if you write the case study afterward.
WP-001 argues that organizations don't primarily suffer from a lack of software: they suffer from a lack of context: the relationships, rationale, and history connecting their fragmented records. It further argues (H3, H4) that context can only accumulate sustainably as a byproduct of work, never as a separate documentation duty, and that this requires the work itself to happen in, or be instrumented into, a system designed to generate context from every action.
Kendriala is the apparatus for testing that claim. The compressed research question:
Can a founder-led organization, running its real operations on software designed for context generation, accumulate a queryable organizational memory that measurably outperforms the fragmented-tools baseline: without anyone doing documentation work?
Every design decision below is downstream of this question.
A research vehicle needs a real organization to run inside: synthetic data cannot test capture incentives, and a demo environment cannot test whether context survives contact with actual client pressure. Kendriala's first host is the author's own software consulting practice (an Indian LLP serving domestic and international clients): small, founder-led, multi-client, and, critically: the researcher bears the full cost of his own design mistakes.
Self-hosting the experiment is a feature, not a limitation: it aligns incentives exactly as the capture taxonomy (WP-001 §4.1) requires, and it means the system's failures are experienced, not surveyed.
The obvious objection: n=1, and a conflicted n=1 at that, is accepted upfront. This phase establishes existence proofs and instrumentation, not generalizable effect sizes. Generalization is a later phase's problem (§8).
The build began not with knowledge graphs or AI, but with the least glamorous workflow available: invoicing. Create an invoice, a client pays it (via Razorpay domestically, Wise for foreign-currency clients: a constraint of building from India, where Stripe is unavailable), the system reflects the payment. That's the entire first slice.
This looks like a strange opening for a context-research platform. It is a deliberate application of three principles:
WP-001 §9.1 identifies adoption as the program's binding risk: byproduct capture requires work happening in-system, but nothing moves into an unproven system. The mitigation is a vertical slice whose value is independent of the context thesis: billing must be worth using even if every context hypothesis fails. Money movement is the one workflow no organization can defer the way it abandons wikis.
An invoice.paid event is unfakeable, timestamped by an external party, and causally entangled with nearly everything upstream: the project that earned it, the milestone that triggered it, the commitment it fulfills, the client relationship it evidences. Payment behavior is also the single most objective input any client-context model will ever get. Starting the event log (Layer 2) with financially ground-truthed events means the context graph grows outward from its most reliable region.
A system asking to become an organization's memory is asking for enormous trust. Handling the organization's money correctly: idempotent webhook processing, reconciliation jobs, exact integer arithmetic, immutable audit logs, is the highest-stakes trust test available, taken first, on purpose. An organizational memory built by people who got payments right reads differently from one built by people who started with the demo-friendly parts.
Each major decision below is a commitment made now, mapped to the WP-001 hypothesis it operationalizes, with the observable that will later judge it. This table is the heart of the case study.
| # | Decision | Operationalizes | What will judge it |
|---|---|---|---|
| D1 | Append-only event log under everything. Every state change emits an immutable domain event (invoice.paid, milestone.completed, decision.recorded) with a standard envelope: actor, org, timestamp, payload. Current state is always reconstructable as a fold over history. |
H1 (event log as ground truth); WP-001 §5.1 | Whether Layer-3 reinterpretation ("apply 2027's ontology to 2025's events") is actually performed and works when the ontology changes |
| D2 | Relational spine, graph semantics, no graph engine. PostgreSQL for everything: entities and typed edges as tables, assertion metadata (source, method, confidence) as columns, recursive CTEs for traversal, pgvector for embeddings. A dedicated graph database is explicitly deferred until measured query latency demands it. | H5; WP-001 §5.2 | Instrumented latency on rationale-chain (C2) and cross-entity synthesis (C4) queries as edge count grows; the decision reverses at measured, pre-stated thresholds: not at aesthetic discomfort |
| D3 | Bitemporal assertions from the first migration. Every context assertion carries valid-time and transaction-time. Implemented as schema discipline in Postgres, not a specialty engine. | WP-001 §5.3 (non-negotiable) | Whether decision-time reconstruction (C3) queries are actually used, or bitemporality proves to be architecture the org never asks questions of: a real possibility worth measuring |
| D4 | Tenant-scoped from row one. Every table carries an organization_id, though exactly one organization exists. |
Generalization path (§8) without rewrite | Cost of onboarding host-organization #2, whenever that happens |
| D5 | Decision and Question as first-class entities, with mandatory input-edges, participants, and supersession chains: arriving in the schema before any AI extraction exists to populate them automatically. |
H2 (minimal core ontology); WP-001 §3.2 | Decision traceability ratio over time; whether manually-recorded decisions in the early phase are recorded at all: an honest early test of solicitation economics |
| D6 | Capture-mode provenance on every assertion. From day one, every piece of context knows whether it was byproduct, instrumented, extracted, solicited, or authored. | H3: this metadata is the experiment | The capture-mode mix curve: H3 predicts byproduct+instrumented dominate; a drift toward authored capture is the pre-registered signature of KM-style failure |
| D7 | AI writes are proposals, never facts. When extraction arrives, model-inferred assertions land at reduced confidence in a review lane; a human confirmation promotes them. No autonomous writes to Layer 3. | WP-001 §3.3, §6.2 (trust boundary); Q6 | Agent-proposal acceptance rate, tracked per edge type: simultaneously a quality metric and the empirical answer to Q6's precision-threshold question |
| D8 | Instrumented capture as first-class, not fallback. Calendar, email metadata, and code events stream in as events alongside native ones: hedging the §9.1 adoption risk by allowing context density to grow over tools that were not replaced. | H4 hedge; WP-001 §4.1 | Boundary-loss measurement: what fraction of relationship context survives federated ingestion vs. native capture: a number WP-001 calls for and no literature provides |
Recorded with equal weight:
The roadmap is usually presented as engineering pragmatism. It is equally a research design: each phase brings a specific hypothesis into testable range:
Billing end-to-end. Research yield: the event log exists and is populated by ground-truthed events (D1 live); trust infrastructure (audit logs, reconciliation) proven at highest stakes. No context claims are testable yet, by design: a system must exist before its memory can.
Projects, milestones, tasks, client portal, support. Research yield: byproduct capture (D6) starts producing its mix curve; Decision entities (D5) meet reality; the first honest read on H4: does the delivery vertical actually hold daily work, or does it leak back to the fragmented baseline?
The C1–C3 retrieval layer over the accumulated graph: state-with-provenance, rationale chains, decision-time reconstruction. Research yield: retrieval fidelity against a curated organizational Q&A set; first data on whether bitemporal queries (D3) get asked.
Meeting → decision extraction, commitment detection, directory-edge inference; all through D7's proposal lane. Research yield: Q6's per-edge-type acceptance thresholds, to our knowledge the first organizational-setting numbers for this.
C4–C6: cross-boundary synthesis, contradiction surfacing, counterfactual advisory. Only reachable if Phases 2–4 survive their falsifiers; explicitly conditional. A demo of C6-style advisory could be built in a week on a synthetic graph; it would prove nothing.
The sequencing encodes an epistemic commitment: capability claims are made only after their preconditions have been measured, not after they have been demoed.
WP-001 §9's program-level threats, localized to this build, in the order they will be encountered:
A commitment device, in the form of the table of contents of the results paper this document obligates:
If section 7 of that paper is empty, this document has failed at its job.
The tenant-scoped foundation (D4) exists so that, conditional on Phases 2–3 surviving, a second and third host organization can be onboarded without rewrite: converting the existence proof into a small-n study, and converting context-debt metrics from internal telemetry into cross-organizational comparables.
That is also the point at which Kendriala stops being only a research vehicle and faces the ordinary questions of a product. Those questions are real but out of scope here; the research reserves the right to outlive any particular commercial form of the implementation: which is precisely why the project and the product carry different names.
| Research program | The Organizational Context Project (WP-001) |
| Reference implementation | Kendriala |
| Host organization | Founder-led software consulting LLP (India); domestic + international clients |
| Current phase | Phase 1: billing vertical (Razorpay domestic / Wise cross-border), event log, audit infrastructure |
| Stack (current) | PostgreSQL (relational spine + pgvector), TypeScript (NestJS / Next.js), event-sourced context substrate over CDC, S3-compatible artifact store |
| Hypotheses under test | H1–H5, Q6–Q9 (registered in WP-001 §8) |
| Pre-registered failure signatures | Authored-capture drift (H3); event-rate flatline with off-system work (H4); traversal latency thresholds (H5) |
| Next publication | Phase-2 adoption and capture-mix findings, positive or negative |