Lensmethodology · language · rules · design
r4n/meta
// 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
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.
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.