Skip to content

Domain Language

Stable language is part of the repository design.

bijux-canon does not just store code. It stores distinctions that need to survive years of review: package contract versus root rule, maintainer automation versus product behavior, and compatibility bridge versus canonical surface.

Language Map

flowchart LR
    terms["stable terms"]
    owners["package, root, maintenance, and compatibility owners"]
    proof["files, tests, schemas, workflows, and metadata"]
    reviews["faster reviews and fewer routing mistakes"]

    terms --> owners --> proof --> reviews

This page should make naming feel structural, not cosmetic. Stable language is what lets a reviewer move from a discussion to the right owner and the right proof without a translation step.

Terms That Should Stay Stable

  • canonical package means one of the publishable bijux-canon-* packages that owns real product behavior
  • repository handbook means the root-level explanation of cross-package structure, governance, and decisions
  • maintenance handbook means the maintainer-facing documentation rooted at docs/07-bijux-canon-maintain/
  • compatibility package means a preserved-name bridge under packages/compat-* that keeps an older or shorter public package, import, or command name pointed at the canonical owner instead of becoming a second implementation home
  • proof surface means the files that let a reader verify a claim, such as tests, schemas, workflow definitions, or metadata

Terms To Avoid

  • do not use root package when the subject is actually repository governance
  • do not use platform as a synonym for any one product package
  • do not use public surface for internal helper code that only supports one package implementation
  • do not use canonical for compatibility material that exists only to bridge older names

Review Consequence

Language drift is an architecture problem. If a reviewer cannot tell whether a change belongs to a package, the root, maintenance tooling, or compatibility material, the names are already failing.

Design Pressure

Language drift looks harmless until ownership discussions start taking longer than the change itself. Once terms stop pointing reliably at real surfaces, the architecture has already started to blur.