Proven Core Extension Boundary

When a component's core correctness is the reason other systems trust it, add capability around that core instead of replacing it. Name the protected internals, keep extension layers outside the boundary, and pay the maintenance cost of restraint.

Problem

Teams need to grow trusted systems. They add networking, pooling, replication, indexing, policy, integrations, or operational controls. The tempting path is to rewrite the awkward core so the new capability feels natural. That can destroy the very property the system was trusted for.

Context

Use this pattern around storage engines, ledgers, identity systems, policy engines, payment rails, protocol stacks, schedulers, or any component whose proven kernel owns durable truth, money, rights, security, or correctness.

Forces

New capability has legitimate product value.
The proven core may be hard to extend cleanly.
Rewriting internals can make short-term work easier.
Correctness bugs in the core are more expensive than extension complexity.
A fork or extension has an ongoing maintenance bill.

Solution

Draw a hard extension boundary around the proven core. State which internals are not to be replaced. Layer new capabilities outside the boundary through protocols, adapters, sidecars, feature gates, storage wrappers, or narrow extension contracts.

Make the cost explicit: upstream tracking, compatibility work, merge obligations, more awkward extension points, and slower experiments are part of the architecture. The constraint is real only if the project continues paying that bill.

Consequences

The system can become more capable without forcing everyone to re-evaluate the correctness of the kernel. The extension layer may be less elegant than a rewrite, but the trusted core remains trusted. The organization gets a clear review question: did this change cross the protected boundary?

Failure Modes

The protected core is named, but feature work edits it casually.
Extension points are so broad that they become a second core.
Upstream merge work is deferred until the fork becomes unmaintainable.
The team treats restraint as conservatism rather than a purchased guarantee.
New capabilities depend on undocumented behavior inside the core.

Proof Points

the trusted core while adding pooling, TLS network access, volume storage, and physical replication around it.

constraint as architecture, not merely preference.

CapDB — keeps SQLite's B-tree, pager, and query planner as
Law II — treats sustained

Full source pattern: proven-core-extension-boundary.md.

Proven Core Extension Boundary