SafeGate v6.3 / Evidence Timeline / Audit Viewer

Show the trust path as a minimal audit timeline.

v6.3 defines a simple reviewer-facing audit viewer: event, time, result, and boundary.

No noisy dashboard. No internal logs. No secrets. Just enough evidence to show what happened after payment.

30-Second v6.3 Summary

SafeGate evidence should be readable as a timeline: PAYMENT_FINALIZED → RECEIPT_PROOF_CREATED → ACCESS_UNLOCKED → MERCHANT_RECORD_WRITTEN → RECEIPT_VERIFIED → EVIDENCE_SUMMARY_READY.

Each row should answer four things: what happened, when, result, boundary.

1. Interactive Public Audit Viewer Mock

Use the buttons below to switch between a successful controlled evidence timeline and safe failure timelines.

Click a timeline button to load a mock audit view.

2. Minimal Timeline Row Format

{
  "event": "RECEIPT_VERIFIED",
  "time": "mock_timestamp",
  "result": "OK",
  "boundary": "Pi Testnet controlled evidence / no Mainnet settlement claim"
}

3. Timeline Design Rules

Keep the viewer minimal: event, time, result, boundary.
Do not expose backend secrets, service role keys, wallet passphrases, access tokens, database URLs, stack traces, or raw provider payloads.
Use public-safe event names instead of internal debug logs.
Show failed or blocked states clearly without implying successful unlock.
Ambiguous verification must show fail-secure behavior.
Replay-like attempts must preserve existing state and create an audit-relevant event.
Future production viewer should support role-based visibility: public, merchant, reviewer, operator.

4. Success Timeline Example

Event	Time	Result	Boundary
PAYMENT_FINALIZED	mock_timestamp	OK	Pi Testnet controlled payment flow.
RECEIPT_PROOF_CREATED	mock_timestamp	OK	Receipt proof created after payment finalization.
ACCESS_UNLOCKED	mock_timestamp	OK	Digital access unlocked after verified payment state.
MERCHANT_RECORD_WRITTEN	mock_timestamp	OK	Merchant-side evidence recorded.
RECEIPT_VERIFIED	mock_timestamp	OK	Reviewer-facing receipt verification result.
EVIDENCE_SUMMARY_READY	mock_timestamp	OK	Evidence summary generated for review.

5. Safe Failure Timeline Examples

Replay Attempt

Duplicate verification or replay-like behavior should not create a new unlock. It should preserve existing state and log a blocked event.

{
  "event": "VERIFY_REPLAY_ATTEMPT",
  "result": "BLOCKED",
  "safeBehavior": "PRESERVE_EXISTING_STATE_AND_LOG"
}

Ambiguous Verification

If payment state cannot be confirmed safely, SafeGate should fail secure.

{
  "event": "VERIFY_TIMEOUT_FAIL_SECURE",
  "result": "AMBIGUOUS",
  "safeBehavior": "NO_UNLOCK"
}

Internal Error Safe

Internal errors must not leak stack traces, environment variables, service role keys, or database details.

{
  "event": "VERIFY_INTERNAL_ERROR_SAFE",
  "result": "ERROR_SAFE",
  "safeBehavior": "NO_SECRET_LEAK_NO_UNLOCK"
}

6. Proposed Audit Viewer Output

{
  "ok": true,
  "mode": "public_audit_viewer_mock",
  "receiptId": "SG-RCPT-1781465776152",
  "orderId": "TP-DEMO-273551",
  "network": "Pi Testnet",
  "timeline": [
    {
      "event": "PAYMENT_FINALIZED",
      "time": "mock_timestamp",
      "result": "OK",
      "boundary": "Controlled Pi Testnet evidence"
    },
    {
      "event": "RECEIPT_PROOF_CREATED",
      "time": "mock_timestamp",
      "result": "OK",
      "boundary": "Receipt proof created"
    },
    {
      "event": "ACCESS_UNLOCKED",
      "time": "mock_timestamp",
      "result": "OK",
      "boundary": "Digital access unlocked"
    },
    {
      "event": "MERCHANT_RECORD_WRITTEN",
      "time": "mock_timestamp",
      "result": "OK",
      "boundary": "Merchant evidence recorded"
    }
  ],
  "publicClaims": {
    "productionPublicApiClaim": false,
    "productionApiKeyIssued": false,
    "backendSecretExposed": false,
    "piMainnetSettlementClaim": false
  }
}

7. V6 Progression

v6.3 Evidence Timeline

Current stage: minimal audit viewer direction.

8. Public Boundary

SafeGate v6.3 is a public audit viewer mock and direction page. It does not claim a production public API, does not issue real API keys, does not create production merchant accounts, does not expose backend secrets, and does not claim Pi Mainnet settlement proof.

Current evidence remains Pi Testnet controlled post-payment trust flow.