LeanKG

Enterprise Knowledge Graph Platform

PRODUCT REQUIREMENTS DOCUMENT

Version 2.0 | May 2026

Classification Internal — Confidential | Target Release Q3–Q4 2026

# 1. Executive Summary

LeanKG is an enterprise-grade, temporal Knowledge Graph platform purpose-built for large-scale microservice ecosystems. Starting as a local-first, lightweight tool, LeanKG v2.0 evolves into a shared internal backend service that gives every software engineer on a team — regardless of their local context — instant, precise, and token-efficient access to the collective intelligence of the entire codebase, all 200 services, across three deployment environments.

The platform answers three fundamental questions that slow down engineering teams:

• "What does this service do, and how does it connect to everything else?"

• "What broke in production last time, why, and how was it fixed?"

• "What is the correct, minimal context I need right now to complete this task with Cursor AI?"

LeanKG v2.0 introduces four strategic pillars beyond the current v0.5.9 codebase:

Pillar | What It Solves | Key Technology | Outcome
Shared Team KG Service | Siloed, stale local graphs | Graphiti + REST/MCP API | One source of truth for 200 services
Temporal Graph Evolution | No history of how the system changed | Graphiti temporal edges | Time-travel queries & incident replay
Incident Knowledge Loop | Incidents recur; fixes forgotten | Incident ontology + auto-propagation | AI agents never repeat known failures
3-Environment Isolation | Dev/staging/prod context collisions | Environment-scoped subgraphs | Zero false context delivered to Cursor

# 2. Problem Statement

## 2.1 The 200-Service Reality

Modern microservice architectures do not just add linear complexity — they compound it. With 200 services, the dependency graph contains potentially tens of thousands of edges. No single engineer holds a complete mental model. When something breaks, the investigation radius is enormous, context-gathering is slow, and the same mistakes happen again because the fix was never formalized into the shared knowledge base.

## 2.2 Current Pain Points

Pain Point | Who Feels It | Business Impact
AI coding tools (Cursor) scan entire repos → waste 80–99% of tokens on irrelevant context | Every engineer, every session | Token cost inflation; slow AI responses
No shared knowledge: every engineer re-discovers the same codebase facts | New hires, cross-team work | 2–5 days wasted onboarding per engineer per quarter
Production incidents recur because fixes exist only in Slack or individual memory | On-call engineers; SRE | MTTR increases; trust erodes
Local-only graph becomes stale within hours of a deployment | Engineers using Cursor daily | AI gives wrong or outdated context
No concept of environment: local, staging and prod queries return mixed results | QA, SRE, feature teams | Wrong fixes applied to wrong environments
Legacy codebase has zero structured documentation; context must be reverse-engineered each time | Engineers touching legacy | Feature delivery slows 3×; regressions increase

# 3. Vision and Goals

## 3.1 Vision Statement

LeanKG becomes the living nervous system of every engineering team that builds on microservices — a always-current, temporally-aware, semantically-rich knowledge graph that knows not just what the code is, but what it means, how it behaves across environments, what went wrong in the past, and how to prevent it from going wrong again.

## 3.2 Strategic Goals

Goal ID | Goal Description
G-01 | Deliver a shared, persistent Knowledge Graph service accessible by all team members via REST and MCP within the internal network
G-02 | Achieve single-query context retrieval that gives Cursor AI enough precision to complete any task on any of the 200 services without additional context gathering
G-03 | Maintain three isolated environment subgraphs (production, staging, local) that are automatically updated on every deployment and code change
G-04 | Build an incident documentation and propagation loop so that every resolved production issue becomes a permanent, queryable knowledge artifact that prevents recurrence
G-05 | Migrate the graph database layer from CozoDB to Graphiti to gain native temporal reasoning, entity evolution tracking, and LLM-native graph construction
G-06 | Enable every team member to contribute knowledge (annotations, runbooks, fixes, architectural decisions) through a low-friction interface that keeps the graph authoritative
G-07 | Reduce average Cursor AI token cost per engineering task by at least 60% compared to baseline full-repo scanning

## 3.3 Success Metrics

Metric | Current Baseline | v2.0 Target | Measurement Method
Token cost per AI query | 22,261 tokens (LeanKG v0.5.9) | < 8,000 tokens | MCP query log analysis
Context precision (relevant nodes / total returned) | ~40% | > 85% | Engineer feedback rating per query
Incident recurrence rate (same root cause) | Unmeasured; anecdotally high | < 5% over 6 months | Incident postmortem tags in KG
Knowledge graph freshness lag after deploy | Manual re-index required | < 5 minutes, automatic | CI/CD webhook timestamp delta
Engineer onboarding time to first productive PR | 3–5 days average | < 1 day with KG-assisted Cursor | HR + team lead survey
Shared KG API p99 latency | N/A (local only) | < 200ms for any query | API observability dashboard

# 4. User Stories

## 4.1 Software Engineer — Daily Development

US-01 | As a software engineer working in Cursor, I want to type a single natural-language query like "trace the payment flow from API gateway to database" and receive a minimal, precise subgraph of the relevant services, functions, schemas and their relationships so that I can start coding without spending 30 minutes reading source files.

US-02 | As an engineer picking up a new feature ticket, I want LeanKG to automatically surface the concept map for the feature domain (e.g., "Order Management") showing which services own it, which APIs expose it, which databases store it, and which other features share data with it, without me needing to know which repositories to search.

US-03 | As an engineer writing a new service, I want LeanKG to warn me — inside Cursor — when my proposed API contract already conflicts with an existing contract in another service in production, staging, or another team's local branch that has been pushed to the shared KG.

## 4.2 On-Call Engineer — Incident Response

US-04 | As an on-call engineer responding to a production alert, I want to query LeanKG with the error signature and receive: (a) the blast radius of affected services, (b) previously recorded incidents with the same or similar signature, (c) the resolution steps that worked last time, so I can resolve in minutes rather than hours.

US-05 | As an on-call engineer who just resolved an incident, I want a guided, low-friction flow to document the root cause, the fix, the impacted services, the environment context, and any code changes made, so that this knowledge is permanently queryable by future AI agents and engineers.

## 4.3 Team Lead / Architect

US-06 | As a team lead, I want to query the KG for the dependency blast radius of any planned refactor — showing which of the 200 services, tests, and feature flags will be affected — before a single line of code is changed, so I can accurately scope the migration effort.

US-07 | As an architect, I want the KG to maintain a versioned record of every Architectural Decision Record (ADR) linked to the code entities it affects, so that Cursor AI can explain not just what the code does but why it was designed that way.

## 4.4 New Team Member — Onboarding

US-08 | As a new engineer on day one, I want to ask Cursor "give me a tour of the checkout system" and receive a structured, context-rich walkthrough of the relevant services, their responsibilities, their known quirks, and the incidents they've had, all sourced from the team's shared KG.

## 4.5 QA / Release Engineer

US-09 | As a QA engineer, I want to query the staging environment subgraph to find all services that were updated in the last release candidate, the tests that cover them, and any known open issues in those services, so I can build a targeted regression test plan.

# 5. Concept Ontology — Deep Dive

The Concept Ontology defines the "what" of the system — the nouns, categories, and taxonomies that describe the knowledge domain. It answers: "What kinds of things exist in this system, and how are they classified?" This is the backbone of every query LeanKG will serve to Cursor AI agents.

## 5.1 Ontology Design Principles

• Universal Resource Identity: Every entity in the graph has a globally unique ID (GID) composed of [org]:[environment]:[service]:[type]:[name]:[version]. This prevents namespace collisions across 200 services and three environments.

• Layer Separation: Entities are organized into four conceptual layers — Infrastructure, Service, Domain, and Knowledge — and cross-layer relationships are explicitly typed.

• Temporal Validity: Every entity node carries valid_from and valid_until timestamps. This enables point-in-time queries ("what did the payment service look like on 2026-03-01?") and is the core reason for adopting Graphiti.

• Environment Scope: Every entity is tagged with its environment (production, staging, local:[engineer_id]) and subgraph queries are always environment-scoped unless explicitly cross-environment.

• Confidence Score: Entities auto-indexed from code carry a confidence score (0.0–1.0). Human-annotated entities start at 1.0. AI-inferred entities start at 0.6 and require human validation to promote to 0.9+.

## 5.2 Core Entity Types (Node Taxonomy)

### 5.2.1 Infrastructure Layer

Entity Type | Description & Key Properties
DeploymentEnvironment | Top-level environment scope: production | staging | local. Properties: name, region, cloud_provider, cluster_id, sla_tier.
Cluster | Kubernetes or ECS cluster. Properties: provider, region, node_count, namespace_list.
Namespace | K8s namespace or logical deployment group. Properties: environment_ref, owner_team.
Database | Database instance (Postgres, MySQL, Redis, Elasticsearch). Properties: type, host, schema_version, owner_service.
MessageQueue | Kafka topic, SQS queue, NATS subject. Properties: broker_type, topic_name, retention_policy, owner_service, consumer_services.
ExternalSystem | Third-party dependency (Stripe, Twilio, etc.). Properties: vendor, api_version, auth_type, known_issues.
ConfigMap / Secret | Environment-specific configuration entity. Properties: keys, owner_service, environment_scope.

### 5.2.2 Service Layer

Entity Type | Description & Key Properties
Microservice | The primary unit. Properties: name, team_owner, repository_url, language, framework, docker_image, current_version, environments[], health_check_url, sla_p99_ms, criticality_tier.
APIEndpoint | HTTP/gRPC endpoint. Properties: method, path, auth_scheme, rate_limit, request_schema, response_schema, deprecated, owner_service.
APIContract | Formal interface contract (OpenAPI, Protobuf, AsyncAPI). Properties: spec_version, format, compatible_versions[], breaking_change_log[].
Function / Method | Code-level callable. Properties: signature, file_path, line_range, language, complexity_score, test_coverage_pct.
Module / Package | Language-level module. Properties: path, language, export_count, import_count.
Repository | Git repository. Properties: url, default_branch, last_commit_sha, ci_pipeline_url.
CIBuild | CI/CD build artifact. Properties: build_id, status, triggered_by, test_results_url, deploy_target_env.
FeatureFlag | Feature toggle. Properties: flag_key, default_value, rollout_pct, owner_team, linked_services.

### 5.2.3 Domain Layer

Entity Type | Description & Key Properties
BusinessDomain | High-level bounded context (e.g., "Payments", "Inventory"). Properties: name, owner_team, services[], key_metrics[].
Feature | Product-level feature unit (e.g., "One-Click Checkout"). Properties: name, status (planned|active|deprecated), epic_id, jira_link, owner_team, linked_services[], acceptance_criteria.
DataEntity | A business data object (Order, User, Product). Properties: name, canonical_schema, owner_service, storage_locations[], pii_flag, gdpr_classification.
BusinessRule | A codified business constraint (e.g., "orders over $10K require manual approval"). Properties: rule_text, enforcement_point, linked_services[], linked_code_refs[].
ADR | Architectural Decision Record. Properties: title, status (proposed|accepted|superseded), context, decision, consequences, affected_services[], linked_commits[].
Runbook | Operational runbook. Properties: title, trigger_condition, steps[], owner_team, last_validated_date, linked_incidents[].

### 5.2.4 Knowledge Layer

Entity Type | Description & Key Properties
Incident | Production incident record. Properties: id, severity (P0–P4), title, environment, started_at, resolved_at, mttr_minutes, root_cause_summary, contributing_services[], resolution_steps[], linked_commits[], linked_runbook, recurrence_fingerprint.
KnownIssue | A documented bug or quirk not yet resolved. Properties: description, affected_service, workaround, severity, reporter, discovered_at, linked_incident.
DebugTrace | A recorded debugging session. Properties: query_text, affected_nodes[], resolution, engineer_id, created_at, environment, linked_incident.
CodeAnnotation | Human or AI-generated semantic annotation attached to any code entity. Properties: text, author, confidence, created_at, annotation_type (EXPLANATION | WARNING | TODO | FIX | WHY).
TeamKnowledge | Tribal knowledge nugget (e.g., "never run migrations on Friday evening"). Properties: text, author, domain_ref, tags[], confidence.
ChangeEvent | A recorded change to any graph entity (code, config, schema). Properties: entity_gid, change_type (ADD|MODIFY|REMOVE|DEPRECATE), changed_by, timestamp, commit_sha, diff_summary.

## 5.3 Relationship Type Taxonomy (Edge Types)

All edges are directed and typed. Every edge carries: source_gid, target_gid, relation_type, valid_from, valid_until, confidence, environment, and metadata.

### 5.3.1 Structural Relationships

Edge Type | Semantics & Example
OWNS | Team or service owns an entity. (team:payments) OWNS (service:payment-gateway)
DEPLOYED_IN | Service is deployed in an environment. (service:order-service) DEPLOYED_IN (env:production)
IMPORTS | Module imports another module. (module:auth-client) IMPORTS (module:jwt-lib)
CALLS | Function calls another function. (fn:processOrder) CALLS (fn:chargeCard)
DEPENDS_ON | Service runtime dependency. (service:order) DEPENDS_ON (service:inventory)
EXPOSES | Service exposes an API endpoint. (service:user-service) EXPOSES (endpoint:GET /users/{id})
STORES_IN | Service writes to a database. (service:order) STORES_IN (db:orders_postgres)
PUBLISHES_TO | Service publishes to a message queue. (service:payment) PUBLISHES_TO (queue:payment-events)
CONSUMES_FROM | Service consumes from a message queue. (service:notification) CONSUMES_FROM (queue:payment-events)
TESTED_BY | Code entity is covered by a test. (fn:chargeCard) TESTED_BY (test:TestChargeCard_Success)
IMPLEMENTS | Service implements a feature. (service:cart) IMPLEMENTS (feature:add-to-cart)
DEFINED_BY | Service is governed by a contract. (service:payment-gateway) DEFINED_BY (contract:payment-openapi-v3)

### 5.3.2 Knowledge Relationships

Edge Type | Semantics & Example
CAUSED_BY | Incident root cause. (incident:INC-2024-001) CAUSED_BY (service:legacy-auth)
RESOLVED_BY | Incident resolution action. (incident:INC-2024-001) RESOLVED_BY (commit:abc123)
DOCUMENTED_IN | Entity has a runbook or ADR. (service:payment-gateway) DOCUMENTED_IN (runbook:payment-failover)
SUPERSEDES | ADR supersedes a prior decision. (adr:ADR-045) SUPERSEDES (adr:ADR-023)
ANNOTATED_WITH | Code entity has semantic annotation. (fn:legacyCalc) ANNOTATED_WITH (annotation:WHY-we-cant-refactor)
SHARES_DATA_WITH | Two services exchange a DataEntity. (service:order) SHARES_DATA_WITH (service:fulfillment) VIA (data:Order)
RECURRENCE_OF | Incident is a recurrence of a known pattern. (incident:INC-2026-022) RECURRENCE_OF (incident:INC-2024-001)
MITIGATED_BY | Known issue is mitigated by a workaround. (known-issue:KI-007) MITIGATED_BY (runbook:KI-007-workaround)
EVOLVED_FROM | Temporal entity evolution. (service:auth-v2) EVOLVED_FROM (service:auth-v1)
DEPLOYED_AS | Code version deployed as a build artifact. (commit:def456) DEPLOYED_AS (build:build-4891) IN (env:production)

# 6. Procedural Ontology — Deep Dive

While the Concept Ontology describes what exists, the Procedural Ontology encodes what happens — sequences of actions, workflows, decision trees, and operational patterns. It is the "how" layer of the knowledge graph, and it is what transforms LeanKG from a code-indexer into a true engineering intelligence platform.

## 6.1 Procedural Entity Types

### 6.1.1 Workflow

A Workflow represents a business or technical process as a directed acyclic graph (DAG) of Steps. Workflows are first-class nodes in the knowledge graph and can be queried to understand end-to-end business processes.

Property | Description
workflow_id | Unique identifier (e.g., "checkout-flow-v3")
name | Human-readable name
domain | BusinessDomain reference
trigger | What initiates this workflow (event, API call, schedule)
steps | Ordered list of Step node GIDs
happy_path_sla_ms | Expected duration for the happy path
error_paths | List of known failure modes and their recovery workflows
environment_variants | Differences in workflow behavior per environment
last_traced_at | Timestamp of last live trace (production execution captured)

### 6.1.2 Step

A Step is a single unit of work within a Workflow. It maps to one or more Microservices, Functions, or APIEndpoints and carries the input/output contract and the known failure modes of that step.

Property | Description
step_id | Unique within its workflow
name | Descriptive label (e.g., "Validate Payment Method")
responsible_service | Microservice GID
responsible_function | Function GID (optional, for granular tracing)
input_schema | Expected input data shape (JSON Schema reference)
output_schema | Expected output data shape
timeout_ms | Timeout configuration
retry_policy | Retry count, backoff strategy
failure_mode | What happens when this step fails (skip, abort, fallback)
fallback_step | Step GID to execute on failure

### 6.1.3 OperationalProcedure

An OperationalProcedure is a human+system workflow for operational tasks: deployments, rollbacks, database migrations, certificate rotations, and on-call escalations. It is the structured form of a Runbook.

Property | Description
procedure_id | Unique identifier
trigger_conditions | Alert conditions or manual triggers that invoke this procedure
preconditions | System state that must be true before starting (e.g., "staging deploy successful")
steps | Ordered list of ProcedureStep nodes
rollback_procedure | Reference to a rollback OperationalProcedure
escalation_path | Who to contact at each step if automated resolution fails
estimated_duration_minutes | How long this procedure takes
affected_environments | Which environments are impacted
validation_checks | Post-completion validation queries against the KG

### 6.1.4 IncidentResponsePlaybook

A specialized form of OperationalProcedure that encodes the structured response to a specific class of incidents. Playbooks are linked to Incidents via RESOLVED_BY and are retrieved automatically when a new incident's fingerprint matches a known pattern.

• Fingerprint matching uses both structural similarity (same services in blast radius) and semantic similarity (error message embedding comparison via vector search in Graphiti).

• Playbooks are version-controlled within the KG and can be marked as superseded when a more reliable resolution is found.

• Every step in a Playbook can be marked as "AI-executable" (Cursor can automate it) or "human-required" (requires manual judgment).

### 6.1.5 DevelopmentProcedure

Encodes team-specific development workflows: how to add a new service, how to deprecate an API, how to perform schema migrations, how to conduct code reviews. These are the institutional knowledge that currently lives only in Confluence or the minds of senior engineers.

Procedure | Example Steps Encoded in KG
Add New Microservice | Create repo → Define OpenAPI contract → Register in KG → Add to service mesh → Configure CI/CD → Set up dashboards → Add to dependency graph
Deprecate API Endpoint | Mark as deprecated in KG → Notify consumer services → Set sunset date → Monitor consumer traffic → Remove after sunset → Update contracts
Database Schema Migration | Create migration script → Test in local → Test in staging → Create rollback script → Deploy in production with feature flag → Validate → Remove flag
Incident Postmortem | Gather timeline → Identify root cause → Write resolution → Link to affected KG nodes → Update playbook → Schedule follow-up items

## 6.2 Procedural Query Patterns for Cursor AI

The Procedural Ontology enables a new class of queries that are not possible with a purely structural code graph:

Query Intent | Procedural Ontology Used | Context Returned to Cursor
"How do I implement X feature end-to-end?" | DevelopmentProcedure: Add New Feature | Ordered steps + linked services + example PRs + ADRs
"Trace the checkout flow" | Workflow: checkout-flow-v3 | Step DAG + service map + known failure points + SLAs
"What do I do when payment times out?" | IncidentResponsePlaybook: payment-timeout-P2 | Fingerprint-matched playbook + recent incident outcomes
"How do I roll back the order service?" | OperationalProcedure: rollback-order-service | Step-by-step + preconditions + validation checks
"What broke in staging last week?" | Incident nodes + environment:staging filter | Incident list + root causes + resolutions + status
"Is there a documented reason why auth service is synchronous?" | ADR + CodeAnnotation (type:WHY) | ADR-023 context, decision, and consequences

# 7. Database Layer: Graphiti vs CozoDB — Analysis & Decision

The current LeanKG implementation uses CozoDB as its graph database backend — an embedded, Datalog-powered database with strong query expressiveness for static graphs. As the requirements evolve toward temporal reasoning, shared multi-user access, LLM-native graph construction, and incident replay, a re-evaluation is warranted.

## 7.1 CozoDB — Current State Assessment

### Strengths

• Embedded (no separate process): zero operational overhead for local-first use cases

• Datalog query language: expressive recursive queries for impact radius computation

• Strong performance for read-heavy workloads on static graphs

• Rust-native library: excellent fit for the current LeanKG Rust binary

• No licensing costs; MIT licensed

### Limitations for v2.0 Requirements

• No native temporal graph support: bi-temporal edges require manual implementation with significant complexity

• No built-in LLM integration: entity extraction and semantic search require external tooling

• Not designed for multi-user concurrent writes: shared team service requires careful locking

• No vector search: semantic similarity for incident fingerprint matching is not supported natively

• Schema evolution is painful: changing the graph schema requires manual migration scripts

• Limited ecosystem: smaller community, fewer integrations compared to Neo4j or dedicated temporal graph stores

## 7.2 Graphiti — Capability Assessment

Graphiti is an open-source temporal knowledge graph framework developed by Zep AI, specifically designed for building LLM-powered applications that require memory of events over time. It is built on top of Neo4j and integrates deeply with LLM pipelines.

### Core Graphiti Capabilities Relevant to LeanKG v2.0

Capability | How It Addresses LeanKG v2.0 Needs
Bi-temporal edges (valid_time + transaction_time) | Every graph change has two time axes: when it was true in the world, and when it was recorded. Enables both "what did the system look like on March 1?" and "what did we know about it on March 1?"
LLM-native entity extraction | Graphiti can ingest unstructured incident reports, Slack messages, or PR descriptions and automatically extract entities and relationships into the graph — dramatically reducing annotation friction
Vector-based semantic search | Built-in embedding search enables incident fingerprint matching: "find incidents semantically similar to this error stack trace" without exact string matching
Episode-based ingestion | Graphiti's episodic memory model is ideal for incident documentation: each incident resolution session is an "episode" that updates the graph with new knowledge, preserving history
Contradiction detection | Graphiti detects when new information contradicts existing graph facts and flags them for human review — prevents knowledge corruption in a multi-contributor shared KG
Neo4j backend | Production-grade, horizontally scalable graph database with ACID transactions, full-text search, and a rich ecosystem of tooling
Python-first SDK | Graphiti's Python SDK integrates naturally with FastAPI-based backend services, enabling rapid development of the LeanKG v2.0 API layer

### Graphiti Limitations & Mitigations

Limitation | Mitigation Strategy
Requires Neo4j (no longer embedded) | Run Neo4j in Docker for local environments; use Neo4j Aura or self-hosted cluster for staging/production. Cost: ~$50–200/month for team-sized Neo4j Aura instance.
Python SDK (vs Rust binary) | LeanKG v2.0 separates into: (a) Rust indexer/CLI that writes to Graphiti via REST API, (b) Python FastAPI service (leankg-server) that wraps Graphiti and exposes MCP + REST endpoints.
LLM API dependency for entity extraction | Entity extraction from code is still done via the Rust tree-sitter indexer (deterministic, fast, no LLM). LLM-based extraction is used only for unstructured inputs (incident reports, annotations). Configurable to use local LLM (Ollama) to avoid external API costs.
Graphiti is relatively new (v0.x) | Pin to a stable Graphiti version; abstract the Graphiti interface behind a LeanKG GraphStore trait so we can swap back to CozoDB or to another backend if needed.

## 7.3 Decision Recommendation: Migrate to Graphiti

DECISION | LeanKG v2.0 should migrate from CozoDB to Graphiti as the primary graph store for the shared server mode, while retaining CozoDB as an option for offline/local-only CLI mode where engineers prefer zero-dependency operation.

The architectural pattern is:

• Local CLI mode (leankg CLI without --remote flag): CozoDB embedded, unchanged from v0.5.9. Works offline, no dependencies, instant startup.

• Shared server mode (leankg-server): Graphiti + Neo4j, exposed via REST and MCP. All team members connect to this instance. All ChangeEvents, Incidents, and environment updates go through this server.

• Sync bridge: When an engineer's local CozoDB graph has changes that should be promoted to the team KG (e.g., a new annotation or a resolved incident), leankg sync pushes those delta changes to the shared Graphiti server.

# 8. Three-Environment Architecture

One of the most critical v2.0 features is the introduction of environment-scoped subgraphs. Today, LeanKG indexes whatever codebase is in the current directory — there is no concept of whether that code is running in production, staging, or a developer's local machine. This causes context collisions that mislead AI agents.

## 8.1 Environment Model

Environment | Scope & Source of Truth | Update Trigger
Production (prod) | What is currently serving real user traffic. The highest-trust, highest-priority subgraph. Services, versions, configs, and database schemas reflect the deployed state. | CI/CD deployment webhook fires on every successful production deploy. Kubernetes admission webhook captures rollouts. ChangeEvent nodes are created automatically.
Staging (staging) | The pre-production integration environment. Reflects the state of the next release candidate. May contain services not yet in production and experimental feature flags. | CI/CD webhook on staging deploy. Engineers can also manually push staging-specific annotations. Staging graph is a child of production with deltas applied on top.
Local ([engineer_id]) | Each engineer's development context. Scoped to their machine, their current branch, and their work-in-progress changes. Multiple local graphs can coexist without conflict. | leankg watch detects local file changes and updates the local subgraph. leankg sync optionally pushes human-approved knowledge to the shared team KG.

## 8.2 Environment Inheritance Model

Environments follow an inheritance chain: Local → Staging → Production. When an entity does not exist in the local graph, the query engine automatically falls through to staging, then to production. This means a developer working on service-A can query the full system context even for services they have never checked out locally.

EXAMPLE | Engineer Alice is working on "user-service" locally. She queries: "what services call my notification endpoint?" LeanKG first checks Alice's local graph (no consumers indexed locally), falls through to staging (2 consumers found), then production (5 consumers found). Response includes all 5 with environment labels so Alice knows which ones are live.

## 8.3 Conflict Resolution Rules

Conflict Type | Resolution Strategy
Same service, different versions in staging vs production | Both nodes exist. Queries scoped to production return the production version. Cross-environment queries return both with version labels. ChangeEvent edges show the diff.
Local schema differs from staging/production | Local schema change is flagged with a CONFLICT_WARNING annotation. Engineer must explicitly mark it as intentional or sync it to staging before it can be queried without a warning.
Two engineers have conflicting local annotations for the same entity | Both annotations are preserved. When queried, both are returned with author and timestamp metadata. The shared team KG shows the most recently human-validated annotation as canonical.
An incident resolution in local differs from the one documented in production KG | Incident nodes are environment-tagged. Engineer can run leankg incident merge to propose their resolution as an update to the production incident record, which goes through a review step.

# 9. Shared Team Knowledge Graph Service

The core architectural shift in LeanKG v2.0 is the promotion from a local CLI tool to a shared internal backend service. Every team member, every CI/CD pipeline, every AI agent queries this single authoritative service.

## 9.1 Service Architecture

### 9.1.1 Component Stack

Component | Technology & Responsibility
Graph Store | Graphiti (Zep AI) + Neo4j 5.x. Stores all entity and relationship data with full temporal and vector indexing.
API Server (leankg-server) | Python 3.12 + FastAPI. Exposes REST API, MCP server endpoint, and WebSocket for real-time graph update notifications.
Indexer Workers | Rust-based workers (ported from current LeanKG CLI). Consume CI/CD webhooks, parse source code via tree-sitter, and write structured entities to Graphiti.
LLM Gateway | Optional: LiteLLM proxy configured to route entity extraction and semantic search requests to either OpenAI, Anthropic, or a local Ollama instance based on team configuration.
Auth & RBAC | JWT-based authentication. Role: Reader (query only), Contributor (query + annotate + document incidents), Admin (configure environments, approve schema changes).
Cache Layer | Redis. Caches frequent subgraph queries (service dependency maps, impact radius results) with a 60-second TTL. Cache is invalidated on ChangeEvent for affected entities.
Sync Agent (leankg sync) | Rust CLI component. Pushes local graph deltas to the shared server, resolves conflicts, and pulls remote updates to the local CozoDB cache.
Web UI (leankg web) | Enhanced from v0.5.9. Adds team dashboard, environment switcher, incident log, and knowledge contribution interface.

## 9.2 REST API Design

### Core Query Endpoints

Endpoint | Description
GET /api/v2/context?q={query}&env={env}&depth={n} | Primary context retrieval. Natural language or GID-based query returning a targeted subgraph with the minimum nodes needed. env defaults to production.
GET /api/v2/services/{service_id}/impact?env={env} | Blast radius computation for a service. Returns all downstream services, functions, and tests affected by a change.
GET /api/v2/services/{service_id}/dependencies?env={env} | Full dependency tree (upstream and downstream) for a service.
GET /api/v2/trace/{workflow_id}?env={env} | Full procedural trace of a workflow with all step details and known failure modes.
GET /api/v2/incidents?env={env}&fingerprint={fp}&limit={n} | Retrieve incidents matching a fingerprint or recency filter.
POST /api/v2/incidents | Create a new incident record with structured metadata.
PATCH /api/v2/incidents/{id}/resolve | Document the resolution of an incident. Triggers auto-propagation to update related KnownIssue nodes and Playbooks.
POST /api/v2/entities/{gid}/annotate | Add a CodeAnnotation or TeamKnowledge node to any entity.
GET /api/v2/search?q={text}&type={entity_type}&env={env} | Full-text + semantic hybrid search across all entity names, descriptions, and annotations.
GET /api/v2/environments/diff?from={env1}&to={env2} | Show all entity differences between two environments (e.g., staging vs production delta for current release).
GET /api/v2/history/{gid}?from={ts}&to={ts} | Temporal history of an entity — all changes between two timestamps using Graphiti's bi-temporal index.

## 9.3 MCP Server Design

The shared leankg-server exposes an MCP-compatible server endpoint at mcp://internal.leankg:7700/mcp. Cursor AI agents and Claude Code agents connect to this endpoint. All engineers' Cursor instances point to the same shared MCP server — they do not run local LeanKG MCP servers.

### Enhanced MCP Tool Set for v2.0

MCP Tool | Description
kg_context(query, env, depth) | Primary tool. Returns a compact JSON subgraph for any natural-language or GID query. The workhorse of Cursor integration.
kg_impact(service_id, env) | Compute blast radius. Returns list of affected services, functions, and tests.
kg_trace_workflow(workflow_id, env) | Retrieve full procedural trace of a named workflow.
kg_search(text, type, env) | Semantic + full-text search across the entire KG.
kg_incident_lookup(error_sig, env) | Find past incidents by error signature or semantic similarity.
kg_diff_environments(from_env, to_env) | Show what's different between staging and production.
kg_annotate(gid, text, type) | Add an annotation to any entity from within a Cursor session. Low-friction knowledge contribution.
kg_service_info(service_id, env) | Complete profile of a service: owner, dependencies, APIs, known issues, recent incidents.
kg_history(gid, from, to) | Temporal history of any entity. "What did this service look like last month?"
kg_document_incident(incident_data) | Create a new incident record directly from a Cursor session during incident response.

# 10. Incident Knowledge Loop

The Incident Knowledge Loop is the mechanism that ensures LeanKG evolves continuously with the team's operational experience. Every incident resolved is converted into structured, queryable knowledge that prevents its recurrence.

## 10.1 Incident Lifecycle in the KG

1. DETECTION: Alert fires (PagerDuty, Datadog, Prometheus). Incident is auto-created in KG with severity, affected_services (from alert metadata), environment:production, and recurrence_fingerprint (hash of error type + service set).

2. TRIAGE: Engineer queries kg_incident_lookup(error_sig, "production") from Cursor. KG returns: (a) matching past incidents with fingerprints, (b) the playbook that resolved each, (c) the blast radius graph for the current alert.

3. RESPONSE: Engineer follows the suggested playbook steps. Each step executed can be logged back to the incident record via kg_document_incident.

4. RESOLUTION: Engineer runs the incident resolution flow in the LeanKG Web UI or via leankg incident resolve {id}. Guided form captures: root cause summary, resolution steps (free text + structured), linked commits, linked runbook, lessons learned.

5. PROPAGATION: leankg-server auto-propagates the resolution: (a) creates or updates a Playbook node linked to this incident class, (b) creates RESOLVED_BY edges to the fix commits, (c) updates the recurrence_fingerprint index so future identical incidents are immediately matched, (d) marks any KnownIssue nodes as resolved or partially mitigated, (e) notifies the team channel via webhook.

6. FUTURE PREVENTION: Next time Cursor AI encounters the same error signature in any codebase context, kg_incident_lookup returns the full history and resolution. The AI agent can automatically suggest the fix without engineer intervention.

## 10.2 Recurrence Fingerprint Algorithm

The fingerprint system is what enables LeanKG to recognize "we've seen this before" across incidents that may not have identical error messages:

Fingerprint Component | Weight in Similarity Score
Error type / exception class (exact match) | 35%
Primary service in blast radius (exact match) | 25%
Error message semantic embedding similarity (vector cosine) | 20%
Secondary affected services overlap (Jaccard similarity) | 10%
Time-of-day / day-of-week pattern | 5%
Environment match | 5%

An incident is considered a recurrence when the composite similarity score exceeds 0.75. The on-call engineer is notified: "This appears to be a recurrence of INC-2024-001 (similarity: 87%). Suggested resolution: [link to playbook]."

# 11. Token Efficiency Strategy

Token efficiency is not a nice-to-have — it is the primary value proposition of LeanKG for teams using Cursor. Every architectural decision must be evaluated against its impact on token cost per AI task.

## 11.1 Context Budget Model

LeanKG v2.0 introduces a Context Budget — a configurable maximum token count for any single KG query response. The default budget is 4,000 tokens. The query engine is responsible for fitting the most relevant subgraph within this budget.

Budget Tier | Use Case & Token Limit
Nano (≤ 500 tokens) | Quick lookups: "what team owns this service?" / "is this endpoint deprecated?" Returns a single entity with key properties only.
Micro (≤ 2,000 tokens) | Single-service context: dependencies, APIs, owner, known issues. Sufficient for most single-file edits.
Standard (≤ 4,000 tokens) | Feature-level context: all services in a domain, their relationships, recent incidents. Sufficient for cross-service feature work.
Extended (≤ 8,000 tokens) | Architecture-level context: full workflow traces, impact radii, environment diffs. Used for large refactors or incident investigation.
Full (≤ 16,000 tokens) | Reserved for architectural review queries. Requires explicit opt-in. Never used as default.

## 11.2 Context Compression Techniques

• Property filtering: Only include entity properties that are relevant to the query context. A "trace the checkout flow" query does not need database host names.

• Edge pruning: Include only edges within the requested depth. Default depth is 2 hops from the seed entity. Deeper hops are summarized as counts ("3 more services in layer 3").

• Semantic deduplication: When two entities in the result are semantically nearly identical (e.g., two versions of the same service), they are merged with a delta summary.

• Annotation summarization: Long CodeAnnotations and TeamKnowledge entries are summarized to 1–2 sentences by the LLM gateway before inclusion in the context response.

• Progressive disclosure: The API returns context in tiers. Cursor receives Tier 1 first (entity names + relationships). If the AI agent determines it needs more detail on a specific node, it makes a follow-up drill-down query for that node only.

# 12. Cursor AI Integration

## 12.1 Team-Wide MCP Configuration

Instead of each engineer configuring their own local LeanKG MCP server (as in v0.5.9), the team maintains a single shared MCP endpoint. Engineers add the following to their Cursor workspace .cursorrules or the team-wide cursor-team.json:

Cursor MCP Configuration (cursor-team.json)
{
"mcpServers": {
"leankg": {
"url": "http://internal.leankg.company.com:7700/mcp",
"auth": { "type": "bearer", "token": "${LEANKG_TOKEN}" },
"env": "production",
"localOverride": true
}
}
}
# localOverride: true means Cursor will first check the shared KG,
# then blend in local graph data for the current repository.

## 12.2 Mandatory LeanKG-First Instruction

The following instruction is distributed to all team members' .cursorrules files and enforced via the leankg install cursor command:

AGENTS.md — Mandatory LeanKG-First Rule (Cursor)
## MANDATORY: Use LeanKG Before Anything Else
Before ANY codebase navigation, search, or context-gathering:
1. Call kg_context(query, env) — this is ALWAYS your first tool call
2. Use kg_impact() before any refactor to understand blast radius
3. Use kg_incident_lookup() when you see error messages or alerts
4. Use kg_trace_workflow() when asked about business processes
NEVER grep, read_file, or list_directory before calling LeanKG.
LeanKG context is 10–100× cheaper than raw file scanning.
When LeanKG returns context, trust it. Only fall back to
direct file reading when LeanKG explicitly says "entity not indexed".
ALWAYS use env="production" unless the user specifies staging or local.

# 13. Team Knowledge Contribution Model

For the shared KG to remain valuable, it must be easy for every team member to contribute to it. LeanKG v2.0 provides multiple contribution surfaces — from fully automated (CI/CD indexing) to highly human-guided (incident documentation).

## 13.1 Contribution Surfaces

Contribution Surface | How It Works
Automatic: CI/CD Webhook | Every deployment triggers the LeanKG indexer. All code entities are re-indexed, ChangeEvents are created, and environment subgraphs are updated. Zero human effort.
Automatic: PR Merge Hook | When a PR merges, the indexer diffs the graph: new functions, deleted functions, changed API contracts, new dependencies. Breaking changes in API contracts trigger a BREAKING_CHANGE_WARNING annotation.
Semi-automatic: Incident Resolution Flow | Guided form at incident close. Requires the on-call engineer to fill in root cause and resolution. LLM pre-populates fields based on the incident timeline; engineer approves or edits.
Manual: Cursor In-Session Annotation | Engineer types in Cursor: "LeanKG: annotate this function — it MUST not be called concurrently, there is a known race condition." LeanKG calls kg_annotate() and creates a WARNING annotation.
Manual: ADR Registration | Architect submits ADR via leankg adr create or the Web UI. LeanKG links it to affected services and functions automatically using entity extraction.
Manual: Runbook Creation | Via Web UI or leankg runbook create. Steps can reference entity GIDs directly, enabling the KG to link runbook steps to the exact service components they affect.
Manual: TeamKnowledge Nugget | Any engineer can submit tribal knowledge via leankg know "never deploy payment-service on Fridays — the settlement batch starts at 23:00 UTC and a deploy mid-batch causes double-charges."

## 13.2 Knowledge Quality Gates

As the shared KG grows, quality control becomes critical. LeanKG v2.0 introduces quality gates at the contribution layer:

• Confidence scoring: Every entity and annotation has a confidence score. Auto-indexed code entities start at 0.95 (high, because they are deterministic). LLM-extracted entities from incident reports start at 0.65 and must be reviewed.

• Staleness detection: Entities not updated in 90 days receive a STALE warning. The owning team receives a weekly digest of stale KG nodes in their services.

• Contradiction alerts: Graphiti's contradiction detection flags when a new annotation directly contradicts an existing one. Both are preserved but flagged for resolution.

• Curation queue: The LeanKG Web UI includes a curation queue where Admins and Leads can review, promote, edit, or reject pending annotations and knowledge contributions.

# 14. Functional Requirements

## 14.1 Core Requirements

ID | Category | Requirement | Priority | Source
FR-01 | Shared Service | leankg-server MUST expose a REST API and MCP endpoint accessible to all engineers on the internal network | P0 | G-01
FR-02 | Shared Service | All engineers' Cursor instances MUST be configurable to point to the shared MCP server as a team-managed default | P0 | US-01
FR-03 | Environment | The KG MUST maintain three isolated subgraphs: production, staging, and local:[engineer_id] | P0 | G-03
FR-04 | Environment | The query API MUST support env parameter on all endpoints and default to production | P0 | G-03
FR-05 | Environment | Environment inheritance MUST fall through local → staging → production when an entity is not found | P1 | 8.2
FR-06 | Indexing | The CI/CD webhook integration MUST automatically update the production and staging subgraphs within 5 minutes of a deployment | P0 | G-03
FR-07 | Indexing | The indexer MUST support Go, TypeScript, Python, Rust, and Java as primary languages | P0 | Current v0.5.9
FR-08 | Indexing | Breaking API contract changes MUST generate a BREAKING_CHANGE_WARNING annotation automatically detectable by Cursor | P1 | US-03
FR-09 | Incidents | The system MUST support creating, documenting, and resolving incident records via API, Web UI, and CLI | P0 | G-04
FR-10 | Incidents | On incident resolution, the system MUST auto-propagate updates to related Playbook, KnownIssue, and IncidentResponsePlaybook nodes | P0 | G-04
FR-11 | Incidents | The system MUST compute a recurrence fingerprint for every new incident and surface matching past incidents with similarity score | P0 | 10.2
FR-12 | Graphiti | The shared server MUST use Graphiti + Neo4j as the graph store backend | P0 | G-05
FR-13 | Graphiti | The system MUST support temporal queries ("what did service X look like on date Y?") via Graphiti bi-temporal indexing | P1 | G-05
FR-14 | Contribution | Engineers MUST be able to add annotations to any entity from within a Cursor session via kg_annotate MCP tool | P1 | G-06
FR-15 | Token Efficiency | All MCP tool responses MUST fit within the configured Context Budget (default 4,000 tokens) | P0 | G-07
FR-16 | Token Efficiency | The query engine MUST support progressive disclosure: return Tier 1 context first, with drill-down available for specific nodes | P1 | 11.2
FR-17 | Auth | The shared server MUST enforce JWT-based authentication with RBAC roles: Reader, Contributor, Admin | P0 | 9.1.1
FR-18 | Legacy Support | The system MUST support manual annotation of legacy code entities that cannot be auto-indexed (e.g., undocumented COBOL modules, binary services) | P2 | Problem Statement

# 15. Non-Functional Requirements

ID | Category | Requirement | Target
NFR-01 | Performance | MCP tool response time (p50) | < 50ms
NFR-02 | Performance | MCP tool response time (p99) | < 200ms
NFR-03 | Performance | Impact radius computation for any service in a 200-service graph | < 500ms
NFR-04 | Performance | Incident fingerprint lookup | < 100ms
NFR-05 | Availability | Shared KG service uptime SLA | 99.5%
NFR-06 | Scalability | Graph node capacity without performance degradation | 10 million nodes
NFR-07 | Scalability | Concurrent MCP client connections | 500 simultaneous
NFR-08 | Freshness | Max lag from CI/CD deploy to graph update | < 5 minutes
NFR-09 | Security | All API traffic must be TLS 1.3 encrypted | Mandatory
NFR-10 | Security | PII-flagged DataEntity nodes must be access-controlled to Contributor+ only | Mandatory
NFR-11 | Security | All graph writes must be audited with engineer identity and timestamp | Mandatory
NFR-12 | Reliability | The local CLI mode (CozoDB) must function fully offline | Mandatory
NFR-13 | Reliability | If the shared KG service is unavailable, Cursor must gracefully degrade to the local CozoDB cache | Mandatory
NFR-14 | Data Retention | All temporal graph history retained for minimum 2 years | Mandatory
NFR-15 | Observability | All MCP queries logged with: engineer_id, query, tokens_returned, latency, env | Mandatory

# 16. Migration Plan: CozoDB → Graphiti

Phase | Duration | Work Items
Phase 0: Preparation | 2 weeks | Define GraphStore trait in Rust. Refactor current CozoDB calls to implement this trait. Write integration tests against the trait interface. No behavior change.
Phase 1: Graphiti Server Bootstrap | 3 weeks | Stand up Neo4j 5.x + Graphiti in Docker Compose. Build leankg-server (FastAPI) with core REST and MCP endpoints. Implement entity schema in Graphiti matching current CozoDB schema. Write data migration script to export CozoDB snapshot and import to Graphiti.
Phase 2: Indexer Integration | 3 weeks | Port Rust indexer to write to leankg-server REST API instead of local CozoDB. Implement CI/CD webhook receiver. Implement environment-scoped write paths. Test with production codebase (shadow mode — write to both CozoDB and Graphiti, compare results).
Phase 3: Temporal Features | 2 weeks | Enable Graphiti bi-temporal indexing. Implement ChangeEvent creation on every write. Build temporal query API endpoints. Implement leankg history command.
Phase 4: Incident Loop | 3 weeks | Implement Incident entity CRUD. Implement recurrence fingerprint algorithm using Graphiti vector search. Build incident resolution propagation workflow. Build Web UI incident documentation interface.
Phase 5: Team Rollout | 2 weeks | Deploy shared leankg-server to internal infrastructure. Distribute team Cursor MCP configuration. Run 2-week parallel operation (both CozoDB local and Graphiti shared active). Collect engineer feedback. Cut over to Graphiti as primary.
Phase 6: CozoDB Deprecation (Soft) | 4 weeks post-rollout | Retain CozoDB for offline-only mode (no shared features). Remove CozoDB from server-mode code path. Update documentation and install scripts.

RISK | The largest migration risk is correctness: Graphiti's entity extraction may produce a graph that differs from the deterministic tree-sitter + CozoDB graph. Shadow mode comparison in Phase 2 is critical. Define a diff coverage target of < 2% unexplained discrepancies before cutting over.

# 17. Roadmap

Milestone | Target Date & Deliverables
v0.5.x (Current) | Local-first CozoDB, tree-sitter indexing, MCP for Cursor/Claude Code/OpenCode, 25.6% token savings. [DONE — Released March 2026]
v1.0 — Shared Service Alpha | Q2 2026 (July). leankg-server (FastAPI + Graphiti + Neo4j). REST API + MCP shared endpoint. Production environment subgraph. CI/CD webhook integration (GitHub Actions, GitLab CI). JWT auth. Internal team alpha test (5 engineers).
v1.1 — Three Environments | Q2 2026 (August). Staging + local environment subgraphs. Environment inheritance fallthrough. Environment diff API. Local sync agent (leankg sync). Web UI environment switcher.
v1.2 — Incident Loop MVP | Q3 2026 (September). Incident entity CRUD. Recurrence fingerprint v1 (structural only). Incident resolution propagation. kg_incident_lookup MCP tool. Web UI incident documentation flow.
v2.0 — Full Platform | Q3 2026 (October). Temporal queries (Graphiti bi-temporal). Semantic fingerprinting (vector embeddings). Full Concept + Procedural Ontology. Workflow + Playbook entities. IncidentResponsePlaybook auto-generation. Context Budget with progressive disclosure. Team-wide rollout.
v2.1 — Legacy Codebase Support | Q4 2026 (November). Manual entity creation for unindexable legacy services. Binary/undocumented service stubs. Legacy annotation import from Confluence/Notion. Cross-language dependency tracing (Go → Python → Java).
v2.2 — Intelligence Layer | Q4 2026 (December). AI-assisted ADR generation from code patterns. Automatic DevelopmentProcedure extraction from PR descriptions. Proactive conflict detection (your PR will break 3 downstream services). Knowledge health dashboard.
v3.0 — Multi-Team Federation | Q1 2027. Federated KG across multiple internal teams. Cross-team shared knowledge with permission boundaries. External dependency tracking (vendor SLAs, API versioning). Public-facing KG export (anonymized for open-source contributions).

# 18. Appendix

## 18.1 Glossary

Term | Definition
ADR | Architectural Decision Record — a document capturing an architectural decision, its context, and consequences.
Bi-temporal indexing | Storing two time axes for every data point: valid_time (when the fact was true in the world) and transaction_time (when it was recorded in the database).
Blast Radius | The set of all services, functions, and tests that would be affected by a change to a given entity. Computed by traversing DEPENDS_ON, CALLS, and CONSUMES_FROM edges.
Context Budget | A maximum token count for any single KG query response. Ensures AI agents receive focused, affordable context.
CozoDB | An embedded, Datalog-powered graph/relational database used in LeanKG v0.x. Local-first, zero-dependency.
GID | Global ID — a universally unique identifier for any entity in the KG. Format: [org]:[env]:[service]:[type]:[name]:[version].
Graphiti | An open-source temporal knowledge graph framework by Zep AI, built on Neo4j, with LLM-native entity extraction and bi-temporal indexing.
MCP | Model Context Protocol — a standard protocol for AI coding tools (Cursor, Claude Code) to call external tools and retrieve context.
Ontology | A formal, structured description of the concepts, categories, and relationships within a knowledge domain.
Procedural Ontology | The part of the ontology that describes processes, workflows, and sequences of actions (the "how").
Concept Ontology | The part of the ontology that describes entities, categories, and static relationships (the "what").
Progressive Disclosure | A query strategy where high-level context is returned first, with drill-down available for specific nodes to avoid token waste.
Recurrence Fingerprint | A composite similarity score used to match new incidents against past incidents to detect recurrences.
Subgraph | A subset of the full knowledge graph, filtered by entity type, environment, depth, or other criteria.
Temporal Query | A query that retrieves the state of the graph at a specific point in time, enabled by Graphiti's bi-temporal indexing.

## 18.2 References

• LeanKG GitHub Repository: https://github.com/FreePeak/LeanKG

• Graphiti by Zep AI: https://github.com/getzep/graphiti

• Neo4j 5.x Documentation: https://neo4j.com/docs/

• CozoDB Documentation: https://docs.cozodb.org/

• Model Context Protocol Specification: https://modelcontextprotocol.io/

• Tree-sitter Parsers: https://tree-sitter.github.io/

• FastAPI Documentation: https://fastapi.tiangolo.com/

## 18.3 Document Control

Version | Date | Changes
1.0 | May 2026 | Initial PRD draft
2.0 | May 2026 | Added: 3-environment model, Graphiti migration analysis, Procedural Ontology deep dive, Incident Knowledge Loop, Token Efficiency Strategy, Team Contribution Model, full Functional and Non-Functional Requirements, Migration Plan, detailed Roadmap

— End of Document —