Orchestra and verifiable knowledge from meetings
31 October 2026
Orchestra turns meeting material into structured knowledge with a traceable origin. Its central engineering problem is preserving the relationship between a claim, the exact source version behind it, and the decision to treat it as a current fact. This case study compares requirements, architecture decision records and implementation through a static source review dated 31 October 2026.
The problem and the boundary
A transcript preserves a conversation. Answering questions about current commitments, decisions and changes requires more structure. When meetings are processed in sequence, an incorrect entity match can become context for the next step and reinforce itself. Correcting it must preserve both the original extraction and the later human decision.
The requirements describe a broader platform for organizational knowledge, decisions and automation. The implementation examined here covers meeting ingestion, file artifacts, knowledge extraction and reconciliation, human review, search and a web interface. This review does not establish delivery of the whole platform, enterprise tenant isolation or independently deployed product runtimes. Development harnesses and project-management tools are outside the product runtime described here.
The data path
- A transcription-service adapter discovers meetings and queues downloads. Transcript and derived-document versions become file artifacts with checksums, while the database stores their metadata.
- A separate knowledge-processing run creates a source and revision, divides the text into units and performs extraction. Content and configuration identity allow completed work to be reused. Summarization has its own handler and does not itself enqueue ontology extraction.
- The model returns findings and quotations. Server code locates the exact quotation in the specified revision, computes its position and rejects missing or ambiguous anchors. Exact matching establishes where a quotation came from; semantic validity needs further checks.
- Reconciliation resolves entities, relations and temporal states. Sources advance in a defined order with durable checkpoints and work-ownership checks. Unresolved cases receive explicit states and review records.
- A deterministic materializer derives the canonical projection from selected extraction results and decisions. A fact retains the chain
CanonicalFact → Assertion → Evidence → SourceRevision. Human corrections have their own provenance.
- Meeting material and source revisions
- Parallel finding extraction
- Exact quotation anchoring
- Ordered reconciliation and human review
- Deterministic canonical projection
- Interface and knowledge reads
What the implementation contains
| Area | Evidence in the source |
|---|---|
| Application | A TypeScript monorepo with Node.js 24, NestJS, Next.js and React, shared contracts and Zod. REST controllers coexist with tRPC. |
| Execution | Database-backed jobs and handlers within the API process, with retries, recovery and configurable concurrency. An Effect runtime integrates with Nest dependency injection and shutdown. |
| Storage | PostgreSQL through Prisma and pg, file artifacts, relational provenance and canonical-fact records, and PostgreSQL full-text search. |
| Retrieval | The candidate module wires exact, alias/transliteration, full-text, graph and open-loop channels. Its vector backend is deferred. A separate MCP meeting-search path calculates cosine similarity in application code. |
| Models | An OpenAI-compatible extraction and resolution transport, captured run configuration, and an optional local GLiNER mention stage with configurable fallback to an LLM. |
| Deployment | Compose defines local PostgreSQL 18 with pgvector, a persistent volume and a healthcheck. Python helper services for GLiNER, name normalization and a model gateway have launchd templates. Running-service state was not inspected. |
Including pgvector in a database image does not establish an active approximate-nearest-neighbor search path. Source configuration also does not establish a cloud production deployment, high availability or an operational SLA.
Seven architecture decisions
The first four entries summarize existing ADRs. The final three reconstruct the architectural implications of specifications and code for this account; they are not newly accepted project ADRs.
ADR-1 — products above a shared kernel
The requirements choose separately deliverable products. Documented alternatives are a single product and open-core with a marketplace. The cost is cross-product contracts and version discipline. This is target architecture, not evidence that the entire suite ships.
ADR-2 — ontology as a versioned artifact
Ontology IR and generated artifacts are preferred to hardcoded semantics or independently maintained OWL files. Consistency and evolution require a compiler and version management. The code confirms a shared TypeScript registry, a hash and extraction-prompt compilation; the complete Studio and generator set are not established.
ADR-004 — a separate provenance model
Business entities are separated from assertions, evidence, revisions and extraction generations. Corrections add decisions rather than rewriting the extraction history. The documented cost of traceability and re-extraction is additional records, current-version pointers and materialization logic. Core mechanisms are present in code.
ADR-005 — explicit lifecycle states
Task cancellation and question withdrawal have distinct states, and relation constraints are refined. The MVP uses one flag for OWL functionality and current-value policy. Splitting these mechanisms is explicitly deferred: a documented simplification. Registry changes are present in code.
Reconstruction R1 — parallel extraction, ordered reconciliation
Independent extraction jobs meet at a barrier before source-ordered reconciliation. The inferred tradeoff is parallel throughput in independent work versus a sequential commit section that preserves causal order. Fully parallel commits are an analytical alternative, not a documented team decision.
Reconstruction R2 — checkpoints and fenced ownership
State transitions use compare-and-swap. Lease-protected writes check owner, token and expiry in the mutation condition itself. The inferred cost of rejecting stale workers is a more complex state and failure model. An in-memory-only lock is an analytical alternative.
Reconstruction R3 — PostgreSQL in a local container
The specification explicitly prefers a container to native installation for reproducibility; the code confirms PostgreSQL without a SQLite fallback. Operating a server and migrations adds complexity compared with a database file. That cost is an analytical assessment; requested search extensions are not automatically implemented features.
Quality checks and evaluation
The repository defines a common verification command covering policy rules, lint, types, instrumented tests, coverage, acceptance, builds and browser e2e. Test definitions cover exact and ambiguous evidence anchors, repeated anchoring, materializer determinism, shadow-build isolation and lease loss. They were not run for this review, so no current passing result is claimed.
Evaluation contracts specify source coverage, evidence exact matches, fact traceability, absence of future leakage, determinism and replay idempotency. The aggregator distinguishes a failed measurement from a missing one: an unmeasured critical gate prevents a positive verdict. Some earlier gold-based metrics have been removed from the active gate list. A recall@k calculator measures retrieval against supplied resolution decisions. These are evaluation mechanisms, not published independent benchmark results.
What the case demonstrates
The source provides concrete examples of LLM contracts, data versioning, provenance, entity reconciliation, recoverable processing and explicit quality invariants. These are useful subjects for an engineering portfolio and a discussion of AI-system evaluation.
Measured accuracy, throughput, production scale, complete requirements coverage and individual ownership of decisions remain unverified. This account describes the system and does not assign sole authorship of its design or implementation. A personal contribution statement requires separate confirmation from the project owner.