Automate the mechanical. Govern the judgment.

The Boundary

Not everything in compliance can be automated, and not everything should be manual. The distinction is not about technical capability. Modern systems can automate nearly any decision if you let them. The distinction is about accountability. When an organization accepts a risk by operating with a known control gap, that acceptance carries legal and contractual weight. An authorizing official signs the risk acceptance. Their name is on the document. Their judgment is the basis for the decision. No automated system should make that decision on a human's behalf, because no automated system bears the consequence of getting it wrong. Similarly, when an organization grants a policy exception that allows a system to deviate from a security baseline, that exception must be justified, time-bounded, reviewed, and approved by someone with the authority to accept the associated risk. Automating that approval removes the accountability that makes the exception governable.

The mechanical side of compliance is equally clear. Collecting a configuration snapshot from a running system is a deterministic operation. Comparing that snapshot against a security baseline produces a binary result: the configuration matches or it does not. Recording the result with a timestamp, source system identifier, and integrity hash is a data operation. Repeating this collection on a defined schedule is a scheduling operation. None of these steps require judgment. They require reliability, consistency, and tamper-evident storage. Performing them manually introduces human error, scheduling drift, and evidence gaps. An engineer who collects configuration evidence quarterly will occasionally miss the collection window. The evidence ages. The compliance posture degrades without anyone noticing until the next assessment preparation cycle reveals the gap. Automating mechanical evidence collection does not remove humans from the process. It removes humans from the parts of the process where they add error instead of value.

The boundary between mechanical and judgment work is not always obvious. Consider vulnerability management. Detecting a vulnerability is mechanical: a scanner identifies a known CVE in a deployed component. Assessing the vulnerability's applicability to your environment involves judgment: does the vulnerable code path execute in your deployment configuration? Is the vulnerability exploitable given your network segmentation? Prioritizing remediation involves more judgment: does this vulnerability affect a system that handles regulated data where the risk is higher, or an internal development environment where the blast radius is contained? Deciding to accept the risk of delayed remediation because a compensating control mitigates the exposure is a governance decision that requires human authority. Each step in the vulnerability management lifecycle crosses the automation boundary at a different point, mirroring the Map, Measure, and Manage functions described in the NIST AI RMF. A platform that treats the entire lifecycle as either fully automated or fully manual misses the nuance that determines whether the output is trustworthy.

The Problem

Platforms that automate everything create a specific failure mode: false confidence backed by automated assertions that no human reviewed. The system reports 95% compliance. The dashboard is green. The executive team reports the number to the board. No one examined whether the automated assessment correctly interpreted each control. No one verified whether the evidence the system collected actually demonstrates what the control requires. No one reviewed whether the cross-framework mappings the system applied are accurate for the organization's specific implementation. The 95% number is a computation, not a judgment. When the assessor arrives and probes the controls behind that number, they find configurations that technically satisfy the automated check but do not satisfy the control's intent. They find evidence that demonstrates existence but not effectiveness. They find mappings that are structurally correct but contextually wrong because the organization's implementation differs from the standard pattern the automation assumed.

Manual compliance processes fail differently. They fail through exhaustion. A compliance team of three people managing CMMC Level 2 across two systems must track 220 control implementations, collect evidence for each on a recurring schedule, write and maintain narratives that describe the current state of each control, manage POA&M items for open gaps, coordinate remediation with engineering teams who have competing priorities, and prepare evidence packages for the assessor. Each task is individually manageable. The aggregate volume is not. Evidence collection falls behind schedule. Narratives describe last quarter's architecture. POA&M items age without progress because the compliance team lacks the authority to compel engineering resources. The team spends its time on mechanical evidence collection because that is the most visible deliverable, leaving no bandwidth for the judgment work that actually determines compliance outcomes: evaluating whether controls are operating effectively, identifying cross-control dependencies that create systemic risk, and making governance decisions about acceptable risk levels.

Both failure modes converge on the same outcome: the organization enters an assessment with an inaccurate understanding of its own compliance posture. The fully automated organization believes it is compliant because the dashboard says so. The fully manual organization knows it is behind but cannot quantify how far behind because it lacks the bandwidth to assess its own state. The assessor discovers the truth in both cases, and the discovery happens at the most expensive possible moment: during the assessment itself. The cost is not just the failed assessment. It is the months of preparation that produced an inaccurate picture, the remediation cycle that must follow, and the organizational credibility lost when the reported posture does not match the observed posture. The problem is not automation versus manual. The problem is drawing the line in the wrong place, or not drawing it at all.

Mechanical Work

Evidence collection, vulnerability scanning, configuration monitoring, and baseline comparison are mechanical operations. They follow deterministic rules. The input is observable infrastructure state. The output is a recorded artifact with provenance metadata. No step in the chain requires interpretation, risk judgment, or organizational authority. These operations consume the majority of a compliance team's time in manual workflows: scheduling evidence collection windows, reminding engineers to export configurations, chasing missing screenshots, reformatting artifacts into the evidence repository's required structure, and verifying that timestamps fall within the freshness window. Every hour spent on mechanical collection is an hour not spent on governance decisions, narrative review, or risk assessment. The mechanical work does not require the compliance team's expertise. It requires their calendar, and that calendar is finite.

Doing this work manually consumes all available capacity because the volume scales with the number of controls, systems, and evidence freshness requirements. A single CMMC Level 2 system with 110 practices requires evidence for each practice, refreshed on the cadence the framework or the organization's policy dictates. Two systems double the volume. Adding FedRAMP raises the count again; the rev5 High baseline carries 410 controls, some overlapping with CMMC but carrying their own freshness windows and format requirements. A compliance team that spends most of its week on mechanical evidence collection keeps only a remainder for the judgment work that determines whether the organization is actually compliant, and that remainder is further divided between narrative writing, gap analysis, remediation coordination, and assessment preparation. The bandwidth available for actual governance, the work that distinguishes a compliant organization from one that merely has evidence, approaches zero.

The design gives the mechanical side to machines and states the boundary in architecture rather than in a settings page. Sentinel is specified as the observation limb of the control plane, with four collection profile classes, each a question asked of the world: discovery asks what exists, evidence asks whether a control can be shown satisfied, compliance-scan asks whether a target passes its checks, and monitoring asks what changed. Each profile produces observations rather than conclusions, and every observation carries provenance and taint rather than arriving as a bare fact. Collection is declarative in this design: a control's evidence requirement arrives as a requirement, never as a collector name, and a resolver binds it to the discovered estate. Schedules are derived, never hand-set, and collection is designed to heal itself, classifying failures by type and rotating credentials, so a silent gap is a defect rather than a fate. Vanguard is designed to run the scan half of the mechanical work through eight scanner classes: code, IaC, secrets, SBOM, vulnerability, DAST, antivirus, and cloud posture. None of this asks a human for judgment, and that is the point. The reconciliation loop is observe, compare, act within policy, record, escalate, learn; a human enters exactly where the loop says escalate.

Judgment Work

Risk acceptance is a governance decision that carries legal and contractual weight. When an organization operates with a known control gap, it accepts the associated risk. The authorizing official signs the risk acceptance, and their signature attests that they understand the gap, evaluated the potential impact, considered compensating controls, and determined that the residual risk is acceptable given operational requirements. This decision cannot be automated because no automated system bears the consequence of the decision. The authorizing official can be named in a False Claims Act proceeding. The automated system cannot. Policy exceptions follow the same pattern: a specific system or component is allowed to deviate from a security baseline under defined conditions, for a bounded duration, with a compensating control in place. The exception must be justified, reviewed, and approved by someone with the organizational authority to accept the deviation. Categorization decisions determine which data types a system handles, which directly determines which controls apply and at what rigor. Categorizing a system as handling only Federal Contract Information when it actually processes Controlled Unclassified Information changes the entire compliance baseline. These decisions shape the compliance program. They require human accountability.

Automating judgment work produces compliance without accountability. A platform that automatically accepts risk when a control gap persists for a defined period has eliminated the governance check that makes risk acceptance meaningful. A platform that automatically categorizes data based on keyword matching has removed the human determination that regulatory frameworks require. A platform that automatically approves policy exceptions when compensating controls are detected has substituted a mechanical check for the organizational judgment that assessors will evaluate. The assessor does not ask whether a compensating control exists. The assessor asks whether the authorizing official evaluated the compensating control's adequacy, documented the rationale, defined a remediation timeline, and accepted the residual risk with full understanding of the implications. Automated approval produces a record. It does not produce the judgment that the record is supposed to represent.

The architecture holds this line as law, not as configuration. Risk acceptance, control not-applicable justification, authorization-boundary changes, and policy decisions are Tier-3 actions by architecture: human only, never delegable, with no automated path, no pre-approval, and no configuration key that could soften the gate. Rampart's design carries that gate on each action. A risk acceptance requires a live step-up elevation from a named human or the act refuses; the requester and the approver cannot be the same person; and an acceptance with no stated expiry is recorded against a maximum window rather than as permanence, because an acceptance that never expires is exactly the silent policy the gate exists to forbid. The posture record that results carries the elevation citation on the row itself, so who ruled travels with what was ruled. The same discipline governs what models touch: AI triage of findings is bound by the rule that tainted input informs but never authorizes, with human confirmation downstream, and nothing Artificer drafts publishes without a named human confirming it. Every ruling commits to the append-only spine carrying the actor's identity, who it was on behalf of, and the action contract it rode; the name lives in the record, not in a wiki.

Escalation Design

Escalation is not an error state. In this design it is the specified behavior for every condition that crosses the automation boundary: the mechanical loop runs until it reaches a decision it is not authorized to make, then hands a human that decision with its context attached rather than a raw alert. The human should receive everything required to rule without conducting an investigation: the control affected, the condition that fired, the current evidence state, the applicable requirement, and the response options. Escalation designed this way compresses the decision cycle from days or weeks of back-and-forth investigation to a single informed action, and it makes the boundary itself visible. Every escalation is a record that a machine stopped where the architecture said it must.

Traditional compliance tools fail at escalation in two directions. Some escalate everything: every configuration deviation, every evidence gap, every baseline mismatch generates an alert that routes to the compliance team. The volume overwhelms the team's capacity to triage. Critical findings are buried under routine deviations. The team develops alert fatigue and begins ignoring notifications, which means genuine governance decisions age without attention. Other tools escalate nothing: deviations are silently recorded in a log that no one reviews until assessment preparation begins. The compliance team discovers six months of accumulated drift in a two-week preparation window and cannot remediate in time. Neither approach serves the purpose of escalation, which is to ensure that the right human makes the right decision at the right time with the right information.

The policy surface for this boundary is AutomationPolicy: AUTO, APPROVAL, or MANUAL, declared per resource, alongside organizational risk thresholds, change windows, AI confidence thresholds, and AI budget constraints. The tiers map to the modes by default. Routine, reversible reconciliation, a configuration restored to its baseline value, defaults to AUTO and can be tightened per resource; consequential actions default to APPROVAL, where a human confirms before effect; and Tier-3 policy decisions are always MANUAL, never delegable by architecture. An APPROVAL-class action can earn AUTO promotion only through policy-time pre-approval: the human authority is established at declaration time and applies to every action meeting the declared confidence threshold, so the confirmation is derived, never skipped. Earned autonomy also decays; absent fresh verified outcomes inside a declared window, an envelope steps down one grade automatically, AUTO to APPROVAL to the MANUAL floor. And the design refuses to treat human silence as approval. Escalation classes declare liveness expectations, and when a consequential item sits unacknowledged past its bound (a day, by default), the pending action voids rather than proceeding, observation continues, the escalation re-routes up the accountability chain, and the item re-offers with full context when a human returns. An empty chair never approves. Pending decisions surface in Citadel, the command surface where action items and approvals render; the ruling itself always belongs to a person, recorded through Rampart's gates.

Approval Workflows

Overlay operations modify the control baseline a system is measured against. Adding a DISA STIG overlay layers new implementation requirements onto the base framework controls. Removing an overlay removes obligations. Modifying a control's parameters changes what the assessor will evaluate. The platform's overlay model carries four operation types: ADD introduces new controls or requirements, MODIFY changes parameters or implementation guidance for existing controls, REMOVE marks controls as not applicable with documented justification, and PARAMETER adjusts specific configuration values within a control's implementation. None of these operations should happen without deliberate human authorization. Each changes the compliance obligations that govern a system, and each must be justified, reviewed, and traceable to the person who approved the change.

Approval bottlenecks stall remediation when the approval workflow routes every decision through a single authority regardless of severity or impact. A configuration restoration that returns a system to its documented baseline should not require the same approval chain as a decision to remove a control from the assessment scope. Yet many compliance workflows treat all changes uniformly, routing every remediation action through the same approval queue. The result is a backlog where low-risk, well-understood remediations wait behind complex governance decisions. Engineers cannot remediate known drift because the approval has not been processed. The compliance posture degrades while the approval queue grows. The bottleneck is not the approval requirement itself. It is the failure to differentiate between approvals that require senior governance judgment and approvals that require operational confirmation.

The design gates overlay operations by their effect on what the organization owes, not by the verb in the request. Activating an overlay is a Manager-class action in Rampart's design, gated on entitlement and on the base framework being active; organizational overlays, the customer-defined rules an enterprise writes against its own policy, are reviewed and approved by an organization Manager before they apply. Deactivating an overlay is graded Tier-3, human only: deactivation removes obligations wholesale, and the rows most worth removing are the ones being failed, so the architecture assigns it the same elevation gate risk acceptance carries, and a deactivation without a cited human elevation refuses. Mapping confirmations follow the same discipline: Artificer is designed to propose, and a named human to dispose. An AI-suggested cross-framework mapping enters Rampart's registry excluded from the posture basis, fail-closed, until a human confirms it, and the design watches the oldest unconfirmed suggestion against a one-week watermark so confirmations cannot silently pile up. Every approval and refusal lands in the same tamper-evident org history, so when an assessor asks who approved a change, the answer is a record, not a recollection. No approval is implicit. No authorization is assumed.

Learning

Every human decision is also a signal, and the design treats it as one. A confirmed cross-framework mapping strengthens the strategy that produced it. A rejected mapping, with its rationale, informs what is suggested next. A false-positive ruling on a finding becomes triage-learning input. The intent is contextual, never prescriptive: precedent is meant to improve what is presented to the next decision-maker, not to pre-approve their decision, and it never reduces the number of decisions that require human authorization. Learning that quietly widened automation would erase the boundary this entire model exists to hold, so the design constrains how learning itself is allowed to change behavior.

Most compliance tools discard judgment. They record the outcome (approved, rejected, deferred) but not the reasoning, the context, or the precedent. When a similar decision arises six months later, the team has no institutional memory of how they handled it before, why they chose that path, or what the outcome was. The decision is made fresh each time, often by a different person, often with a different result. Inconsistent governance decisions create risk: if the same type of deviation is accepted for one system and rejected for another without a documented reason, the assessor will question the organization's governance maturity. If a mapping was confirmed by one reviewer and rejected by another for the same control pair, the cross-framework scoring becomes unreliable. Without decision memory, the compliance program cannot learn from its own history.

The architecture makes learning as governable as any other change. The platform's reasoning is designed as state, not memory: every act of consequential cognition, reasoning that will bear authority, commits as a reasoning transaction recording the context consumed, the model and skill versions applied, the conclusion with its confidence, and the effects to verify, and no consequential cognition happens outside the audited kernel that enforces this. Artificer is the user-facing surface of that cognition plane, designed as a lens on it rather than an oracle beside it. What the system learns is a recorded mutation to its genome, the versioned skills, rules, and prompts it runs on, and a mutation moves through proposed, shadow-evaluated, staged, and promoted stages with rollback, under the same gate discipline as code. No learned behavior is live on arrival; no drift is silent. The dispositions humans produce are the raw material: a false-positive ruling on a finding feeds triage learning as a recorded genome mutation, and the ratio of confirmed to suggested mappings is a tracked signal of suggestion quality. The loop closes where it started. Humans rule, rulings become recorded mutations, mutations are reviewed before they change behavior, and authority never migrates to the model.

The Right Balance

The human-in-the-loop model is not a philosophical position. It is a structural requirement driven by how compliance assessments actually work. Assessors do not evaluate whether your platform collected evidence automatically. They evaluate whether the evidence demonstrates control effectiveness. Assessors do not evaluate whether your cross-framework mappings were computed algorithmically. They evaluate whether the mappings are accurate for your specific implementation. Assessors do not evaluate whether your risk acceptances were processed through an approval workflow. They evaluate whether the right person, with the right authority, made an informed decision with adequate justification. The automation handles the volume. The human governance handles the accountability. Both are necessary. Neither is sufficient alone.

What the model changes is where human hours go. Evidence collection is designed to run on derived schedules instead of a compliance calendar, so the staleness that manual workflows accumulate becomes a surfaced defect rather than a quiet fate. Narrative drafting and cross-framework suggestion are designed to start from observed state, so the human contribution begins at review rather than at a blank page. The compliance team's output shifts from spreadsheet maintenance to governance: reviewing escalations, confirming mappings, ruling on risk. The difficulty does not disappear, and no one should promise that it does; judgment work is hard precisely because it carries consequence. The claim is narrower and more defensible. The mechanical volume belongs to machines, so the finite human bandwidth is spent where the human is the control.

The proof that the line holds is structural. The design's self-documenting property states it directly: declared states are the policies, actions are the evidence, the gap is the assessment, and history is the audit trail; the platform's operation is designed to be its own compliance documentation. Automated actions and human rulings ride the same append-only history but stay distinguishable on the record. An automated act carries its action contract and the policy it acted within; a human ruling carries its named actor and, for Tier-3 decisions, the step-up elevation cited on the posture row it produced. The chain is tamper-evident by construction: a per-org SHA-256 hash chain sealed under signed checkpoints, so ranges of history attest cryptographically rather than by assertion. Citadel is designed to render both layers without performing either: action items and approvals surface there, contested observations render side by side rather than resolving to a silent winner, and a taint lens shows on every committed transaction whether tainted input came anywhere near the decision. An assessor reading this record does not have to ask whether a human was in the loop. The record answers: here is what the machine did under policy, here is what a named person ruled, and here is the proof that neither was altered.