Compliance-Centric Frame: Core Governance & Metrics

• Compliance-centric frame is a design approach where compliance obligations shape architecture, workflows, and metrics from the outset.
• It integrates regulatory, privacy, and technical standards through methods like static analysis, policy mapping, and runtime metric aggregation.
• This framework redefines compliance as a continuously measurable, iterative process that balances formal verifiability with practical implementation challenges.

Searching arXiv for the cited works to ground the article and verify relevance. A compliance-centric frame is a design, governance, or analytical orientation in which compliance is treated as the primary organizing principle of a system rather than as an ex post audit condition. Across the literature, this orientation appears in user-configurable privacy enforcement, enterprise control libraries, agentic financial-crime workflows, continuous LLM governance, and federated data processing, where policies, regulatory obligations, evidence, and oversight determine what computations, workflows, or control actions are admissible (Khan et al., 2020, Sonkar, 16 May 2025, Axelsen et al., 16 Sep 2025, Dussert, 23 May 2026, Kokash et al., 22 Feb 2026). In some works, the term extends beyond legal regulation into business-process measurement and technical engineering, where “compliance” is itself the central evaluative quantity and the surrounding framework is organized around proving, measuring, or minimizing it (Lam et al., 2020, Gupta et al., 4 May 2026, Sun et al., 14 Jul 2025).

1. Definition and organizing logic

Across these works, a compliance-centric frame can be understood as a systematic arrangement in which compliance obligations are not peripheral constraints but the basis on which architecture, workflow, metrics, and authority structures are constructed. This contrasts with reactive models in which directives are documented and then assumed to be followed, or with audit-time models in which compliance is treated as a binary verdict delivered around deployment time rather than as a continuously maintained property (Lehto et al., 2021, Dussert, 23 May 2026).

Several literatures define the frame by opposition to weaker baselines. In privacy-preserving analytics, the contrast is with systems that “focus on reducing custodial risk and lack features empowering data owners,” whereas a compliance-centric design requires analysis code to be statically checked against user-defined policies before raw data can be accessed (Khan et al., 2020). In business-process management, the contrast is with binary “YES-NO” notions of process compliance, which are said to be inadequate because many real cases occupy a gray zone of partial compliance that must be quantified across dimensions such as time, money, role, data, and quality (Lam et al., 2020). In GDPR automation, the contrast is with consumer-centric and regulator-centric approaches; the frame shifts attention to controllers, processors, and law firms as “agents of compliance,” with privacy documents treated as compliance instruments and evidence of accountability (Amariles et al., 2020).

A further recurring feature is integration across viewpoints. In regulatory requirements engineering, legal, business, requirements, and architecture viewpoints are treated as distinct but coordinated perspectives, and compliance by design depends on maintaining consistency between them through structured artifacts rather than through ad hoc communication (Kosenkov, 10 Mar 2026). This suggests that a compliance-centric frame is not merely a rule set. It is a way of organizing specification, execution, verification, and evidence so that admissibility under a policy, regulation, or norm is the first question asked of a system, not the last.

2. Formalization and metrics

The literature formalizes compliance in several distinct but related ways: as a program–policy relation, as a refinement relation, as an argumentative consequence relation, and as a graded or continuous metric. In PrivFramework, a data capsule pairs data and policy, and a processing step is compliant only if the analysis program satisfies the current policy, written as $\pi \models P$; static analysis may also derive a residual policy $P'$ so that compliance is represented compositionally rather than as a single Boolean decision (Khan et al., 2020). In "Checking Security Policy Compliance" (0809.5266), a low-level policy is compliant with a high-level policy iff there exists a valid refinement path from the high-level policy to a refined ground decision view such that the low-level decision view implies that refined view. This places compliance inside a refinement calculus over actions, obligations, and authorizations rather than treating it as a surface-level rule match.

In "Theory of Regulatory Compliance for Requirements Engineering" (Jureta et al., 2010), compliance is explicitly not reduced to monotonic entailment. The compliance problem is to find a framework $\mathcal{C} = (Spec(R), L, C, \vdash_c)$ such that

$Spec(R), C \ \vdash_c \ L,$

where $\vdash_c$ is an argumentation-based, non-monotonic compliance relation. A requirement set is compliant when there is an acceptable argument that the specification together with compliance assumptions satisfies the interpreted legal norms, and no acceptable counter-argument that it does not. This formalization makes contestability intrinsic to compliance verification.

Other works quantify compliance directly. "Towards a Formal Framework for Partial Compliance of Business Processes" (Lam et al., 2020) models compliance as a real value in $[0,1]$ at task, trace, and process levels, with attribute-level compliance scores aggregated across dimensions and then across execution paths. "Compliance as a Trust Metric" (Wu et al., 3 Jan 2026) turns regulatory compliance behavior into a dynamic trust signal: violations are scored along Volume, Duration, Breadth, and Criticality, accumulated into a decaying penalty, and mapped to a bounded compliance score through

$Comp(p, W_k) = 1 - \tanh(\text{Penalty}_k).$

This converts compliance from a pass/fail attribute into a continuously evolving reputation metric.

A runtime variant appears in LLM governance. "Who judges the judges? Governance from metrics: a runtime framework for continuous LLM compliance monitoring" (Dussert, 23 May 2026) defines criterion-level scores $s_i(j,u)\in[0,1]$, aggregates them into profile-level governance scores,

$S_P(u) = \sum_{i=1}^{n} w_i \cdot s_i(\pi(c_i),u),$

and treats inter-judge variance

$$\sigma_u^2 = \frac{1}{|J|}\sum_{j\in J}(S(j,u)-\bar S(u))^2$$

as a regulatory uncertainty signal that warrants human arbitration. A related incentive-theoretic line appears in ZETAR, where compliance is modeled through trustworthiness of recommendations and summarized through the Initial Security Level and Average Compliance Enhancement Level, which the paper explicitly interprets as measures of how compliant and persuadable an insider is under a given security objective (Huang et al., 2022).

Taken together, these formalizations show that a compliance-centric frame need not choose between symbolic rules and quantitative scores. It can be predicate-based at one layer, argumentative at another, and continuous at runtime.

3. Architectural patterns and enforcement mechanisms

Architecturally, compliance-centric systems tend to externalize policy and internalize enforcement. They separate obligations from business logic, attach policies to governed artifacts, and ensure that execution paths pass through explicit compliance gates.

Setting	Compliance mechanism	Representative instantiation
Privacy-preserving analytics	Data capsules, PrivPolicy, static analysis, residual policies, AMD SEV TEE	PrivFramework (Khan et al., 2020)
Cloud compliance governance	Modular control families, meta-mapping, CAB, unified evidence reuse	Cisco CCF v4.0 (Sonkar, 16 May 2025)
Financial-crime workflows	Artifact-centric agents, bounded roles, audit logging, structured escalation	Agentic AI for FCC (Axelsen et al., 16 Sep 2025)
Federated data processing	BraneHub + Brane, policy-as-code, OPA/eFlint, STP-RBACG	FDP compliance management (Kokash et al., 22 Feb 2026)
Regulated blockchain access	Local zk-SNARK proving, verifier contract, access registry, revocation lifecycle	ZK-Compliance (Khadka et al., 16 Mar 2026)

In these systems, the common pattern is not a shared implementation language but a shared control topology. PrivFramework stores each submitted dataset in a data capsule, couples it to a formal policy, statically analyzes Python programs against that policy, and executes only validated programs inside a Trusted Execution Environment; if the policy is only partially satisfied, execution yields an intermediate capsule governed by a residual policy rather than unrestricted output (Khan et al., 2020). Cisco’s CCF v4.0 uses a different mechanism but the same logic: a single internal control library is mapped many-to-many onto ISO 27001, SOC 2, NIST, FedRAMP, EU CRA, DORA, NIS2, and related frameworks, so that products are governed through a stable internal control system rather than through duplicated framework-specific implementations (Sonkar, 16 May 2025).

In agentic compliance systems, the frame becomes workflow-native. The FCC architecture uses an FCC Orchestrator Agent, Investigation Agent, and Report Compilation Agent, operating over compliance artifacts such as alerts, cases, STRs, and logs, with task-specific model routing and explicit audit trails (Axelsen et al., 16 Sep 2025). In federated data processing, the analogous architecture combines a design-and-governance layer with a distributed execution layer. The formal access model is the Spatio-Temporal Purpose-Aware RBAC Graph

$P'$0

and authorization is defined only when role–object assignment, temporal validity, regional compatibility, purpose limitation, and data minimization all hold (Kokash et al., 22 Feb 2026). In user-centric blockchain compliance, the same architectural principle appears as local proof generation and on-chain verification: the user proves an eligibility predicate without revealing the underlying data, and downstream access control depends on an authorization state rather than on stored identity documents (Khadka et al., 16 Mar 2026).

This suggests that compliance-centric architecture is characterized less by any single enforcement primitive than by a repeated pattern of policy attachment, explicit admissibility checks, and persistence of obligations across system boundaries.

4. Governance, lifecycle, and human oversight

A compliance-centric frame almost always introduces a governance layer that is distinct from operational execution. In Cisco’s CCF v4.0, that role is played by the Control Advisory Board, composed of representatives from Compliance, Product Security, Internal Audit, and Regulatory Intelligence. The CAB controls mappings, resolves clashes between frameworks, approves new or updated controls, and maintains alignment with evolving worldwide standards, while operational teams implement the controls and maintain evidence (Sonkar, 16 May 2025). The frame is therefore not only control-centric but governance-layered: interpretation and mapping are stabilized at one level so that implementation can vary without losing compliance coherence.

In agentic financial-crime compliance, governance appears as bounded autonomy. Agents hold responsibility for sub-decisions such as triage, investigation, or STR drafting, but human compliance officers remain the accountable actors vis-à-vis regulators. Structured handovers—agent to agent and agent to human—encode governance into the workflow, and multistep decisions that affect regulatory risk require explicit human checkpoints (Axelsen et al., 16 Sep 2025). A different but related governance mechanism appears in LLM compliance monitoring: govllm uses a panel of criterion-specific regulatory judges, treats disagreement as a regulatory uncertainty signal rather than mere noise, and routes high-variance cases to human arbitration, thereby operationalizing selective human oversight instead of relying on a blanket override model (Dussert, 23 May 2026).

Continuous compliance approaches make governance temporal as well as organizational. In calculated event-log layers, compliance rules are evaluated over operational traces, rule violations are materialized as calculated events, and real-time or near-real-time feedback is delivered to compliance officers so that preventive actions occur in parallel with process execution rather than after the fact (Lehto et al., 2021). In regulatory requirements engineering, the governance mechanism is artifact-based rather than event-based: AM4RRE assigns responsibilities to legal experts, domain experts, requirements engineers, and software architects, couples them to explicit goal, context, milestone, and content models, and uses viewpoint coordination as the core means of sustaining compliance by design across the SDLC (Kosenkov, 10 Mar 2026).

A further extension appears in ZETAR, where governance is mediated through information design rather than only through rules. A common audit policy is combined with bespoke recommendation policies, and compliance is improved by learning trustworthy regions of the policy space in which insiders voluntarily follow recommendations aligned with organizational security objectives (Huang et al., 2022). This broadens the governance repertoire of compliance-centric systems from command-and-control toward incentive-aligned coordination.

5. Domains, scope, and semantic variation

Most works use the term in regulatory, privacy, or security contexts, but the scope of the frame is broader than legal compliance alone. In GDPR document automation, privacy policies, records of processing activities, DPIAs, contracts, and internal policies are treated as compliance instruments whose completeness, lawfulness, readability, and consistency provide evidence of accountability (Amariles et al., 2020). In blockchain compliance, the same orientation is reframed around a user-governed lifecycle—Grant, Verify, Revoke—in which compliance becomes a dynamic, revocable authorization session rather than a permanent identity handover (Khadka et al., 16 Mar 2026). In analyses of EU cybersecurity legislation, the frame is explicitly risk-based: compliance obligations across CSA, GDPR, CRA, CER, and NIS2 are structured around likelihood, severity, impact, “appropriate” and “proportionate” measures, and documentary demonstration of risk assessment and mitigation, even though notable gaps remain around acceptable risk and residual risk (Ruohonen et al., 29 Aug 2025).

The term also has a technical meaning in engineering disciplines that is distinct from legal conformity. In structural optimization, “compliance” denotes the work done by external forces under the resulting displacements, and the proposed framework is compliance-centric because design and state variables are jointly optimized to minimize this quantity under physics and volume constraints (Sun et al., 14 Jul 2025). In grid-forming inverter assessment, compliance refers to whether a device behaves like a voltage source behind impedance over a specified frequency range; the proposed criterion is defined through minimum expected $P'$1 and $P'$2 Bode characteristics and is shown to be equivalent to existing time-domain pass-fail criteria (Gupta et al., 4 May 2026). These uses are technically unrelated to GDPR-style compliance, but they preserve the same meta-structure: a single evaluative quantity is elevated into the governing variable of design, testing, or system assessment.

This semantic variation matters because it prevents a common misconception. A compliance-centric frame is not tied to any single regulator, policy language, or enforcement regime. What persists across domains is the centering of admissibility, constraint satisfaction, or compliance quantity in the specification of the system itself.

6. Limitations, trade-offs, and open problems

The literature is explicit that compliance-centric designs introduce their own constraints. Static enforcement is sound but conservative: PrivFramework may reject safe programs because the analyzer works with approximations, and the threat model assumes TEEs such as AMD SEV are trusted and correctly implemented (Khan et al., 2020). In agentic financial-crime compliance, the prototype remains mostly descriptive and rule-based, predictive enrichment is future work, and regulatory approval is ongoing rather than complete (Axelsen et al., 16 Sep 2025). In runtime LLM governance, small regulatory judges achieve agreement rates from 51.5% to 69.1%, exhibit position bias that can degrade agreement by up to 25 percentage points, and therefore provide decision support rather than a substitute for legal audit (Dussert, 23 May 2026).

Federated compliance management is still at prototype stage. The architecture demonstrates how legal and organizational requirements can be collected and translated into machine-actionable policies, but the authors identify open questions around full end-to-end deployment, scalability of policy evaluation, LLM reliability, and interoperability with existing governance tooling (Kokash et al., 22 Feb 2026). The user-centric blockchain pattern likewise remains preliminary: the current prototype relies on self-attestation, proof binding and replay resistance remain open issues, and on-chain verification costs make Layer 2 deployment important for practical use (Khadka et al., 16 Mar 2026). In artifact-based regulatory requirements engineering, empirical understanding of how integrated compliance by design should be achieved remains limited, and the current model is presented as an intermediate result awaiting broader evaluation (Kosenkov, 10 Mar 2026).

A separate class of open problems concerns the legal semantics of compliance itself. The analysis of EU cybersecurity legislation identifies notable gaps around acceptable risks, non-probabilistic risks, and residual risks, even though those notions are operationally central to real-world compliance programs (Ruohonen et al., 29 Aug 2025). This suggests a broader limitation of compliance-centric frames: the more central compliance becomes, the more costly ambiguity in the governing norm becomes. Formalization, evidence generation, and automation can reduce uncertainty, but they cannot eliminate interpretive gaps that are built into the law or into organizational policy.

The cumulative implication is not that compliance-centric frames are overextended, but that they redistribute complexity. They replace implicit trust, post hoc checking, and siloed interpretation with explicit policy models, verification procedures, metrics, and governance mechanisms. The benefit is tighter control and stronger evidence; the cost is sustained investment in formalization, traceability, and cross-functional coordination.