The infrastructure is the evidence.

IaC Evidence

Infrastructure as Code inverts the evidence model. Instead of deploying infrastructure manually and then collecting evidence of its configuration, the infrastructure is defined in code before deployment. The code specifies every configuration parameter: encryption settings, access control rules, logging destinations, network boundaries, retention policies, key management configurations. When that code is applied, the resulting infrastructure matches the specification exactly. The deployment event itself is evidence that the specified configuration exists. The code repository maintains the complete history of every configuration change, who made it, when, and why. The gap between "what was intended" and "what was deployed" collapses because they are the same artifact. The Terraform state file records the deployed resource identifiers, configuration values, and dependency relationships. The plan output shows exactly what will change before it changes. The apply log records exactly what did change and when.

When infrastructure is defined as code, compliance requirements can be encoded as configuration parameters. An encryption control does not require a screenshot of a console page showing encryption enabled. It requires a Terraform resource definition with server_side_encryption_configuration set to AES-256 or aws:kms with a specific key ARN. That configuration is version-controlled, peer-reviewed, and applied through an automated pipeline. The evidence is the code itself, the deployment log, and the state file confirming the resource exists with the specified configuration. This evidence is machine-readable in line with NIST OSCAL conventions, timestamped, attributable to a specific commit and author, and verifiable against the running infrastructure at any time. It does not decay because the code repository preserves every version indefinitely. It does not become disconnected from the running system because the deployment pipeline enforces the code as the single source of truth. If someone modifies the infrastructure outside the code pipeline (console click, manual API call), the drift is detectable because the running state no longer matches the declared state.

The compliance implications are structural, not incremental. Infrastructure as Code does not make evidence collection faster. It eliminates the need for a separate evidence collection process entirely. The deployment pipeline IS the evidence collection process. Every terraform apply that provisions or modifies infrastructure simultaneously creates the evidence that the infrastructure meets its specified configuration. Every pull request that modifies infrastructure code creates a reviewable, auditable record of the change, the justification, the approvals, and the resulting state. The compliance team does not need to ask engineers to take screenshots because the deployment artifacts contain more information, with higher fidelity, than any screenshot could capture. The assessor does not need to trust that a screenshot represents the current state because the infrastructure state can be verified against the code in real time. This is not an optimization of the screenshot model. It is a replacement of it. The evidence model shifts from "capture and file" to "deploy and verify."

The Problem

The dominant evidence collection model in compliance programs is manual capture. An engineer opens a console, navigates to a configuration page, takes a screenshot, and uploads it to a shared drive or GRC platform. A compliance analyst labels the screenshot, cross-references it to a control, and files it in the evidence package. This process repeats for every control that requires technical evidence: encryption settings, access control configurations, logging pipelines, network segmentation rules, vulnerability scan results, patch management records. For a framework like NIST 800-53 at the Moderate baseline, the burden multiplies across every control family, every service, and every account until the artifact library outgrows anyone's ability to keep it current. Each artifact is a static image of a dynamic system, captured at a single point in time, disconnected from the infrastructure it claims to represent the moment the screenshot is saved. The screenshot is not evidence of a control. It is evidence that someone looked at a configuration page on a specific date. It proves nothing about what happened before that moment or after it.

Evidence decay is not a risk to manage. It is a certainty to plan for. Every piece of static evidence begins decaying the moment it is captured. Infrastructure is not static. Security groups are modified to accommodate new application requirements. IAM roles are created, expanded, and reassigned. Encryption keys rotate. Logging configurations are adjusted. Network ACLs are updated. Storage buckets are created for ad hoc projects without compliance review. Services are deployed to new regions. Each of these changes invalidates some portion of the existing evidence package, but the evidence package does not know it. The screenshot of the security group configuration from three weeks ago still sits in the evidence library, cross-referenced to the boundary protection control, presenting a configuration that no longer matches the running environment. The compliance team discovers this during the next collection cycle, or worse, the assessor discovers it during the assessment.

Configuration drift compounds evidence decay into active misrepresentation. When an engineer modifies a security group rule to troubleshoot a connectivity issue and forgets to revert the change, the evidence package now contains a screenshot showing a compliant configuration while the running system is non-compliant. This is not intentional misrepresentation. It is the mechanical consequence of maintaining evidence separately from infrastructure. The evidence and the infrastructure are two independent systems with no synchronization mechanism. They diverge naturally and silently. The compliance team does not know the configuration changed because they are not monitoring the infrastructure; they are managing a document library. The engineering team does not know the change has compliance implications because they are not tracking which configurations map to which controls. Both teams are doing their jobs. Neither team has visibility into the other's domain. The result is an evidence package that actively contradicts the running environment, discovered only when an assessor compares the documented state to the observed state during an assessment.

Deploy and Comply

Writing compliant infrastructure code from scratch requires deep knowledge of both the target framework's control requirements and the cloud provider's configuration options. An engineer implementing SC-28 (Protection of Information at Rest) must know that the control requires encryption of all data at rest, that the encryption must use FIPS 140-2 validated cryptographic modules, that the key management must include rotation policies and access restrictions, and that the specific Terraform resource attributes that implement these requirements vary by service. Multiply that by every control in the framework, and the engineering burden becomes prohibitive. Most teams either implement a subset of controls (leaving gaps) or implement controls inconsistently across services (creating partial coverage that is difficult to assess). The problem is not willingness. It is the cognitive load of mapping framework requirements to infrastructure configuration across dozens of services simultaneously.

Manual infrastructure requires a separate evidence collection process because no structural link exists between the deployment action and the compliance requirement it satisfies. An engineer who provisions an encrypted storage bucket through the console has satisfied a control, but the only record is the console action itself. No metadata connects that action to SC-28. No provenance chain links the configuration to the framework requirement. The compliance team must independently discover that the bucket exists, verify its encryption configuration, capture evidence of that configuration, and map the evidence to the control. This is redundant work: the engineer already knows the configuration because they set it. The compliance team must rediscover what engineering already did, in a different format, on a different timeline, through a different process. Every manual deployment creates this gap. Every gap requires manual bridging. The labor cost compounds across every resource, every control, and every assessment cycle.

The design answers this with modules that carry the mapping so engineers do not have to. Armory is specified as a governed marketplace of signed, provenance-verified packages alongside hardened Terraform modules. Each hardened module consumes a community module and applies STIG parameters as exact values, with CCI mappings carried in the module metadata and security settings hardcoded so consumers cannot weaken them. A storage module does not document its encryption posture beside the code; the parameter that enables encryption is the same artifact that maps the deployment to SC-28. Module satisfaction is expressed in the design as OSCAL component definitions, so a deployed module arrives in Rampart already carrying the controls it addresses, layered against provider and platform responsibility mappings rather than asserted flat. The catalog is designed to show a score-impact preview before deployment: which controls a module addresses and what the posture change would be. Deploy the module, and the control mapping travels with it. Nothing is rediscovered later, because nothing was ever separate.

Evidence Chain

The evidence chain begins at the code repository. A hardened Terraform module is committed with a specific version tag. The module's metadata declares which controls it satisfies: SC-28 for encryption at rest, AU-3 for audit content, SC-7 for boundary protection. The pull request records who authored the change, who reviewed it, what approvals were granted, and when the merge occurred. The CI/CD pipeline runs terraform plan, which produces a machine-readable execution plan showing exactly what resources will be created or modified and with what configuration values. The plan is stored as an artifact with an integrity hash. When the plan is approved and applied, terraform apply executes the changes and produces a state file recording the deployed resource identifiers, their configuration attributes, and the dependency graph. At this point, a complete, immutable, machine-verifiable record exists of what was intended (the code), what was planned (the plan), and what was deployed (the state file and apply log).

Traditional evidence chains have gaps at every handoff point. The engineer deploys infrastructure. Weeks later, the compliance team captures a screenshot. Between deployment and capture, the configuration may have changed. Between capture and assessment, the configuration may change again. Each handoff introduces a temporal gap where the evidence and the infrastructure are unsynchronized. The chain is not continuous; it is a series of disconnected snapshots stitched together with assumptions. The assessor must trust that the screenshot taken on January 15 still reflects the configuration on April 1. That trust is an assertion, not evidence. The longer the chain of assumptions, the weaker the evidentiary value. A chain that requires "we believe this screenshot still reflects reality" at three separate points is structurally weaker than a chain where every link is independently verifiable at the moment of assessment.

The design carries this chain past deployment. Sentinel is designed to observe the estate through declared collection profiles, and every observation it records is content-addressed: the payload digest of a captured configuration makes a changed byte a changed digest, so integrity drift is detected by construction rather than by re-inspection. Observations carry provenance and taint rather than arriving as bare facts, and every collection act appends as a typed event on a signed spine; a collector that cannot record its evidence is designed to fail its run closed rather than observe unrecorded. The spine itself is specified as a per-org SHA-256 hash chain whose ranges attest under a signed root, with independently signed time on every sealed root; no unsigned attestation exists in the design. The chain the assessor walks therefore runs from source commit through deployed state to observed configuration, and every link is checkable. As-of answers are citable by design, naming the exact log range that grounds them. The question "has this artifact been modified after creation" is answered by arithmetic, not by custody.

Terraform Baseline

Three NIST 800-53 controls define the configuration management triad that underpins infrastructure compliance. CM-2 (Baseline Configuration) requires organizations to develop, document, and maintain a current baseline configuration of the information system. CM-6 (Configuration Settings) requires establishing and enforcing security configuration settings for information technology products employed in the system. CM-8 (System Component Inventory) requires developing and documenting an inventory of system components that accurately reflects the current system. Terraform state satisfies all three simultaneously. The state file IS the baseline configuration: a machine-readable document that records every resource, its configuration attributes, and its relationships. The Terraform code that produces the state IS the configuration settings: the declared values that define how each resource must be configured. The resource inventory within the state IS the component inventory: every deployed resource with its type, identifier, and current attributes. When these controls are satisfied through Terraform, they are satisfied structurally rather than through separate documentation artifacts.

Without Terraform, satisfying CM-2, CM-6, and CM-8 requires maintaining three separate document sets. The baseline configuration document describes the approved system architecture and configuration parameters. The configuration settings document lists the security-relevant parameters for each component and their approved values. The component inventory lists every hardware and software element in the system with attributes like version, location, and owner. These documents are authored manually, updated periodically (often quarterly), and reviewed during assessments. Between updates, the documents drift from reality. New components are deployed without updating the inventory. Configuration parameters change without updating the settings document. The baseline document describes an architecture that existed at authorship time but has evolved since. Drift from Terraform state IS a compliance violation of these controls, because drift means the running system no longer matches its documented baseline, its documented settings, or its documented inventory.

The design treats the declared state as the baseline and observation as the check against it. Sentinel is designed to run discovery against the connected estate, and the component inventory is the discovery profile's output: every component arrives as an observation carrying provenance and a freshness horizon, not a row in a maintained spreadsheet. Configuration settings are observed the same way. The drift machinery reports declared-versus-observed as a typed change event with a drift class, never a silent overwrite, and a change nobody declared still gets seen, which is the half of configuration change control an approval workflow structurally cannot cover. Garrison is designed to hold that inventory as a temporal estate: what existed at time T, with compliance history retained beyond an entity's lifespan. When drift is confirmed, remediation is specified as the work of governed actors executing codified fixes under action contracts and authority envelopes, including opening fix pull requests in the repositories that declared the resource. The AutomationPolicy surface holds the boundary per resource, AUTO, APPROVAL, or MANUAL, with change classes that are never delegable to automation at all.

Drift Detection

Configuration drift is the primary threat to infrastructure-as-evidence. If the running state diverges from the declared state, the evidence chain breaks. The code says encryption is enabled with a specific key. The running resource has encryption disabled because someone modified it through the console. The monitoring system observes the discrepancy. At this point, the evidence stream for the affected control transitions from "satisfied" to "degraded." The speed of detection determines the severity of the gap. A drift detected within minutes produces a brief compliance event gap that can be explained and remediated. A drift undetected for weeks produces a sustained evidence gap that may constitute a control failure during an assessment. The difference between a minor annotation and a material finding depends entirely on how quickly the drift is detected and how quickly the compliant state is restored.

Between assessments, drift accumulates silently in organizations that lack continuous monitoring. A security group rule is modified to troubleshoot a connectivity issue. An IAM policy is broadened to accommodate a deadline. A logging configuration is adjusted to reduce costs. A storage bucket is created without encryption for a temporary project that becomes permanent. Each change is individually rational, operationally justified, and compliance-invisible. No alert fires. No ticket is created. No evidence artifact is updated. When the next assessment arrives, the assessor compares the documented baseline to the running environment and discovers dozens of discrepancies. Each discrepancy requires investigation, explanation, and remediation. The organization enters a scramble phase that could have been avoided entirely if drift had been detected and addressed continuously.

The drift machinery in the design is typed, not ad hoc. A detected change carries the digest it moved from and the digest it moved to, a drift class covering access, structure, configuration, and lifecycle changes, and a significance grade separating posture-bearing changes from informational ones. The default drift verdict is specified as declared wins, observed reported: the declaration is never silently rewritten to match what someone clicked. Detection does not lean on change events alone; the design sets a full-scan floor under its delta-driven sweeps, so every resource is re-verified daily regardless of whether any change fired. A posture-bearing change feeds Rampart's posture recompute directly, and evidence whose freshness horizon passes flips its control rather than continuing to satisfy it; in this design, stale evidence never silently satisfies. Citadel is designed to surface the alarm with its context: what changed, which controls it touches, and what response the policy surface has queued, so the organization sees drift as it accumulates instead of meeting it at the assessment.

Convergence Loop

The convergence loop is the operating model that ties infrastructure-as-evidence into continuous posture. It is not a linear process with a beginning and an end. It is the loop the architecture specifies for every controller: observe, compare, plan, simulate, check policy, act, verify predicted against actual, record, learn. Observation captures the running state. Comparison holds it against the declaration. Planning proposes the correction, and simulation predicts its effect with the cheapest faithful predictor available, plan diffs and dry runs before anything richer. The policy check applies the human boundary before any action executes. Verification closes the loop: every consequential act is checked against its predicted effect, and the comparison is recorded, so each pass leaves the loop better calibrated than the pass before it.

Without convergence, posture degrades mechanically. Infrastructure changes introduce new drift. New vulnerabilities are disclosed against existing dependencies. Evidence ages past its usefulness. Personnel changes alter access patterns. Each of these events affects compliance posture, but without a continuous loop to detect and correct them, the degradation is invisible until the next assessment. Organizations that treat compliance as a periodic project experience this degradation as an assessment surprise: the posture that looked settled six months ago has quietly slipped, and the remediation effort to restore it consumes weeks of engineering time under deadline pressure. A convergence loop denies the degradation its accumulation window by meeting deviations at the speed they occur.

In the design, posture is not recomputed on a calendar. It is maintained event-by-event, with point-in-time assessments and readiness scores as projections of that continuous state. The architecture routes Vanguard scan results into Rampart's finding intake through a defined trigger seam, and routes Sentinel's change observations into the same posture recompute, so one scoring surface absorbs both. Collection scheduling is derived, never hand-set: the cadence for observing a target is computed from the freshness horizon its evidence class declares, the target's observed change frequency, and the posture weight of what the observation supports, and a horizon breach outranks the standing cadence rather than waiting for the next tick. A collection run already in flight is acknowledged idempotently rather than duplicated, so the loop converges without racing itself. Each declared resource carries its lifecycle: converging while reconciliation closes the gap, converged when predicted matches actual within tolerance, and back to converging the moment drift is detected. And the record is bitemporal by design, so the question "what was the posture on the first of the month" has a citable answer naming the exact evidence behind it.

The New Model

The traditional compliance model treats infrastructure and evidence as separate concerns managed by separate teams on separate timelines. Engineers build and maintain systems. Compliance teams collect and organize proof that those systems satisfy framework requirements. The two workflows share a subject (the infrastructure) but nothing else: not the data sources, not the collection mechanisms, not the temporal cadence, not the storage systems. This separation is not a process inefficiency. It is an architectural flaw that guarantees evidence decay, assessment scrambles, and compliance findings. The evidence and the infrastructure are two independent representations of the same reality, maintained by different people with different tools, synchronized manually at quarterly intervals. Every organization that operates this model experiences the same failure modes: stale evidence, scrambled re-collection, assessor surprises, and engineering time consumed by documentation rather than security improvement.

The new model removes the separation. Infrastructure deployed from hardened IaC modules satisfies controls from first deployment. The deployment event is the evidence creation event. Continuous observation confirms the configuration persists, drift surfaces as a typed deviation from the declaration, and remediation restores the compliant state through the same code pipeline that created it. There is no separate evidence collection process, because the infrastructure operations are the evidence collection process. There is no assessment scramble, because the evidence is as current as the last reconciliation pass. There is no gap between what the documentation says and what the infrastructure does, because they are the same artifact.

This is the model Redoubt Forge is designed around, and the architecture states it as law rather than aspiration: declared states ARE the policies; controller actions ARE the evidence; the desired-versus-actual gap IS the assessment; reconciliation history IS the audit trail. One hardened deployment through Armory carries its control mappings with it, and Rampart is designed to project posture from that one defended implementation across every framework the organization maintains, with assessments rendered as projections of continuous state rather than annual reconstructions. The evidence beneath every projection is designed to be checkable: content-addressed observations on a signed, witnessed event spine, exportable as machine-verifiable attestation in OSCAL that a third party can check cryptographically. Citadel is designed to hold the unified view: every system, every framework, every control, one surface. And Alliance is specified as proof-exchange rather than document-exchange, with external assessors entering as scoped, time-boxed actors holding as-of evidence lenses. The infrastructure is the evidence. The design's job is to keep that sentence checkable.