REAPS
REAPS is the governance architecture of Clarvus. Not a checklist, not a compliance framework bolted onto an existing system. Five structural constraints — Responsible, Explainable, Auditable, Policy-Driven, Sovereign — enforced at the inference layer, inherited by every product built on the platform.
The distinction between governance-as-architecture and governance-as-process is the difference between accountability that holds under pressure and accountability that dissolves when it is needed most. REAPS is the former.
01
Responsible
Governance at the inference layer, not the application layer.
Every inference Clarvus produces passes through an automated fairness layer before it reaches an end user. Bias detection runs on model outputs, not just training data, catching demographic parity violations in real time, surfacing them to supervisors, and escalating to human review when confidence drops below configured thresholds.
This is not a post-hoc audit capability. It is structural. The fairness layer cannot be bypassed by application code. Product teams inherit it without configuration. The result is that a bank deploying CertiVus or Stanli does not need to build its own bias detection; the platform already enforces it.
Regulatory guardrails are applied in the same layer. Where a regulation prohibits a specific inference (for example, using a protected attribute in a credit decision), that prohibition is encoded as a platform constraint. The LLM cannot produce that output. The application cannot request it.
Operationally
- —Automated demographic parity checks on all classification outputs
- —Protected attribute exclusion enforced at inference time, not application time
- —Confidence-triggered human escalation with configurable thresholds
- —Regulatory guardrails as platform constraints — not documentation to comply against
02
Explainable
Every output carries its reasoning. No black-box decisions reach users.
When Clarvus recommends a credit decision, it surfaces the factors that moved the recommendation — income trajectory, debt-service ratio, payment history — in language legible to a credit officer, a compliance team, or a customer. Reasoning chains, SHAP feature attribution, and counterfactual explanations are generated at inference time, not reconstructed from logs.
The distinction matters. Post-hoc explainability is an approximation. The explanation is derived from the output, not from the decision process itself. Clarvus generates explanations as part of the inference, meaning the explanation reflects what actually happened inside the reasoning chain, not a plausible reconstruction of it.
Every AI output has a human-readable justification attached. For regulated industries, this is not a convenience feature. It is the difference between an AI system that can be defended to a regulator and one that cannot.
Operationally
- —Reasoning chains generated at inference time, not reconstructed post-hoc
- —SHAP feature attribution on all recommendation outputs
- —Counterfactual explanations: what would have changed the outcome
- —Language calibrated to the audience: professional reasoning terms, not model diagnostics
03
Auditable
An immutable chain of custody for every request. Tampering is structurally impossible.
Clarvus maintains a complete, immutable chain of custody for every request the platform handles. Each LLM call, skill invocation, policy evaluation, and decision is hash-chained: each record includes the hash of the preceding record. Tampering with a single entry breaks the chain and surfaces immediately.
This architecture means that audit evidence is a primary output of the platform, not a side-effect of logging. Compliance teams do not need to assemble evidence packages from disparate log files. Clarvus exports complete, verifiable evidence packages for any time period on demand.
For institutions operating under RBI, SEBI, GDPR, or equivalent regulatory frameworks, this means that a compliance examination does not require weeks of evidence assembly. The platform maintains the evidence as a matter of course. The examination can proceed immediately.
Operationally
- —Hash-chained audit records — every LLM call, skill invocation, and policy evaluation
- —Tamper-evident by construction: broken chain is immediately detectable
- —On-demand evidence package export for regulatory examination
- —Complete decision provenance: inputs, reasoning, outputs, policy evaluations
04
Policy-Driven
Governance expressed as layered YAML policy. Regulatory changes propagate in minutes, not months.
Governance in Clarvus is expressed as layered YAML policies, not hardcoded logic. Four layers govern every inference: an immutable platform framework (L0), institutional defaults (L1), product-specific configurations (L2), and tenant customisations (L3). Each layer can only add constraints relative to the layer above it. No tenant can weaken a platform constraint. No product can override an institutional default.
This architecture has a practical consequence that is significant for regulated industries: when a regulatory requirement changes, administrators update a policy file. All products immediately inherit the stronger constraint. No application code changes. No redeployment of individual products. The propagation is instant and uniform.
For institutions managing AI compliance across multiple products and jurisdictions, this means that regulatory response time collapses from months (engineering cycles, testing, deployment) to minutes (policy file update, platform reload).
Operationally
- —Four-layer policy hierarchy: L0 platform → L1 institutional → L2 product → L3 tenant
- —Constraints are additive only: lower layers cannot weaken upper-layer rules
- —Regulatory changes propagate via policy file update — no code change, no redeployment
- —Policy audit trail maintained: every change recorded with author and timestamp
05
Sovereign
Your data stays in your jurisdiction. No vendor lock-in. No data residency compromise.
Data does not leave your jurisdiction unless you explicitly configure it to. Clarvus supports on-premises, air-gapped, hybrid, and multi-cloud deployments without architectural changes. The platform is infrastructure-agnostic by design.
Clarvus integrates with any LLM provider — Claude, GPT-4o, Gemini, Cohere, Mistral, and locally-hosted open-source models — without binding institutions to a single vendor. Provider selection can be changed at the policy layer. Products do not depend on a specific model; they depend on the platform's abstraction of model capability.
For institutions in India operating under DPDP Act data localisation requirements, or for European institutions under GDPR, this means that AI deployment does not require a data residency exception. The platform runs where the data must stay. Domain specialisation can deepen without loosening data sovereignty.
Operationally
- —On-premises, air-gapped, hybrid, and multi-cloud deployment support
- —LLM provider abstraction: swap providers at the policy layer, not the application layer
- —DPDP Act, GDPR, and multi-jurisdiction data residency compliance by architecture
- —No proprietary data formats: full data portability at exit
06. Why Architecture Matters
Governance that holds under regulatory scrutiny
The most common failure mode in enterprise AI governance is not malicious intent. It is organisational friction: teams that intended to build governance in, but found it easier to ship first and add accountability later. Later never arrives with the same rigour as the original deployment.
REAPS is designed to remove that choice. When governance is a platform property, no product team can opt out. When explainability is generated at inference time, no one has to remember to log it. When audit trails are hash-chained, no one can quietly amend them. The architecture does not rely on discipline. It relies on structure.
For regulated institutions, this is the difference between an AI programme that survives a regulatory examination and one that does not. Governance built in from the beginning produces evidence that is complete, consistent, and verifiable. Governance retrofitted after the fact produces evidence that is partial, inconsistent, and difficult to defend.
07. Procurement Evidence
REAPS as compliance evidence, not methodology
REAPS is not a design philosophy. It is an architectural enforcement mechanism compiled into every Clarvus AIOS deployment. Each principle is a structural constraint enforced at inference time — not a guideline applied at the discretion of an engineering team.
For procurement committees evaluating AI infrastructure vendors, the critical question is not whether a vendor claims to follow governance principles. It is whether those principles are verifiable, auditable, and independent of individual deployment decisions. REAPS is the answer to that question.
Bias detection and fairness verification as a platform output, not a model audit.
EU AI Act Article 9 (Risk management) · RBI AI Guidelines (Fairness) · SEBI AI governance circulars
Decision reasoning generated at inference time — not reconstructed from logs. Every output carries its justification.
GDPR Article 22 (Automated decision-making) · EU AI Act Article 13 (Transparency) · SOX (Audit trails)
Tamper-evident, hash-chained audit trail for every inference. Evidence packages exportable on demand for regulatory examination.
RBI audit requirements · DPDP Act accountability · SOX · HIPAA audit controls
Governance expressed as layered policy, not code. Regulatory updates propagate through the infrastructure layer without application changes.
DPDP Act compliance posture · GDPR consent management · Multi-jurisdiction policy enforcement
Data residency, BYOM/BYOL support, and air-gap deployment options. AI operates within your jurisdiction, under your control.
DPDP Act data localisation · RBI cloud policy · EU data residency requirements · CCPA
Evaluate Clarvus AIOS for your regulated environment
Every Clarvus AIOS deployment enforces the full REAPS governance stack at the infrastructure layer