The 18-Pillar Doctrine: Building Unbreakable Software Systems

Why 18 Pillars?

Most software projects rely on a handful of linting rules and a CI pipeline to catch

defects. The Prismatic Platform takes a fundamentally different approach: we define

18 interconnected quality pillars that cover every dimension of software

engineering, from architecture decisions to commit message formatting.

Each pillar has a clear acronym, a set of banned patterns, and an enforcement level

ranging from advisory to blocking. Together, they form a doctrine that eliminates

entire categories of bugs before code ever reaches production.

The Pillar Taxonomy

The 18 pillars fall into four groups: Architecture, Execution,

Permanence, and Operations.

Architecture Pillars

3NL (Three Nested Loops): Every session operates three layers simultaneously

-- logic, neural, and linguistic. This ensures that AI-assisted development

maintains context across reasoning, pattern recognition, and communication.

FLLM (Flowbite LLM): CSS hygiene enforcement. No inline style= attributes,

no <style> blocks, no custom CSS class definitions. All styling must use

Tailwind utility classes or Flowbite components.

PERF (Performance Engineering Runtime Fence): Bans N+1 queries,

unbounded Repo.all calls, length/1 for emptiness checks (O(n) vs O(1)),

and blocking operations inside async handlers.

Execution Pillars

NMND (No Mercy, No Doubts): Zero tolerance for incomplete implementations.

No stubs, no mocks in production code, no placeholders. Every function must be

fully implemented.

M5M (Max 5 Minutes): All tasks must decompose into steps of five minutes or

less. This prevents scope creep and forces granular progress tracking.

TACH (Total Assurance Comprehensive Hardened): Every lib/*.ex module must

have a corresponding _test.exs file. Pure modules require property-based tests.

LiveView changes require E2E tests.

ZERO (Zero Error Runtime Operations): Bans String.to_atom/1 (atom table

exhaustion), bare rescue blocks (swallowed errors), and unsafe

:erlang.binary_to_term/1 without the :safe option.

SEAL (Security Enforcement Absolute Lock): Prevents SQL injection via string

interpolation in Ecto fragments, hardcoded secrets, and Code.eval_string/1

with user input.

Permanence Pillars

NWB (No Way Back): Every solution must be permanent. No temporary hacks,

no backwards compatibility shims. Clean breaks over compatibility layers.

NCLB (No Claim Left Behind): Every platform claim (agent count, test count,

app count) must be backed by verifiable evidence collected at runtime.

DEPS (Dependency Engineering Protection Standard): Version constraints

mandatory on all dependencies. No unstable git branches. Override dependencies

require written justification.

Operations Pillars

DOCS (Documentation Omnipresent Comprehensive Standard): Every module needs

@moduledoc. Every public function needs @doc, @spec, and an iex> doctest.

OTEL (Observability Telemetry Enforcement Layer): GenServers must emit

telemetry events. Controllers must log requests. Rescue blocks must log errors.

GITL (Git Integration and Traceability Linkage): Commits must follow

conventional commit format (type(scope): description).

KNOW (Knowledge Coverage): New modules should have glossary entries.

Academy topics are advisory but tracked.

RDME (README Enforcement): Every umbrella app must have a README.md with

parent navigation links and a standard structure.

NLLB (No Link Left Behind): All internal documentation links must resolve

to existing files. Broken links are detected by pre-commit hooks.

HYGIENE (Repository Hygiene): Enforces clean repository state, prevents

stale files, and validates archive integrity.

Enforcement Levels

Not all pillars block commits. The enforcement matrix has three tiers:

TierPillarsBehavior

|------|---------|----------|

BlockingZERO, SEAL, PERF, HYGIENE, NMND, TACH, DOCS, DEPS, RDMEPre-commit hook rejects commit AdvisoryFLLM, OTEL, GITL, NCLB, KNOW, NLLB, M5M, NWBWarning printed, commit proceeds CI-onlyAll 17 enforceable pillarsmix check.doctrines in CI pipeline

Living Enforcement

The doctrine is not static. New pillars are added when recurring defect patterns

emerge. HYGIENE was added as the 18th pillar after repository cleanliness issues

were identified. The enforcement level of each pillar is reviewed quarterly and

promoted from advisory to blocking as tooling matures.

This systematic approach means that the Prismatic Platform does not rely on

individual developer discipline. The system itself prevents defects.