Evidence Automation

Asiri can collect operational evidence from connected systems and map the result to controls, workflow tasks, and auditor-facing exports. The goal is not to claim automatic compliance. The goal is to make evidence current, traceable, and reviewable so a customer, DPCO, or auditor can see what is real.

What gets automated

Evidence automation runs against connectors that a tenant has explicitly configured. Typical sources include:

Each connector uses the least-privilege credential model available for that system. Where a provider supports read-only APIs, Asiri uses read-only access for collection. Credentials are stored as connector secrets and used only to run evidence checks.

Evidence object shape

Every connector result is normalized before it becomes part of the evidence ledger:

{
  "source": {
    "provider": "github",
    "service": "GitHub",
    "connectionId": "connection-id",
    "externalRef": "github://branch-protection?sample=10"
  },
  "check": {
    "id": "github.default_branch_protection",
    "title": "Default branch protection",
    "status": "pass",
    "severity": "high"
  },
  "controlMapping": {
    "linkedControlIds": ["SEC-002", "AUDIT-001"],
    "primaryControlId": "SEC-002"
  },
  "freshness": "current",
  "owner": "user-id",
  "rawPayloadHash": "sha256:...",
  "collectedAt": "2026-05-31T10:00:00.000Z",
  "validUntil": "2026-06-01T10:00:00.000Z",
  "remediationGuidance": "Enable branch protection or document exceptions."
}

This normalized shape prevents AWS, GitHub, Okta, Jira, Linear, and other connectors from becoming separate mini-systems. Controls can compare evidence consistently across sources.

Freshness and scheduling

Evidence has a validity window. Asiri marks evidence as current, stale, expired, or missing based on the connector cadence and control expectation.

Scheduled runs update lastSyncAt, nextSyncAt, failure reason, retry state, credential health, and the connector’s recommended action. Failed checks can create workflow tasks with severity, owner, SLA, and remediation guidance.

Raw payload traceability

Auditors need to know that Asiri did not only summarize the evidence. When a connector provides a raw payload, Asiri stores a redacted snapshot metadata record with:

• payloadHash
• redactionVersion
• redacted field list
• collection time
• validity window

Exports include the raw payload hash trace so reviewers can reconcile the final evidence item to the original source artifact without exposing unnecessary secrets or personal data.

Runtime assurance pack

The Evidence Engine page includes a connector runtime assurance pack. For every connector it shows:

• connection status
• permissions required
• last successful sync
• last failed sync
• evidence collected
• mapped controls
• credential health
• retry or reconnect guidance
• auditor-visible proof references

This is operational proof for review. It is not an external certification, regulator approval, legal opinion, or audit conclusion.

How to operate it

1. Connect the source system from Integrations.
2. Review required permissions before saving credentials.
3. Run the first evidence collection from Evidence Engine.
4. Review failed, warning, manual, and stale checks.
5. Assign remediation tasks to owners.
6. Approve or document exceptions where a human decision is required.
7. Export the audit pack when a buyer, DPCO, or auditor asks for evidence.

API evidence ingestion

Customers can also push evidence through the public API when a source is not yet supported by a native connector. Use evidence:write scoped API keys, keep raw payloads redacted, and include a stable idempotency key for every submission. See Production Ready and API Reference for the public API contract.