HOW WE DELIVER · SHARED RESPONSIBILITY
The Reign shared-responsibility model.
What Reign does. What your team does. What our FDEs do. Published explicitly so no decision falls into a gap, and so the regulator never asks the question we have not already answered.
Reign Automated
Decisions Reign closes inside the platform without human intervention. The control plane evaluates, enforces, logs, and produces the audit trail.
- Block prompts that violate redaction policy (PII, MNPI, PHI, source-of-truth attribution).
- Enforce MCP tool-call allowlists at the Gateway layer; deny disallowed tools at the call moment.
- Capture every model invocation, agent action, and tool call as tamper-evident entries in the Audit Ledger (CAVR).
- Generate the Assurance Pack snapshot on a schedule (monthly, per-engagement, per-quarter) per regulatory framework.
- Apply Model Risk Validation gates to deployment pipelines (approved-model registry, version pinning, change-control checks).
- Trigger drift-detection alerts when production model behavior deviates from validation baseline.
- Route audit-ledger queries from internal audit, MRM, and Independent Assurance into ledger views without engineering involvement.
Customer Approval
Decisions Reign surfaces but a human in the customer organization owns. The platform constructs the artifact; the customer signs off.
- Approve a new model addition to the approved-model registry (MRM owns).
- Approve a Predetermined Change Control Plan (PCCP) for a Reign-governed model under FDA PCCP scope.
- Sign off on the quarterly Assurance Pack before submission to the regulator.
- Approve a policy exception (a single-instance allowlist that overrides a default deny).
- Approve a new agentic tool integration (a new MCP server or an external API the agent can call).
- Approve a redaction-policy change (e.g., expanding the redaction set for a new data class).
- Approve a new vertical Assurance Pack template for an examination not previously covered.
FDE Intervention
Decisions where iTmethods Forward Deployed Engineers run the work. Embedded inside customer change control, validation cadence, and audit posture.
- Map a new AI inventory (models, agents, prompts, tool calls) against the customer's regulatory frameworks.
- Severity-score gaps and produce the remediation plan with audit-defensible rationale.
- Build the Assurance Pack template for a regulator the customer has not yet faced.
- Operate the continuous-remediation SLA on a Reign Continuous engagement (P0 within 7 days, P1 within 21 days, P2 within 60 days).
- Lead quarterly posture reviews with the customer's CRO, audit committee, and Independent Assurance.
- Coordinate with the customer's Big-4 audit firm on the evidence the Assurance Pack must produce for a specific examination.
- Run the joint working session that aligns Reign's enforcement boundary with the customer's policy boundary at engagement start.
How we decide which column owns a decision.
- Reign automated by default. If the platform can decide and produce the evidence with no ambiguity, Reign decides.
- Customer approval where the decision is regulated, contractual, or board-attested. The customer owns the sign-off; the platform produces the artifact.
- FDE intervention where the decision requires regulator-fluency, specialty modeling, or cross-functional negotiation that the customer has not yet built capacity for in-house.
The customer boundary, stated explicitly.
The customer always owns the AI it deploys, the data it ingests, the regulatory commitments it makes, and the audit posture it presents. iTmethods owns the operational substrate (Reign, Forge, FDE) that makes those commitments executable, observable, and defensible. The boundary is published explicitly so no decision falls into a gap.