Maturity Stages and Proof Tests

A Settlemint does not assess itself by asking how mature it is overall. It asks which of its functions have been demonstrated, how often, under what conditions, and what would advance each one. This module turns the proof discipline of Claim Is Not Proof and the maturity map of From Community to Network State into working practice: how to place each function on the proof ladder, interrogate it with the proof matrix, record it in an evidence ledger, and run the two tests that expose false institutions.

The governing rule throughout:

A claim names what you intend to be. Proof demonstrates what you can repeatedly do.

And the standard a Settlemint is ultimately held to:

A Settlemint is proved by function in place.

The proof ladder, applied per domain

Every function a Settlemint performs sits somewhere on one progression:

Claim → Signal → Evidence → Repetition → Reliability → Institution

• Claim — we say we can do it.
• Signal — something suggests we may be able to do it.
• Evidence — we did it once or produced a concrete result.
• Repetition — we can do it again.
• Reliability — people can reasonably depend on us doing it.
• Institution — the capability survives individual moments and becomes embedded in durable roles, processes, infrastructure, norms, and systems.

The ladder is applied per domain, not to the whole settlement. Governance may sit at evidence while hospitality sits at reliability and the internal economy sits at signal. Placing the whole project on one rung hides exactly the unevenness the assessment exists to reveal.

The rung must also match the strength of the claim being made:

The strength of the evidence must match the strength of the claim.

One successful vote proves that a vote occurred, not durable governance. One month of occupancy proves temporary habitation, not a durable settlement. When stating where a function stands, state the small precise thing the evidence supports rather than the large category it gestures toward:

Specific proof is stronger than grand language.

The destination of the ladder is not a status to display. It is the point at which others can build on the function:

Civilization becomes credible when critical functions move from claim to institution.

The proof matrix: six questions

For any function under assessment, ask the six questions of the proof matrix (given in full in Claim Is Not Proof):

1. Function — What can it actually do?
2. Frequency — Has it happened once or repeatedly?
3. Reliability — Can people depend on it?
4. Independence — What systems, people, capital, permissions, or subsidies must remain available for it to continue?
5. Legitimacy — Why do the affected people accept the arrangement?
6. Override — Who can ultimately stop, revoke, reverse, or overrule it?

In practice, the matrix is a review instrument. Run it whenever a function is proposed for a higher rung on the ladder, and record the answers rather than the impressions. The Independence and Override answers are the ones most often flattered in self-assessment: a Settlemint's dependence on outside systems is not a failure, but it must be visible rather than hidden.

A map, not one score

Civilizational capacity is multidimensional.

A Settlemint's self-assessment is a profile across domains — the ten functions of a credible Settlemint (people, purpose, membership, habitation, work and production, resource flows, coordination, governance, care, continuity — see Claim Is Not Proof) plus whatever domains its own context adds. Each domain gets its own rung on the proof ladder. The question the profile answers is never "how mature are we?" but:

Which functions have moved from claim to institution, and which remain aspiration?

Two disciplines keep the map honest.

First, keep the axes separate:

Do not force settlement maturity and political maturity onto the same ladder.

A place can be operationally strong while politically ordinary, and a polity can be politically sophisticated while its physical footprint is shallow. From Community to Network State tracks four distinct forms of maturity — social, political, settlement, infrastructure — and this module governs only the settlement and infrastructure axes.

Second, remember that rungs are held, not owned:

Maturity is maintained through repeated function, not awarded forever by one milestone.

A reliable function can become intermittent. A profile that never moves backward is a profile that is not being measured.

The evidence ledger

The instrument that operationalizes all of the above is the evidence ledger: a maintained record of every major claim the Settlemint makes about itself. It is kept as discipline, not as marketing. For each major claim, record six fields:

• Claim — What are we saying?
• Status — Proposed, prototype, pilot, operational, repeated, reliable, or institutional.
• Evidence — What concretely supports the status?
• Dependencies — What outside systems or individuals are required?
• Failure modes — What remains fragile or unproven?
• Next proof — What event or repeated function would advance the claim?

Running the ledger

• One entry per major claim, not per project or per team. "We govern ourselves" and "we operate our own water system" are separate entries with separate evidence.
• Status follows evidence, never ambition. An entry advances only when the recorded evidence supports the higher status — and the category should be conceded last, not claimed first: the proof should earn the name.
• The Next proof field drives the work. Each entry names the concrete event or repeated function that would advance it; that is the settlement's actual maturity agenda, ahead of any roadmap language.
• Record failure in the ledger. If participation collapses, if infrastructure requires constant founder intervention, if an economic loop works only while subsidized, if the community cannot survive disagreement — those are material facts and they belong in Evidence and Failure modes. Failure does not automatically invalidate the project; concealing it does.

A system that can see its failures can improve. A system that turns every failure into narrative cannot learn.

A worked entry

The ledger entry for ATX, a genesis Settlemint in formation (see its fuller treatment in the ATX chapter):

Claim: ATX is becoming a Settlemint.

Status: Formation and pilot.

Evidence: Real land, real people, recurring activity, infrastructure restoration, capital, shared work, and institutional relationships.

Not yet proved: Durable governance, persistent economic loops, mature membership, reliable resource systems, integrated infrastructure, and long-term continuity.

Next proof: A recurring shared function that moves from ad hoc founder-led coordination into a reliable community institution.

This entry is more credible than declaring ATX a completed Settlemint — and that is the point of the instrument.

Two practical tests

Two tests deserve to be run explicitly and regularly, because they detect the most common false positive: a function that looks institutional but is not.

The founder-dependence test

What stops working when the founder leaves the room?

Early projects naturally depend on founders; that is not the problem. The problem is claiming that an institution exists when the capability still resides almost entirely in one person. One way to apply it: have the founder step back from a function and observe what continues. A function is becoming institutional as:

• knowledge is shared,
• roles become clear,
• authority becomes legible,
• processes repeat,
• resources remain available,
• and correction no longer requires constant founder intervention.

Passing this test does not eliminate leadership. It proves that leadership has built capacity beyond itself.

The continuity test

Continuity is repeated function under changing conditions.

Many systems work briefly. For each function, ask:

• Does it work after launch attention fades?
• Does it work during conflict?
• Does it work when money becomes tighter?
• Does it work when leadership changes?
• Does it work when infrastructure fails?
• Does it work when people disagree?

A function that has only ever operated under favorable conditions may have demonstrated repetition rather than reliability. The changing conditions are not obstacles to the assessment — they are the assessment.

Minimum viable and mature profiles

Minimum viable Settlemint

The phrase is useful only if it prevents overclaiming: a place does not qualify merely because it has land and internet access. The current working threshold:

A persistent community inhabits a real place, shares a purpose, can make and execute decisions, coordinates real economic or productive activity, operates meaningful infrastructure, preserves institutional memory, and demonstrates durable capacity to continue.

One way to read this threshold in ladder terms: the core functions have each happened more than once and show some capacity to keep happening. That mapping is a working interpretation, not settled canon. It remains a working threshold, deliberately qualitative: high enough to mean something and simple enough to apply.

The mature profile

A mature Settlemint is not one that has added more amenities. Maturity, per the published progression, is critical functions moving from claim toward institution — greater reliability, integration, legitimacy, and resilience — not a stage awarded forever by one milestone. On the settlement-maturity axis this is the movement from Site → Occupied Place → Settlement → Settlemint → Mature Settlemint described in From Community to Network State.

Not every Settlemint must provide every function internally, and maturity does not mean autarky. What maturity requires is that dependence be visible rather than hidden, and that the domains the settlement does claim be operated in fact. The orienting question for any domain remains: what can this place actually do for itself?

On numbers

No exact quantitative thresholds are given for any stage, rung, or profile in this module — how many residents, what treasury volume, how many months of continuity — because none have been established. The canon's rule is explicit: do not force false precision before deployments create real data. Exact thresholds for each maturity stage remain open questions, to be answered by the evidence ledgers of real Settlemints, beginning with ATX. Until then, a Settlemint states its maturity in the precise, testable, domain-specific terms its own ledger supports.

The line to carry

Do not ask what it calls itself. Ask what it can repeatedly do.

A Settlemint that keeps its ledger honestly, maps its maturity by domain, and runs its proof tests under real conditions does not need to argue about its category. The proof accumulates, and the category follows.