// C5 MODEL · AN R4N FIELD GUIDE

Five concerns.
One order.

C5 is an opinionated cross-section of an IT ecosystem. It groups systems by what they make possible, then turns dependency into a build and recovery sequence that an operator can actually test.

It is not a maturity ladder, a product catalog, or a claim that every system fits neatly on the first pass. It is a shared map for deciding what belongs where—and what must exist first.

c5.cross_section semantic zoom · 48 component types

Select a concern to reveal its component types.

01 / FOUNDATION

Core

The machine-to-machine substrate: identity, secrets, scheduling, networking, name resolution, PKI, and observability.

depends on: physical substrate and genesis authority
phase proof: identity, scheduling, DNS, edge, and telemetry respond

Component types describe roles, not deployment state. Named products are reference implementations or tracked candidates; this explorer is not a live service inventory.

// DEPENDENCY MADE VISIBLE

Build from the base.
Restore by proof.

The order is the model’s load-bearing claim. Each phase establishes the conditions and evidence the next phase needs. During total recovery, progress is measured by working effects—not completed commands.

01
Corethe ecosystem can identify, schedule, resolve, observe, and route
02
Commsan alert arrives and a remote operator can reach an internal service
03
Contentdurable data is present; a fresh write and read succeeds
04
Collaba person signs in and completes a real smoke action
05
Compliancecontrols, evidence, recovery posture, and adversarial probes agree

// THE MODEL AROUND THE MODEL

C5 is one cut through a larger system.

C5 partitions the infrastructure modules. Code Components says where the reusable method, tooling, implementation, and operator-specific declarations live. Keeping those two ideas separate is what makes the system portable.

Lensmethodology · language · rules · design

r4n/meta

Toolingthe software that executes the method

r4n/stack

Infrastructure modules C5 lives here

CoreCommsContentCollabCompliance

r4n/it-*

Ecosystem configthis operator’s entities, intent, topology, and bindings

r4n/it-config

// INFRASTRUCTURE + INFORMATION AS CODE

C5 tells us where.
Flows tell us why.

The current R4N direction extends the map without replacing it. Products compose independent Components across C5. Environments bind those Components to real deployments, actors, interfaces, policy, and evidence. Information Flows describe the outcomes that cross layer boundaries.

declare Intent outcomes · actors · constraints

realize Deployment components · environment · location

verify Evidence effects · freshness · acceptance

declaration realization proof

// DECISION TRACE · MAY—AUGUST 2026

Researched from the work, not reconstructed from memory.

Canon

Methodology, glossary, the accepted ordering ADR, context map, DR runbook, and brand geometry.

Implementation contexts

All five layer boundaries, their contracts, consumers, dependencies, and explicit planned-versus-shipped state.

Decision history

Gitea issue and pull-request history from the original C5 split through the v0.2 Product, Environment, and Info-as-Code decisions.

Drift handling

Contradictions were resolved by the project’s authority order and preserved as findings, not silently blended into the story.

This is a public explainer of an evolving methodology, not a claim that every planned module is deployed. Alert-zero remains the design target; ecosystem-wide alert coverage is still being completed.