The Doctrine–Implementation Boundary

A system becomes unsafe when definition and operation collapse into one unexamined authority.

Doctrine Industries therefore separates two powers.

Doctrine authority

Doctrine authority determines:

• what a system is;
• which terms are canonical;
• which states and transitions are admissible;
• what evidence is required;
• where authority begins and ends;
• which version governs;
• and how conflicts are recorded.

Implementation authority

Implementation authority determines:

• how an approved specification is realised in software or process;
• which technical components are selected;
• how performance, reliability, and security are achieved;
• how releases are built, tested, deployed, and operated;
• and how implementation incidents are contained.

Nilsoft ordinarily owns this implementation surface for Nilsoft-delivered systems.

The boundary contract

An implementation conforms when it can identify:

1. the governing specification and exact version;
2. the implemented requirements;
3. any deliberate deviations;
4. unresolved ambiguities;
5. evidence produced by verification;
6. the operating authority accepting the release.

A prototype may explore beyond doctrine, but it must not silently redefine the canonical system. A specification may require a capability, but it must not claim that the capability is operational before implementation evidence exists.

Change direction

Change may travel in either direction:

Doctrine change → implementation migration
Implementation discovery → doctrine amendment proposal

Neither direction is automatic. Both require an explicit record.

Consequence

This boundary permits Doctrine Industries to remain intellectually authoritative without becoming an unbounded operator. It permits Nilsoft to move quickly without allowing implementation convenience to become institutional law.