Canonical Institutional Route 1 4-Page Brief 2 Review Index 3 Evidence Request 4 Protected Diligence
Policy note · Protected diligence boundary

Control Evidence Boundary — Protected Diligence Policy Note

This page defines the boundary between public governance narrative and diligence-complete institutional evidence, and specifies the minimum artefacts that ministries, MDBs/DFIs, auditors, procurement teams and IT/security reviewers should request before relying on Terra Vita Hub in any programme, portfolio or sovereign context.

Protected diligence position

Control Evidence Boundary, Operational Assurance, Evidence Map and technical artefacts are provided under protected diligence and form the basis for reliance.

Public narrative is not reliance evidence. Formal reliance requires the protected artefacts listed in the Procurement-Safe Minimum Evidence Request.

Reliance boundary

No institution should rely on public pages alone. Formal approval must be based on protected, deployment-specific evidence and contractual commitments.

Public governance narrative is not a certification or attestation. Formal reliance must be based on protected demonstrations, deployment-specific artefacts, contractual commitments, and independent evidence.

Current Assurance Status

This page states the current public assurance boundary to avoid accidental over-reliance.

CertificationsNo public SOC 2 or ISO certification is asserted by this page. Request certification, readiness evidence or compensating controls under protected diligence.
Pen-test postureIndependent testing evidence is not disclosed publicly. Request the latest summary and remediation posture where applicable.
SLA / uptimeNo universal public SLA is asserted. Request deployment-specific availability, support, RPO/RTO and DR commitments.
InteroperabilityIntegration is described at control-domain level. Request API, identity federation, connector and audit-log evidence.

1. Assurance Boundary (Non-Negotiable)

Public governance language is not a certification, attestation, SLA, or security guarantee.

Formal reliance must be based on protected demonstrations, deployment-specific artefacts, contractual commitments, and independent evidence.

No public statement replaces SOC 2 / ISO-aligned controls, data residency proof, security architecture documentation, SLA/uptime commitments, integration governance, or audit-event lineage. Institutions must request the evidence listed below before approval or deployment.

2. What Is Public Narrative (Informational Only)

Public pages describe the governance model and institutional posture. They explain:

Governance spineReviewer accountability, evidence classes, decision chain, escalation logic and export posture.
Authority limitsRole boundaries, non-substitution of statutory authority, financial decisions, MRV authority and committee judgement.
Operational postureHigh-level security, reliability, data lifecycle, integration and safeguard domains.
MRV boundaryMRV signal governance without replacing approved methodologies or verification authorities.

These descriptions explain the model but do not constitute operational proof.

3. Diligence-Complete Evidence Schema

This section uses the same schema as the Minimum Evidence Request so procurement, IT/security and vendor-risk teams can cross-reference the two pages without interpreting separate lists.

A. Governance & Reviewer Controls
  • Reviewer identity preservation.
  • Escalation configuration.
  • Override visibility.
  • Decision-chain attribution.
  • Audit-event samples.
  • Evidence lineage demonstration.
B. Security & Operational Reliability
  • Encryption at rest/in transit.
  • Key management posture.
  • Tenancy model.
  • Uptime bands and incident response.
  • RPO/RTO expectations and DR posture.
  • Access-control model.
C. Data Lifecycle & Residency
  • Data residency statement.
  • Retention and deletion logic.
  • Evidence versioning.
  • Export posture and institution-controlled formats.
D. Integration & Interoperability
  • Integration governance.
  • API boundaries.
  • Data ingestion controls.
  • Spatial/MRV evidence handling.
E. Programme-Specific Configuration
  • Role model.
  • Reviewer groups.
  • Escalation pathways.
  • Evidence classes used.
  • Export/reporting configuration.
F. Contractual Commitments
  • SLA availability, response times and support model.
  • Incident-response and support commitments.
  • Data export and termination guarantees.
  • Deployment-specific obligations, such as residency, segregation and audit access.

4. Procurement-Safe Request List

Use the six headings below exactly as the minimum artefact request in procurement, IT/security or RFP review.

Reviewer support tools

5. Institutional Position

Terra Vita Hub provides a governed evidence spine for institutional decisions. It does not replace statutory authority, MRV methodologies, lending decisions, or public-sector approval processes.

All institutional reliance must be based on protected, verifiable, deployment-specific evidence.