Investigation 033 · Platform Evolution Principles

The Admission
Problem

“A boundary that only records what crosses it has not yet decided what may cross it.”

How to Read This Investigation

Representation and convergence already exist.

INV-031 made resource kinds extensible. INV-032 let independently owned automation converge accepted state. This investigation stays before both execution and convergence: it asks what may become authoritative at all.

We begin with every rule inside the platform core, move one responsibility outward, and let the pressures of latency, staleness, silence, and disagreement expose what that move costs.

Well-formed state is not necessarily acceptable state.
The Mystery

Understood is not the same as acceptable.

The database team proposes ReplicatedDatabase orders-production with replicas = 3. Every structural check succeeds — the platform understands the proposal perfectly. The production reliability team's rule requires at least five replicas for a production database. Both conclusions are true.

Foundation

The platform already knows how to validate structure — INV-031 established that a well-formed proposal can be recognized and advanced toward the authoritative write boundary.

Assumption

If the proposal is structurally valid, nothing else should need to stand between it and authoritative state.

Incident

The reliability team's rule requires at least five replicas. The proposal requests three. The platform's approval and the rule's refusal are both true at once.

The resource definition cannot absorb this rule without changing what structural conformance means. The domain automation from INV-032 cannot enforce it either — that automation begins from authoritative desired state, and no authoritative orders-production resource exists yet.
Mystery: who may decide whether a proposal the platform understands is allowed to become a fact the platform must preserve?
First Principles

Five questions hide inside the word "accept".

The prologue produced two truthful statements about one proposal: the platform can represent it, and the production rule does not permit it. Untangling accept requires separating what can be represented from what is permitted, from what exact state was judged, from who judges it, and from who may change the authoritative record.

Structure

Can the platform represent the proposal under its declared shape? INV-031 already answered this.

Acceptability

Do the relevant organizational rules permit it? An independent claim from structure.

Candidate

What exact proposed state was evaluated — C0, not whatever it becomes next?

Decision owner

Who judges the rule? Owning a judgment does not grant ownership of authoritative history.

Final authority

Who performs the one transition from the current authoritative version to the next?

Deferred question: can a correct decision expire? A rule may depend on an observation outside the candidate — an approval, a report, an external fact. The decision was honest when made; its supporting observation can grow stale before commit even while the candidate itself stays byte-for-byte unchanged. The architecture cannot yet say what that expiry should mean — only that it is not the same failure as an incorrect judgment.
The Smallest Design

Check every request inside the platform core.

The same request path checks structural conformance, applies organizational rules, and writes accepted state. Structure runs first — a reliability rule should not have to interpret a malformed replicas field — then the reliability, security, and finance rules the platform team also owns, then the inherited version check and commit. One owner, one release train, and a small rule set make this coherent.

Proposalreplicas = 3
Platform Coreschema + every rule + write
Authoritative Stateaccepted or unchanged

Why it works

Aligned ownership keeps policy, implementation, release, and operational consequences in one understandable boundary.

Synchronous and coherent

No candidate becomes authoritative while a required check remains unfinished.

The untested assumption

Every rule will continue to change for the same reasons and on the same schedule as the platform.

The Architecture That Almost Worked

Move the rule outward. Wait for its answer.

Only the production replica rule moves. The platform still checks structure, still owns the inherited version check and write, but presents a bounded decision request — resource kind, name, environment, proposed fields — and expects back only permit or refuse with a reason. The participant never touches the platform's private object model.

The rule owner can change its implementation without changing platform source, but the participant still ships on the platform-managed release train. The correctness-critical write path also waits synchronously on that participant.

What it preserves

Everything else stays put. Structural checks, the inherited version check, and the authoritative write remain exactly where they were — only the production replica rule moves.

What it assumes

A bounded request is enough independence. The reliability team can change its rule behind a public boundary. We have not yet tested who must control its release when platform and rule-owner conditions diverge, or what happens when it is slow, silent, or judging a candidate that has since changed.

Implementation ownership moved. Release ownership and write-path dependence did not.
Breaking Our Design

Run each pressure independently.

Episode 01 begins from the almost-working design. Each later pressure unlocks only after the preceding discovery creates its reason to exist, while every experiment keeps independently resettable state.

EPISODE 01

The Rule That Needed Its Own Release

Can the security team change its registry rule while the platform release remains frozen?

OwnershipSecurity authors; platform releases
ReleaseAvailable
Rule statusPartner registry permitted

Establish the shared release boundary.

EPISODE 02

The Slow Policy That Blocked Everyone

What happens when one separately operated participant delays a high-volume synchronous path?

RequestsNot measured
EvaluationsNot measured
Write pathClear

Establish request volume before delaying a participant.

EPISODE 03

The Decision That Expired Before Commit

Does an unchanged candidate keep a truthful decision current when its supporting evidence changes?

CandidateC0
EvidenceNot observed
DecisionNone

Present C0 to the release participant.

EPISODE 04

The Participant That Did Not Answer

What can the platform truthfully infer when a required ownership result never arrives?

ParticipationNot requested
EvidenceNone
DispositionImplicit

Require an ownership judgment.

EPISODE 05

The Policies That Disagreed

Can a permission for C0 authorize C1 after another participant transforms the proposal?

Current candidateC0
A judgmentNone
C judgmentNone

Present C0 before collecting candidate-bound results.

Review the five experiments
    The Turning Point

    Judgment may be independent.
    Authority remains singular.

    The five failures did not describe five unrelated bugs. They exposed the conditions a pre-commit boundary must preserve: independent release cadence, synchronous write-path dependence, observation age, explicit disposition instead of silence, and results that never outlive the exact candidate they judged.

    Isolated Candidatenon-authoritative Cn
    Platform Compositioncandidate-bound results · final validation
    One Commitversion checked · platform owned
    The Request Admission Contract

    Independent judgment without distributed authority.

    The platform needs independently owned judgments before commit, but it cannot delegate the meaning of candidate identity, the composition of results, or the transition into authoritative state. Eight obligations hold that boundary together.

    Responsibility 1 — Candidate isolation

    Proposed state remains non-authoritative throughout evaluation and transformation.

    Responsibility 2 — Stable participation

    Participants receive bounded candidate data and declared context, not private platform internals.

    Responsibility 3 — Candidate-bound results

    Every result applies only to the exact candidate and bounded evidence evaluated.

    Responsibility 4 — Explicit disposition

    Every required participation reaches a declared outcome before commit. Silence decides nothing.

    Responsibility 5 — Platform composition

    The platform deterministically combines transformations and decisions.

    Responsibility 6 — Final validation

    Structure and every required final-state disposition apply to the candidate actually committed.

    Responsibility 7 — Single transition

    The platform performs one inherited version-checked authoritative commit, or none.

    Responsibility 8 — Bounded effects

    Participant side effects are not atomic with the authoritative platform commit.

    Architecture, not policy. The contract requires explicit dispositions and candidate fidelity. Timeout values, retries, cache duration, policy language, and iteration limits remain policy or mechanism.

    Candidate, decision, and authority remain three separate things. The architecture must never let one silently stand in for another.

    Only Now: Kubernetes

    Admission realizes the pre-persistence boundary.

    The API server owns the request path and authoritative write. Built-in admission controllers and independently operated admission webhooks contribute bounded mutation or validation results without becoming authoritative writers. Mutating admission runs first and may transform the candidate; validating admission then judges the resulting candidate — mirroring the composition-then-final-validation sequence this investigation derived.

    API Requestcandidate under evaluation
    Admissionmutating then validating participation
    API Persistenceone authoritative write or none

    Mutation

    Mutating webhooks may transform the candidate before validation runs.

    Validation

    Validating webhooks and built-in controllers judge the resulting candidate; none becomes an authoritative writer.

    Disposition

    failurePolicy (Fail or Ignore) turns an invocation failure into a declared outcome instead of silent uncertainty.

    Failure remains declared. An explicit refusal differs from an invocation failure. Configuration such as failurePolicy realizes a chosen disposition; it does not explain why a participant did not answer. This does not cover authentication, RBAC authorization, or which specific organizational rules should exist — those are separate mechanisms this investigation does not decide.
    Bind every judgment to
    the state it actually judged.

    Keep checks integrated

    • One team owns platform and rules
    • Release lifecycles remain aligned
    • Rules are few and candidate-local
    • One operational boundary is preferable

    Separate participation

    • Rule ownership and release cadence diverge
    • Public semantics replace private dependency
    • Candidate identity must remain explicit
    • Write-path dependence is accepted deliberately
    Architectural Honesty

    Keeping every rule inside the platform core remains the better architecture when one team owns the platform and its rules, release lifecycles stay aligned, the rule set is small and candidate-local, and one operational boundary is genuinely preferable to several. Independent participation is not free: it adds latency, availability risk, and operational surface that must be justified by rule owners whose reasons for change have already diverged from the platform's own.

    Costs Accepted

    Latency

    Required evaluation adds synchronous work before commit.

    Availability

    An independent participant can delay or prevent completion.

    Re-evaluation

    Transformations can invalidate earlier final-state judgments.

    Composition

    The authority owner must preserve deterministic candidate semantics.

    Operations

    Independent participants must be deployed, observed, and recovered.

    Reduced writes

    Incomplete required dispositions produce no authoritative transition.

    These costs are accepted only when independent rule ownership is worth more than one synchronous, tightly coupled request path.

    Investigation Exercise

    Which candidate did the decision authorize?

    Track one proposal through mutation, judgment, and commit. Label every candidate it becomes, every participant that judges it, and the single authority that performs the final transition.

    Prediction

    Does A's permission for C0 authorize C1 after B transforms it?

    Experiment

    Label each candidate, transformation, judgment, and authority transition.

    Observation

    A's truthful C0 result has no authority over C1.

    Reflection

    Identify who composes, validates, and commits the final candidate.

    ● ● ●
    Earn the admission contract to unlock this trace.
    Admission Ends

    Several destinations are feasible.
    Which one preserves finite capacity?

    The proposal crossed one governed authority boundary.

    The accepted desired state is now authoritative.

    INV-014 already established correctness filtering and placement.

    Feasible choices can still have different economic consequences.

    An isolated candidate passes through candidate-bound judgment and one platform-owned commit before several feasible destinations expose the unresolved economic comparison problem
    How should feasible placements be compared without treating economic preference as truth?

    Intellectual Lineage

    This investigation inherits the authoritative history and concurrency contract from INV-007 and INV-009, and the extensible resource and automation boundaries from INV-031 and INV-032. Separating a correctness-critical decision from the party who owns it is a long-standing distributed-systems pattern: participants may judge or object to a proposed transition while one authority retains responsibility for the commit. Kubernetes admission control is one realization of the broader Request Admission Contract derived here; this investigation does not claim that admission control invented candidate-bound, pre-commit judgment.

    Deliberate Simplifications Ledger

    Finite-capacity economics for accepted workINV-034
    Fair access among competing accepted workloadsINV-036
    Disruption from later changes to accepted workINV-038

    Sources