SafeGate v6.6 / Selective Disclosure / Reg-Shield Direction

Make evidence reviewable without exposing everything.

v6.6 defines how SafeGate can show enough evidence for trust and review while limiting unnecessary disclosure of sensitive buyer, merchant, payment, and internal data.

Reg-Shield does not mean hiding evidence. It means showing the right proof to the right role with the smallest safe data surface.

30-Second v6.6 Summary

SafeGate selective disclosure means: public sees proof summary, merchant sees own records, reviewer sees selected audit evidence, operator sees safety events, secrets remain hidden.

1. Why Selective Disclosure Comes After Audit Trail

Selective disclosure only works if there is a clean audit trail underneath it. v6.0 to v6.5 created the direction for audit events, working endpoint behavior, edge cases, timeline viewer, security hardening, and agent-ready verification.

v6.6 adds the visibility layer: who can see what, why they can see it, and what must remain hidden.

2. Disclosure Roles

Public

Public Viewer

Can see bounded proof summaries, public status, high-level event names, and public boundaries.

Merchant

Merchant Viewer

Can see own receipts, own order mapping, access state, merchant evidence, and customer-facing delivery proof where appropriate.

Reviewer

Reviewer / Auditor

Can see selected audit timeline, event results, receipt proof state, and bounded verification evidence.

Operator

Can see operational categories such as rate limits, ambiguous verification, safe internal errors, replay attempts, and incident markers.

Agent

AI Agent

Can receive only agent-safe verification fields: result, state, allowed action, blocked actions, and audit reference.

Admin

Admin / Future Secure Console

Can manage role boundaries and evidence policies, but still should not expose raw secrets or wallet passphrases.

3. Role-Based Visibility Matrix

Field / Evidence	Public	Merchant	Reviewer	Operator	Agent
Receipt verification result	Summary	Own record	Selected proof	Status category	Bounded result
Payment network	Pi Testnet label	Own transaction context	Review context	Operational label	Network label
Buyer private data	No	Only necessary fields	Only selected fields	No by default	No
Merchant private metadata	No	Own metadata	Selected metadata	Operational category	No
Audit timeline	Summary only	Own receipt timeline	Selected review timeline	Operational timeline	Audit reference only
Raw provider payload	No	No	No by default	Restricted future operator-only direction	No
Backend secret / service key	Never	Never	Never	Never in viewer	Never

4. Proposed Disclosure Envelope

{
  "ok": true,
  "mode": "selective_disclosure_direction",
  "viewerRole": "reviewer",
  "receiptId": "SG-RCPT-1781465776152",
  "network": "Pi Testnet",
  "visibleEvidence": {
    "paymentState": "PAYMENT_FINALIZED",
    "receiptProof": "CREATED",
    "accessState": "UNLOCKED",
    "merchantRecord": "FOUND",
    "auditTimeline": [
      {
        "event": "PAYMENT_FINALIZED",
        "time": "mock_timestamp",
        "result": "OK"
      },
      {
        "event": "RECEIPT_PROOF_CREATED",
        "time": "mock_timestamp",
        "result": "OK"
      },
      {
        "event": "ACCESS_UNLOCKED",
        "time": "mock_timestamp",
        "result": "OK"
      }
    ]
  },
  "hiddenByPolicy": [
    "backend_secret",
    "service_role_key",
    "wallet_passphrase",
    "raw_provider_payload",
    "private_user_data",
    "unnecessary_merchant_metadata"
  ],
  "disclosureBoundary": {
    "publicSummaryOnly": false,
    "reviewerSelectedEvidence": true,
    "rawSecretExposure": false,
    "piMainnetSettlementClaim": false
  }
}

5. Reg-Shield Direction

Reg-Shield is a product direction, not a legal compliance certification. It means SafeGate should be designed to support selective review, controlled disclosure, and auditability.

The goal is to avoid two extremes:

Showing too little, so no one can verify anything.
Showing too much, so privacy, security, and merchant confidentiality are damaged.

6. Disclosure Policy Rules

Need-to-Know Evidence

Each role sees only the evidence needed for its purpose.

Public-Safe Proof

Public pages show high-level proof, not private user data or internal logs.

Merchant Isolation

Merchants see their own records only. Other merchant evidence remains hidden.

Reviewer Selection

Reviewers get selected evidence fields and audit timeline, not full internal system state.

Agent-Minimal Response

AI agents get bounded verification results, not private records or override authority.

No Secret Viewer

No role-based viewer should display service keys, wallet passphrases, backend tokens, or raw secret material.

7. Future Cryptographic Direction

Hash-Based Evidence Summary

Future evidence summaries can include hashes over selected event fields to support tamper-evident review.

Signed Receipt Proof

Future receipt proof can be signed by a backend-controlled proof key without exposing the signing secret.

View-Key Direction

Future reviewer access can be scoped by temporary view permissions instead of public full disclosure.

ZK / Selective Proof Direction

Future advanced versions may prove selected facts without revealing unnecessary underlying data.

8. What v6.6 Does Not Claim

v6.6 does not claim legal compliance certification, production selective disclosure, ZK implementation, or regulator approval.

It defines the direction for auditable privacy: enough evidence to review, limited enough to protect sensitive data.

9. V6 Progression

v6.6 Selective Disclosure

Current stage: auditable privacy and role-based evidence visibility.

10. Public Boundary

SafeGate v6.6 is a public direction page. It does not claim production selective disclosure, legal compliance certification, regulator approval, ZK implementation, production public API, real API key issuance, production merchant accounts, backend secret exposure, or Pi Mainnet settlement proof.

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