Skip to main content

Evolution Policy: The Immutable Pillars

"The Three Pillars do not evolve. They protect the things that do."

The Zenzic Evolution Policy governs how the project changes. Its first principle is that not everything can change — and the Three Pillars are the things that cannot.

1. The Immutability Contract​

The Three Pillars are not preferences. They are the structural requirements of the Safe Harbor. A Zenzic without Pillar II (Zero Subprocesses) is not a faster Zenzic — it is a different tool that has abandoned its trust model.

What "Immutable" Means​

PillarCan Be Relaxed?Consequence of Relaxation
I — Lint the Source, Not the Build❌ NoBreaks the pre-build analysis guarantee
II — Zero Subprocesses❌ NoBreaks the Zero-Trust execution model
III — Pure Functions First❌ NoBreaks reproducibility and auditability

A change that violates Pillar II or Pillar III — even temporarily, even for a well-motivated reason — requires:

  1. A Major version increment (e.g., v0.7.0 → v1.0.0)

  2. A 30-day public impact analysis period

  3. A formal ADR

    added to the Zenzic Ledger

  4. An Adversarial AI session (Type A) against the proposed

    replacement architecture

  5. 2/3 Core Maintainer consensus

This is not a bureaucratic barrier. It is the cost of the trust model. If the change is truly necessary, the 30-day period protects the users who depend on the Pillar.

2. What Can Evolve (Lightweight Procedure)​

Operational Standards — quality gate thresholds, coverage floors, benchmark targets, finding code messages (not semantics) — evolve on a lightweight track:

StageActivityTimeline
ProposalGitHub issue with rationaleDay 0
Debate72-hour window for Core Maintainer objections72 hours
MergeAny Core Maintainer may merge if no blocking objectionDay 4+
Ledger Update[POLICIES] or [ARCHITECTURE] section updated in same commit—

Examples of Operational Standard changes:

  • Raising the coverage floor from 80% to 85%
  • Adjusting mutation score targets
  • Updating a finding code message (text only, not semantics)
  • Adding a new Zxxx finding code in an existing range

3. RFC Template (for Pillar-Level Proposals)​

Any proposal to amend a Three Pillars invariant must include:

  1. Current Text: The exact [INVARIANT] text being challenged.
  2. Proposed Text: The replacement wording, if any.
  3. Rationale: Why the current invariant is architecturally insufficient or harmful.
  4. Cost: What breaks? Which users must migrate? Which ADRs are invalidated?
  5. Alternative Analysis: What alternatives were considered before proposing this?

A proposal without a Cost section and Alternative Analysis will not enter debate.

4. The "Convenience" Prohibition​

"We don't accept shortcuts because of convenience."

The following are not valid rationales for a Pillar amendment:

  • "It's annoying to write pure functions for this rule."
  • "We need to ship this subprocess call now."
  • "The AI proposed a simpler architecture that bypasses Pillar II."
  • "This is a temporary exception."

If a proposed change would be rejected as a pull request by a junior engineer who has read the Zenzic Ledger once — it is not a candidate for the Evolution Policy. It is a candidate for a code review.

5. Emergency Security Exception​

In case of a Critical Security Vulnerability requiring an emergency deviation from a Pillar (e.g., a process isolation call during a zero-day response), Core Maintainers may invoke the Emergency Exception:

  • Suspends one specific invariant for maximum 30 days

  • Requires a logged emergency ADR in the Zenzic Ledger with: invariant suspended,

    security rationale, expiry deadline

  • If restoration is impossible in 30 days → full Pillar Amendment Process begins

    before the deadline expires

The Emergency Exception cannot be invoked for convenience, deadline pressure, or technical debt. It requires a documented CVE or equivalent security incident.

Saga VI: The Governance of Quartz — read the chronicle