Evidence backbone

Evidence-Grade Audit and Provenance Capture

The evidentiary backbone of the platform. Records events, links them into a chain, applies tamper-evident sealing where supported, and produces exportable evidence packs.

DocumentedApply for Grant Access

Mission problem

Boards, donors, regulators, and auditors increasingly require credible, coherent evidence rather than screenshots and narrative claims.

Who it protects

· NGOs
· Institutes
· Think tanks
· Advanced R&D labs

Sensitive assets involved

· Institutional accountability
· Grant assurance
· Regulator readiness

Required inputs

· Events from every other service
· Reviewer decisions
· Policy versions

Connected systems

· All connected services within the overlay

How the service works

Events are timestamped and linked into a verifiable chain.
Signing or sealing is applied where supported by the environment.
Modifications to a linked record become visibly detectable.
Evidence packs bundle related records for export.

Human-review points

· Evidence pack approval before external release

Evidence produced

· The evidence chain itself
· Signed pack manifests

Service interlocks

· Every service in the portfolio

Evidence Provenance Chain

Modification visibly breaks the chain. Tamper-evident, not tamper-proof.

Illustrative scenario

Illustrative: donor assurance package

A quarterly donor package is assembled from linked records covering access decisions, exceptions, incidents, and vendor changes, then reviewed before release.

Deployment prerequisites

· Read access to overlay-generated events
· Named evidence stewards

Beneficiary responsibilities

· Approve external evidence releases
· Maintain retention policy

Limitations and non-claimsRequires validation

· Tamper-evident is not tamper-proof; the mechanism reveals modification rather than preventing it.
· Signing and sealing capabilities depend on the deployment environment.

Frequently asked

Can we export packs on demand?

Yes. Evidence packs can be composed and reviewed at any time.

How is tamper-evidence achieved?

Events are hashed and chained; each new record commits the prior chain state. Modification of a linked record breaks the chain and becomes visibly detectable on verification.

Where is the chain stored?

Within beneficiary tenancy by default, with signed manifests exportable to external escrow if the beneficiary requests it.

Delivery model

Onboarding → Policy Definition → Controlled Rollout → Steady-State Assurance. Every phase produces named evidence artifacts.

4-Phase Delivery Timeline

Phase 1
Onboarding
Read-only connection to overlay-generated events from every other service in scope. Retention policy and evidence-steward roster established.
- · Event source inventory
- · Retention policy of record
Phase 2
Policy Definition
Signing/sealing configuration, evidence-pack templates, review-before-release rules, and steward authority are ratified.
- · Evidence policy of record
- · Pack template library
Phase 3
Controlled Rollout
Chain runs in shadow mode; sample packs are composed and reviewed. Verification tooling is rehearsed with named stewards.
- · Shadow-mode chain report
- · Sample pack review
Phase 4
Steady-State Assurance
Ongoing chain verification, quarterly evidence integrity reports, and steward rotation.
- · Quarterly chain integrity report
- · Steward rotation record

Beneficiary scenarios

Illustrative

Donor quarterly assurance pack

A quarterly donor pack is assembled from linked records covering access decisions, exceptions, incidents, vendor changes, and reviewer approvals. Stewards verify the chain and sign the pack manifest before external release.

Illustrative

Regulator inquiry — targeted evidence index

A regulator requests evidence for a specific window. Stewards compose a scoped pack, verify chain integrity across the window, and release under a signed manifest with a full lineage index.

Engineering detail

Integration model+

Event ingestion from every overlay service in scope, plus optional export of signed manifests to external escrow. No modification of source systems.

Data flows+

Events are timestamped at capture, hashed, and linked into a verifiable chain. Signing or sealing is applied where the deployment environment supports it. Packs are composed from linked records with full lineage.

Cryptographic components+

SHA-256 event hashing with chain linkage. Signing uses beneficiary-controlled keys where available; sealing uses environment-provided attestation where supported. Crypto-agility is maintained via Service 09.

Logging architecture+

The chain is the log. Every event, every steward action, every pack composition, and every external release is itself a chain entry.

Deployment prerequisites+

Read access to overlay-generated events, named evidence stewards, and a ratified retention policy.

Operational limits+

Tamper-evident is not tamper-proof; the mechanism reveals modification rather than preventing it. Signing depends on environment support.

Governance model

Approval gates

· Retention policy changes require steward-lead ratification.
· Evidence-pack composition for external release requires named steward approval.
· External release requires review-before-release sign-off.
· Chain-integrity verification failures require executive sponsor notification.

Exception handling

Verification-failure events are themselves recorded in the chain with steward disposition and remediation trace.

Rollback paths

The chain is append-only; corrections are new entries that reference and supersede prior entries. Original entries are never overwritten.

Beneficiary control boundaries

The beneficiary owns retention policy, steward rosters, and external-release authority. The overlay records; humans release.

Evidence and reporting outputs

· The evidence chain itself
· Signed pack manifests
· Steward approval record
· Chain-integrity verification report
· External-release log
· Retention-policy version history
· Correction-entry lineage
· Quarterly chain integrity report

Grant scope

Included

· Evidence chain deployment across in-scope overlay services
· Pack template authoring and steward onboarding
· Verification-tooling rehearsal
· Steady-state chain integrity reporting

Beneficiary responsibilities

· Name evidence stewards and rotation
· Ratify retention and release policy
· Approve external releases

Timeline

Typical: 4-phase delivery over 6–10 weeks, running in parallel with other in-scope services.

Explicit exclusions

· Legal admissibility warranty
· Guarantee of environment signing/sealing capability
· Retention beyond ratified policy

Portfolio interlock

Portfolio Interlock Web

Predecessors, successors, and operational interlocks across the portfolio.

Natural predecessors

· Policy-Based Access Mediation
· Sensitive Data Classification and Routing
· Cross-System Threat Anomaly Detection
· Secure Workflow Orchestration with Human Review Gates

Natural successors

· Board-, Donor-, and Regulator-Ready Security Reporting
· Compliance and Jurisdictional Mediation

Operational interlocks

· Every service in the portfolio contributes and reads from the chain.

Risks and non-claims

Requires validation

· Tamper-evident is not tamper-proof; the design surfaces modification rather than preventing it.
· Signing/sealing capability is environment-dependent and labeled explicitly in every pack.
· The chain does not itself certify third-party outcomes or legal admissibility.

Discuss this service in your context

All services Grant access