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.

Open evidence request Download PDF request Operational Assurance

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.

Minimum Evidence Request Operational Assurance Redacted proof objects

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 Attestation Posture

This page states the current public assurance boundary to avoid accidental over-reliance. Terra Vita Hub is institutional governance and workflow software, reviewed as enterprise assurance infrastructure - not a financial service, rating activity, or MRV methodology.

Domain	Current public posture	Evidence to request
SOC 2	Not asserted as completed in public materials.	Status, roadmap, control mapping, readiness evidence or report where available.
ISO 27001	Alignment may be described; certification is not claimed unless separately evidenced.	Policy set, control matrix, certification artefact or readiness evidence.
Pen-testing	Sensitive findings are not public.	Frequency, scope, latest summary and remediation posture.
Residency	Deployment-configurable.	Hosting region, backup/failover, export rules, retention and deletion posture.
Key-management	Model is deployment-specific.	Provider-managed, customer-managed, BYOK/HYOK availability and rotation posture.

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.

Governance configuration pack: reviewer roles, escalation, overrides, audit-event samples.
Security and operational assurance pack: encryption, uptime, DR, incident response.
Data residency and lifecycle statement.
Integration governance and API boundary documentation.
Evidence lineage demonstration: versioning, attribution and export posture.
Programme-specific configuration, where applicable.
Contractual commitments: SLA, support, availability, data export guarantees.

Open full request template Download PDF

Reviewer support tools

Glossary & Acronym Sheet Redacted Proof Objects

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.