Permanent concepts
The canonical definitions behind StackWeaver's trust infrastructure category. Each term answers: what it is, why it matters, how StackWeaver applies it, and what it relates to. These pages rarely change — they are reference definitions, not blog posts.
Why a Library
Compliance vocabulary drifts. "Continuous compliance" means one thing to a GRC vendor and another to an engineer. The Library fixes meaning: each concept is defined once, canonically, and every other page on the site links to it rather than redefining it. That is how a knowledge graph stays coherent as it grows past 500 pages.
How to read it
Start from Trust Infrastructure — the umbrella concept — then follow the related links outward into frameworks (TEOM, TEMM, Evidence Architecture) and capabilities (Compliance Engineering, Evidence-Native Systems). Each entry closes with a "related" trail into Solutions, Research, and Evidence.
What it is not
The Library is not the blog and not the research desk. It does not argue a position or report a finding; it defines. Evolving analysis — the State of Trust Infrastructure report, platform evaluations, the automation-vs-consulting debate — lives in Research.
The StackWeaver perspective
Every definition here is written from one stance: compliance is infrastructure, not theatre. A control that cannot produce evidence of its own operation is not a control. That conviction runs through every term below and into the platform that operationalises them.
Foundational
Trust Infrastructure
The market category StackWeaver operates in: technology able to continuously demonstrate that it can be trusted, not just claim it.
Trust Engineering
The discipline of designing, building, and operating systems so that trust is a measurable, continuously-produced output of engineering work.
Operational Trust
Trust that is demonstrated by how an organisation operates day to day, continuously evidenced, rather than asserted through certificates.
Frameworks
StackWeaver's core frameworks: how trust infrastructure is run (TEOM), how maturity is measured (TEMM), and how evidence is created, connected, and verified (Evidence Architecture). These canonical models ground every practice and solution on this site.
Evidence Architecture
The three-layer model for how compliance evidence is created, connected, and consumed: Created & Captured → Stored & Connected → Verified & Consumed.
Trust Engineering Operating Model (TEOM)
StackWeaver's five-pillar operating model for running Trust Infrastructure: Build, Validate, Observe, Govern, Improve — all resting on Stewardship, the human accountability layer.
Trust Engineering Maturity Model (TEMM)
A six-level model (0–5) measuring how continuously an organisation generates compliance evidence, from Undocumented to Adaptive.
Practice
Compliance Engineering
Treating compliance as something built into systems through engineering — enforced, tested, and monitored — rather than added through documentation.
Continuous Compliance
A state in which compliance evidence is generated and verified continuously, so readiness is always current rather than reconstructed for each audit.
Compliance-as-Code
Expressing compliance controls and policies as versioned, testable code in the engineering pipeline.
Compliance Automation
The use of software to collect evidence, enforce controls, and monitor compliance state with minimal manual effort.
Engineering Controls
Controls implemented and enforced through engineering systems — configuration, code, and automation — rather than through policy and manual process.
Audit Readiness
The state of being able to satisfy an audit or due-diligence request on demand, with current, mapped, and verifiable evidence.
AI Compliance
The discipline of governing AI systems — model risk, data provenance, and human oversight — with the same engineered, evidenced controls used for traditional compliance.
DevSecOps Compliance
Embedding compliance controls and evidence capture directly into the software delivery pipeline, so security and compliance are properties of shipping, not gates before it.
Systems
Evidence Object
A single, verifiable record of correct operation, captured at the source and mapped to one or more controls.
Evidence Package
A scoped, auditable collection of Evidence Objects mapped to a specific framework, engagement, or stakeholder request.
Evidence-Native Systems
Systems where compliance proof is a property of how they operate — captured at the source — not a document produced under deadline.
Evidence Intelligence
The analysis layer over collected evidence that surfaces coverage gaps, control drift, freshness, and readiness — turning raw records into decisions.
RegTech Africa
The regional market and practice of using technology to meet African regulatory obligations — CBN, NDPC, SARB, BoG, and beyond — with evidence-native systems.
GRC (Governance, Risk & Compliance)
The management discipline unifying governance, risk, and compliance — and why GRC platforms fail without an evidence-native engineering layer beneath them.
Start with the category
If you are new to the model, begin at Trust Infrastructure — the umbrella concept everything else hangs from — then explore the terms (TEOM, TEMM, Evidence Architecture) that operationalise it. Evolving knowledge — reports, analysis, and buying guides — lives in Research.