Your evidence is already stale.

Evidence Decay

Compliance evidence is any artifact that demonstrates a control is implemented and operating effectively. A configuration snapshot proving encryption is enabled on a storage volume. An access review log showing quarterly privilege validation. A vulnerability scan report demonstrating that critical findings are remediated within the required timeframe. A network diagram depicting the authorization boundary and data flow paths. Each of these artifacts captures the state of the environment at a specific moment. That moment passes. The environment continues to change. The artifact does not update itself. This divergence between the captured state and the current state is evidence decay. It is not a failure of process discipline. It is a property of time applied to static records in dynamic environments.

The rate of decay varies by evidence type. Infrastructure configuration evidence decays fastest because cloud environments change continuously: security groups are modified, IAM policies are updated, new resources are provisioned, encryption settings are adjusted. A configuration snapshot of an environment taken on Monday may not reflect Tuesday's reality. Access control evidence decays at a medium rate, governed by personnel changes, role modifications, and privilege escalations that accumulate between formal access reviews. Policy evidence decays slowest because organizational policies change infrequently, but even policy evidence becomes stale when the infrastructure it describes is modified without a corresponding policy update. The System Security Plan that describes your network architecture is valid until the network architecture changes. After that, it describes a system that no longer exists.

Assessors understand evidence decay intuitively, even when organizations do not. A C3PAO evaluating CMMC Level 2 practices will ask when each evidence artifact was collected. A SOC 2 Type II auditor evaluating the operating effectiveness of controls over a twelve-month period will look for evidence distributed across that entire period, not a batch collected in the final week. A FedRAMP assessor reviewing continuous monitoring artifacts expects monthly or quarterly evidence demonstrating sustained control operation, not annual snapshots. The assessment is not asking whether the control was ever implemented. It is asking whether the control was operating effectively throughout the assessment period. Evidence that is six months old answers the first question. It does not answer the second. The distinction between "was this control ever working" and "is this control working now" is the distinction between evidence that supports certification and evidence that does not.

The Problem

Most organizations collect compliance evidence on a periodic cycle. Quarterly is common. Monthly is aspirational. Annually is more frequent than many organizations achieve in practice. The collection process follows a predictable pattern: a compliance manager sends a spreadsheet to control owners requesting updated evidence for their assigned controls. Engineers take screenshots of console configurations, export access control lists, generate vulnerability scan reports, and upload them to a shared drive or GRC platform. The compliance manager reviews submissions for completeness, follows up on missing items, and compiles the evidence package. This cycle takes two to six weeks depending on organization size and the number of controls under assessment. By the time the collection cycle completes, the earliest artifacts are already weeks old. The environment they describe has already changed.

The cost of evidence decay compounds silently until assessment time. Between collection cycles, nobody tracks whether the evidence remains valid. The configuration snapshot from last quarter still sits in the evidence repository, marked as "current" because the next collection cycle has not replaced it. Meanwhile, an engineer modified the security group rules to accommodate a new application. The IAM team created a new service role with broader permissions than the access control policy permits. A storage bucket was created without the encryption configuration that the evidence artifact claims is enforced on all storage. None of these changes trigger an evidence update because the evidence collection process is periodic, not continuous. The evidence repository describes a compliant environment. The running environment is not compliant. The organization does not know this until the next collection cycle, or worse, until the assessor discovers it during the assessment.

The assessment scramble begins four to eight weeks before the assessor arrives. The compliance manager reviews the evidence repository and discovers that most artifacts are months old. Configuration snapshots no longer match the running environment. Access reviews have not been completed since the last collection cycle. Network diagrams depict an architecture that has been modified multiple times without documentation updates. The scramble is the organization's attempt to rebuild its evidence package from scratch under time pressure while simultaneously maintaining normal operations. Under that pressure, control owners take shortcuts. Screenshots are captured without verifying correctness. Policy documents are signed without substantive review. Narrative descriptions are written from memory rather than verified against running infrastructure. The resulting package is complete in the sense that every control has an artifact attached. It is not reliable in the sense that every artifact accurately reflects the current state of the control it describes.

The Collection Cycle

The traditional evidence collection cycle begins with a request and ends with an artifact repository that describes a system frozen at multiple points in time. A compliance manager identifies which controls require updated evidence, generates a task list, and distributes it to control owners across the organization. Each control owner is responsible for producing an artifact that demonstrates their assigned control is implemented and operating. For infrastructure controls, this typically means logging into a management console, navigating to the relevant configuration page, taking a screenshot, and uploading it to the designated repository. For process controls, it means locating the most recent policy document and confirming it has a current approval signature. For operational controls, it means exporting log data, generating reports, or providing attestation statements. Each task is treated as a discrete work item, disconnected from the other evidence tasks and from the running environment.

This process creates three categories of false compliance. First, evidence of configuration is not evidence of operation. A screenshot showing that encryption is enabled on a storage volume proves the setting exists at the time of capture. It does not prove that every object written to that volume was encrypted, that the encryption key is managed according to policy, or that the setting was not disabled and re-enabled specifically for the screenshot. Second, evidence of policy is not evidence of enforcement. A signed access control policy proves that management approved a document. It does not prove that the policy is technically enforced, that exceptions are tracked, or that violations are detected and remediated. Third, evidence of existence is not evidence of effectiveness. A vulnerability scan report proves that a scan was executed. It does not prove that critical findings were remediated within the required timeframe, that the scan covered the full authorization boundary, or that the scanner was configured to detect the vulnerability categories relevant to the compliance framework. The collection cycle produces artifacts that satisfy the letter of the evidence requirement while leaving the spirit of the requirement unaddressed.

Sentinel is designed to replace the periodic request with a standing declaration. The architecture specifies collection as a declarative model: evidence requirements are declared per control, stating what collection must satisfy, then resolved against discovered infrastructure, with the resolver's connection choice recorded so every binding is auditable. Collection profiles span discovery (what exists), evidence (prove a control), compliance scanning, and monitoring (what changed), so the observation limb that finds a resource is, by design, the one that keeps proving it. The design's write-path law holds that writing the event is the state change itself; no component updates a record and emits evidence as a side effect, which is precisely the failure mode of the screenshot. Because collectors fail in the real world, the design also classifies collection failure and names an adaptation per class: a rejected credential triggers rotation and a single retry, a faulty connector is circuit-broken rather than allowed to expire the world by failing quietly, and a run that cannot prove what it saw records nothing rather than recording a guess. The estate that Garrison is designed to hold carries full temporal history, so each observation lands against an entity whose past is part of the record. Collection becomes a property of the system, not a project imposed on it.

The Drift Gap

Infrastructure drift is the divergence between the declared state of an environment and its actual running state. In compliance terms, drift means the environment no longer matches the evidence that describes it. Drift is not caused by negligence. It is caused by operations. Engineers modify configurations to resolve incidents. New services are deployed to meet business requirements. Auto-scaling creates and destroys resources continuously. Each change is individually reasonable. Collectively, they move the environment away from the state captured in the last evidence collection. The rate of drift correlates with the pace of operational activity. High-velocity environments that deploy multiple times per day drift faster than static environments. But even the most stable environments drift: certificate renewals, patching cycles, and infrastructure provider changes all modify the environment without requiring a deployment.

Drift affects compliance evidence in two directions. Positive drift occurs when the environment improves beyond what the evidence describes: a team implements stronger encryption or tighter access controls without updating the evidence repository. The organization is more secure than its evidence suggests, but the evidence is still stale. Negative drift is more dangerous: configurations weaken, permissions widen, monitoring coverage decreases, and the evidence repository still describes the stronger previous state. A security group modification that opens a port for troubleshooting and is never closed. An IAM policy exception granted for a migration project that becomes permanent. A logging pipeline that stops collecting events from a new resource type because the collector was not updated. Each of these changes degrades the security posture without triggering an evidence update. The gap between documented posture and running posture is the drift gap, and it is invisible between collection cycles.

The architecture treats drift as a first-class event, not a quarterly discovery. Sentinel is designed to detect divergence between observed state and declared baseline (the property NIST 800-53 CM-3 governs as configuration change control) and to emit it as typed events: DriftDetected, DriftCorrected, DriftAlarmed. In the specified reconciliation lifecycle, a converged resource that drifts re-enters convergence and is replanned under its drift-class policy, and the alert reaches the posture surface, where Rampart is designed to recompute every affected control, each posture change carrying its basis in the event that records it. Correction runs under the AutomationPolicy surface: AUTO, APPROVAL, or MANUAL per resource, with tier defaults the design does not let automation escape. Routine, reversible corrections may default to AUTO. Consequential changes default to approval. The highest-impact class is always MANUAL, with no automatic path architecturally permitted and a named human confirming the act. Every correction is an action contract whose events land in the same evidence stream they repair, closing the loop from detection through correction to proof.

Evidence Freshness

Evidence freshness is a compliance dimension that most organizations treat as binary: evidence either exists or it does not. In reality, freshness operates on a continuous scale. A configuration snapshot taken five minutes ago is more valuable than one taken five days ago, which is more valuable than one taken five months ago. The value degrades at a rate determined by the volatility of the underlying resource and the sensitivity of the control it supports. A snapshot of a firewall rule set in a production environment with daily deployments loses relevance within hours. A snapshot of an encryption configuration on an archival storage volume may remain valid for weeks. A signed policy document may remain valid for months. Treating all evidence as equally valid regardless of age is the foundational error that makes periodic collection feel adequate when it is not.

Staleness compounds across controls. An organization with a few hundred controls does not have a few hundred independent freshness problems. It has a system-wide posture that degrades as individual controls lose evidence currency. When a handful of controls carry stale evidence, the organization can still claim strong posture. When half do, the posture is uncertain. When most do, the organization cannot demonstrate compliance regardless of how strong its actual defenses are. The compounding effect accelerates between collection cycles because evidence does not decay at a uniform rate. Fast-changing infrastructure controls go stale within days. Process controls may hold for weeks. By the midpoint of a quarterly collection cycle, the controls with the fastest decay rates have already lost their evidentiary support. By the end of the cycle, the majority of infrastructure-related evidence is no longer current.

The Redoubt Forge architecture holds freshness as epistemic law, not as a report column. Every recorded belief carries its provenance and ages; confidence is a derived quantity, provenance quality times freshness times derivation chain, never a static annotation, and evidence expiration is specified as one instance of that universal decay law. Each class of evidence declares a freshness horizon. Past its horizon, a record does not quietly keep testifying. It demotes to contested rather than deleting, the expiry event itself preserved in provenance, and any consequential act that would consume it as a critical input is designed to refuse, fail closed, and emit a re-observation task for the owning collection controller. Sentinel owns that re-observation as a scheduled collection demand; Rampart owns what the resulting observation means for each mapped control. The dependency is explicit in the architecture's own capability graph: freshness decay drives continuous authorization. An artifact's age is not a metadata curiosity. It is an input the design refuses to ignore.

Immutable Records

Immutability means an evidence record cannot be modified after creation without detection. In compliance, immutability addresses a specific trust problem: when an organization presents evidence to an assessor, the assessor must determine whether the evidence reflects the actual state of the environment at the time of capture or whether it has been modified to present a more favorable picture. Traditional evidence repositories offer no mechanism for this determination. A screenshot in a shared drive can be replaced. A log export can be edited. A scan report can be regenerated with different parameters. The assessor evaluates the artifacts at face value because there is no technical mechanism to verify their integrity. Trust in the evidence depends entirely on trust in the organization that produced it.

The non-tampering problem extends beyond intentional manipulation. Evidence records are also vulnerable to accidental corruption: file system errors that alter stored artifacts, migration processes that modify timestamps or metadata, organizational restructuring that moves evidence between repositories and inadvertently changes file properties. Even well-intentioned corrections create integrity questions. When a compliance analyst notices an error in an evidence description and updates the metadata, the modification is indistinguishable from deliberate falsification without an integrity verification mechanism. The assessor cannot determine whether the record was corrected or fabricated. In regulated environments where evidence integrity carries legal weight, the inability to distinguish between correction and fabrication is a material liability.

In the Redoubt Forge architecture, the system of record is a signed, append-only event log; every other representation is derived from it and rebuildable. Append-only is enforced structurally: no update or delete path exists against the log, so editing history is not a policy violation but an operation the design refuses to represent. Every event carries a per-org SHA-256 chain hash computed over its canonical bytes folded with the hash of the event before it, so any modification to any record invalidates every hash that follows. On a set cadence the design seals Merkle checkpoints over new events and signs only the roots, and no sealed root exists without independently signed time. External witnesses accept a root only when it chains from the previous one, which makes a silently forked history detectable. The verification story deliberately excludes the platform itself: an exported evidence bundle is designed to verify fully offline, recomputing each leaf hash, folding the inclusion path, and checking signature, timestamp, and witness, with any failure naming the exact broken link. An assessor participates as a scoped, time-boxed actor with an as-of evidence lens, not as a reader of exported screenshots. And because audit is the log itself, there is no parallel audit store to drift. The design does not ask for trust in the evidence. It makes the evidence checkable.

Continuous Assessment

Continuous assessment is the operational model where compliance posture is computed at every change, not evaluated at periodic intervals. In a continuous model, every infrastructure modification triggers a re-evaluation of every affected control. Every evidence event updates the freshness scores of every control it supports. Every drift detection triggers a posture recalculation. The compliance state of the system is always current because it is a function of the current evidence stream, not a function of the last time someone checked. This model eliminates the fundamental weakness of periodic assessment: the gap between assessments where the organization operates without knowing whether it remains compliant.

Periodic assessment always fails because it optimizes for the assessment event rather than for continuous compliance. Organizations prepare for assessments. They collect evidence in the weeks before the assessor arrives. They remediate gaps discovered during preparation. They present a polished evidence package that represents their best compliance state during a narrow window. Between assessments, the incentive structure shifts: operational priorities take precedence, evidence collection stops, drift accumulates, and the compliance posture degrades until the next assessment cycle forces another round of preparation. This sawtooth pattern, where compliance peaks at assessment time and decays between assessments, is the predictable outcome of periodic verification applied to continuously changing environments. The pattern cannot be corrected by more frequent assessments. It can only be corrected by eliminating the gap between assessments entirely.

This is the model the Redoubt Forge architecture commits to. Rampart is specified as a live-authorization workspace: authorization state is maintained event-by-event, and point-in-time assessments and readiness scores are projections of that state, never products assembled for a date. The state is as-of queryable by construction: what was believed at time T, on what basis, and what was done about it, answerable cryptographically, because rebuilding from the log is deterministic and reproduces the projections byte-identically from any replayed range. Citadel is designed to aggregate that posture into one command surface, its cards role-prioritized and never hard-filtered, so the person who can act on a degradation sees it first without anyone else losing sight of it. The charter states the operating claim plainly: a control plane holds desired state, reconciles the world against it, and reports divergence as a diff. Under that model the assessment window loses its special status. There is nothing to prepare, because the state the assessor queries is the state the system has been recording all along.

The New Model

Evidence decay is not a process problem that can be solved with better discipline or more frequent collection cycles. It is an architectural limitation of static artifacts in dynamic environments. No amount of diligence changes the fundamental property: a point-in-time snapshot begins aging the instant it is captured. The only architecture that eliminates decay is one where evidence is produced continuously, stored immutably, and scored against the running state of the environment it describes. This is not an incremental improvement to periodic collection. It is a different model entirely.

The consequences of the old model are predictable and severe. Organizations operate in a perpetual cycle of collection, decay, scramble, and assessment. Each cycle consumes engineering time that should be spent improving security posture. Each cycle produces evidence packages that describe systems frozen at various points in the past. Each cycle ends with an assessment that evaluates a composite image assembled from temporal fragments rather than a coherent view of a running system. The scramble before each assessment is not a failure of preparation. It is the inevitable outcome of an evidence architecture that cannot keep pace with the environment it describes.

This is the model Redoubt Forge is designed around, and the division of labor is strict. Sentinel is the observation limb: discovery, evidence collection, scheduled scanning, and drift alerting across a universal connector interface, emitting observations without ruling on what they mean. Rampart is the interpreter: mapping observations to controls, recomputing posture on change, projecting assessments from continuous state. Garrison holds the temporal estate: what existed at time T, with compliance history retained beyond the lifespan of the entity it describes. Beneath all three, the append-only spine chain-hashes every event and seals signed Merkle checkpoints, so the record that accumulates is the same record an assessor can verify. Under this design the scramble has nothing to feed on. There is no gap between the evidence and the environment for decay to grow in, because the evidence is the environment's own event stream. The assessment changes character, from a high-pressure excavation of the recent past into a query against a record that never stopped being written. Evidence stops being something you go and get. It becomes something the system cannot help producing.