The Living Architecture Assurance Framework (LAAF)
Most implementation failures in large enterprises are not coding errors — they are knowledge failures. Nobody holds a complete, queryable picture of how systems interact, what data crosses each boundary, what business logic governs it, and what breaks if you touch any piece. LAAF addresses this by treating every system, interaction, and configuration component as a living asset.
6
Entity types in the metamodel
8
Lifecycle states per asset
5
Adoption phases
14+
Regulatory frameworks addressed
Key takeaways
The architecture description is the system of record — not an after-the-fact artifact.
Every asset is living: created when proposed, versioned through change, preserved when retired.
An AI-augmented Integrity State continuously assesses the health of the full ecosystem graph.
Five adoption phases take organisations from diagram to governed, continuous change management.
"
Most implementation failures in large enterprises are not coding errors — they are knowledge failures. Nobody holds a complete, queryable picture of how systems interact.
1. The Core Idea
LAAF is built on a single premise: the architecture description is the system of record — not an after-the-fact artifact. It is the single source of truth you get three things from at once: a delivery framework, a change-impact engine, and a self-service knowledge base.
Why this matters
Every asset is created when proposed, evolves through implementation and operation, carries its full version history, and only 'dies' when formally retired. Nothing is deleted. Everything is versioned.
2. The Metamodel — Six Entity Types
LAAF reduces to six entity types and a small set of typed relationships. This is what makes it generic — any SaaS provider or enterprise can model their ecosystem with the same primitives.
System / Application
A deployable unit of software, internal SaaS, or data source. e.g. Core banking platform, Bloomberg feed.
Interaction (directed edge)
A flow of data or control between two systems — with field mappings, rules, SLA, and classification.
Configuration Component
A configurable capability inside a system. Can itself be an endpoint of interactions.
Field
An atomic data element reusable across interactions. Carries type, sensitivity, and owner.
Business Logic Rule
A reusable rule: validation, transformation, routing, reconciliation, enrichment.
Dependency
A typed relationship asserting that one asset relies on another. Enables impact analysis.
3. The Lifecycle — Why Assets Are 'Living'
Every asset moves through a single state machine — accruing history from the moment it is proposed until retirement.
1
PROPOSED
Captured during discovery
Skeletal definition only. The asset exists and starts accumulating history.
2
DESIGNED
Fields and logic defined
Fields, business logic, and dependencies defined. Ready for baseline review.
3
BASELINED
Reference truth established
Reviewed and approved. First integrity baseline computed. This is the anchor.
4
IN_BUILD / IN_TEST
Implementation underway
Spec and reality are converging. Change requests tracked against the baseline.
5
LIVE
In production
The default steady state. Every LIVE interaction is continuously integrity-checked.
6
CHANGE_IN_PROGRESS
Controlled change open
Locked for controlled edit. Maker-checker approval required to advance.
7
DEPRECATED
Slated for removal
Still live but no new dependencies may be added. Triggers integrity warnings.
8
RETIRED
History preserved
No longer counts toward the live Integrity State. Fully auditable indefinitely.
Lifecycle isn't cosmetic
It drives access control, integrity checks, and approval gates. A LIVE interaction depending on a DEPRECATED component is an immediate integrity finding — not something discovered during an audit.
4. Versioning and Audit — Append-Only by Design
Editing an asset never overwrites — it creates a new version. Each version records the author, timestamp, change summary, rationale, and a structured diff of what changed.
"
Point-in-time reconstruction is a first-class capability. You can ask 'what did this interaction look like at go-live?' and get a complete, field-level answer — even years later.
5. The Integrity State — AI-Augmented Assurance
The Integrity State is a continuously computable health assessment of the entire ecosystem graph — combining deterministic rules with AI semantic reasoning.
Deterministic checks
Completeness — every LIVE interaction has at least one field mapping
Connectivity — no orphaned systems or broken endpoints
Dependency integrity — no circular cycles, no retired dependencies
Field-type consistency across exchanging systems
AI-augmented checks
Semantic field drift — same concept, inconsistent representation
Business-logic contradictions across related flows
Hidden coupling — dependencies implied in text but never modeled
Control gaps — high-risk data with no stated control
Documentation drift — narrative no longer matches modeled fields
6. The Adoption Model — Five Phases
DISCOVER
Capture systems as PROPOSED assets. The diagram is the deliverable.
DEFINE
Fill fields, logic, and dependencies. The model becomes queryable.
BASELINE
Review, approve, compute the first Integrity State. The reference snapshot.
OPERATE
Run delivery. Assets move PROPOSED → IN_BUILD → LIVE. Every change tracked.
GOVERN
Continuous change management and integrity monitoring for the life of the ecosystem.
See the Living Architecture Assurance Framework in practice
Ralyio implements the full LAAF metamodel — map your first domain in minutes.