Mneme HQ solves the legacy codebase problem by capturing undocumented constraints, anti-patterns, and tribal knowledge in a structured decision store that AI coding assistants query before generating code. When an assistant proposes code that violates a hidden constraint — touching a deprecated adapter, bypassing a required flag, or ignoring a fragile dependency — Mneme HQ surfaces the violation before damage is done. Memory tools recall context. Mneme governs implementation.
Reference Architecture · Simulated Scenario

# Using Mneme HQ to Preserve Tribal Knowledge in Legacy Codebases

The senior engineer bottleneck, solved. Give every coding assistant access to the undocumented rules that only your longest-tenured engineers know.

Install Mneme HQ View GitHub
The Problem

## Legacy codebases run on invisible rules.

Never call the billing adapter directly. Always use feature flags for payment changes. The v1 auth middleware was quietly deprecated in 2021 — use v2. These rules exist only in Slack threads and the memory of senior engineers.

When a coding assistant generates code for a legacy system, it works from the code it can see — not the rules it can't. The result is PRs that break things that "everyone knows" shouldn't be touched.

Without Mneme HQ — assistant suggests:
Prompt: "Add a payment method to checkout"
I'll update the checkout controller to call the PaymentAdapter directly and process the charge...
With Mneme HQ — pre-flight check:
mneme check --mode strict
✗ FAIL decision/no-direct-billing-adapter
Rule: Never call BillingAdapter directly from controllers.
Context: Direct calls bypass audit logging. Route through PaymentService only.
See: decisions/billing-adapter-constraint.yml
✗ FAIL decision/feature-flag-required-payments
Rule: All payment code changes require a feature flag.
Context: Required for staged rollout and emergency disable.
→ Surfaced 2 violations before code generation.
Why Existing Tools Fall Short

## Tribal knowledge can't be captured in docs or linters.

Approach | Limitation | With Mneme HQ
--- | --- | ---
Onboarding docs | Describe architecture, not constraints; go stale; not queryable | Decisions are structured, retrievable, and enforced
Senior engineer review | Bottleneck; not scalable; knowledge is lost when they leave | Tribal knowledge is captured once, enforced forever
Code comments | Only in files that exist; scattered; not surfaced at prompt time | Centralized decision store surfaced before code is written
Linters / static analysis | Catch syntax/style violations; can't encode business reasoning | Captures intent and rationale, not just syntax rules

How Mneme HQ Solves It

## Capture once. Enforce forever.

1

#### Document hidden constraints as decisions

Capture the rules that live only in senior engineers' heads: deprecated paths, required wrappers, fragile integrations.

2

#### Run `mneme check` before prompting

Pass your intended change through Mneme HQ. It retrieves relevant hidden constraints and flags any violations before the assistant generates a single line.

3

#### Generate assistant-specific rules files

`mneme cursor generate` distills your decision store into a compact rules file every assistant session loads automatically.

4

#### Gate CI on decision compliance

Add `mneme check --mode strict` to CI. PRs that violate legacy constraints fail before review — no senior engineer required.

Technical Implementation

## What capturing tribal knowledge looks like.

decisions/billing-adapter-constraint.yml

    id: no-direct-billing-adapter
    title: Never call BillingAdapter directly from controllers
    status: accepted
    rule: All billing operations must go through PaymentService.
    rationale: Direct calls bypass audit logging required for SOC 2.
      Discovered after billing incident in Q3 2023. See post-mortem PM-12.
    enforcement: strict
    tags: [legacy, billing, audit, anti-pattern]

Terminal — mneme check output

    $ mneme check "add a payment method to checkout" --mode strict

    Retrieving relevant decisions... (4 matched)

    ✓ PASS decision/use-paymentservice-wrapper
    ✓ PASS decision/checkout-idempotency-required
    ✗ FAIL decision/no-direct-billing-adapter
      Reason: Prompt implies direct BillingAdapter call from controller context.
    ✗ FAIL decision/feature-flag-required-payments
      Reason: Payment change detected; feature flag wrapping required.

    Result: FAIL (2 violations, strict mode)

Bulk capture session — 30 minutes with a senior engineer

    # Interview format: "What should no one ever touch directly?"
    # Each answer becomes a decision YAML.

    $ ls decisions/
    billing-adapter-constraint.yml
    v1-auth-deprecated.yml
    feature-flag-payments.yml
    never-delete-user-rows.yml
    sidekiq-queue-naming.yml
    legacy-mailer-wrapper.yml  # 6 decisions captured in one session

Simulated Outcome

## What happens after tribal knowledge is enforced.

6
undocumented constraints captured in first 30-minute session
100%
of captured constraints enforced automatically in CI
~0
legacy violation PRs after enforcement goes live
⚠ These figures are based on a simulated reference scenario — not live customer data.
FAQ

## Common questions.

We have thousands of undocumented rules. Where do we start?
Start with the last 5 PRs that had review comments like "we don't do it this way". Convert those comments into decisions. You'll cover ~80% of common violations in under an hour.
What if a constraint changes?
Update the YAML. You can set `status: deprecated` on a decision to disable enforcement without deleting the history. The decision record remains as context for why the rule existed.
Does this work without good test coverage?
Yes. Mneme HQ is a pre-flight layer on top of prompting — it doesn't require test coverage to enforce decisions. It operates before code is written, not after.
Can we import from existing ADR documents?
Manual migration takes 2–3 minutes per decision. A future importer is on the roadmap. For now, treat existing ADRs as source material and transcribe the key rule and rationale into YAML.
Related Use Cases
Coding Assistant Governance → Security & Compliance Guardrails → Multi-Agent Workflow Governance →