Phase 177FAEDA-EVIDENCE-DATA-CONTRACT-DESIGN-001provider boundary design only

Evidence Storage Provider Boundary Design

A provider-boundary design gate for storage aliases, encryption controls, signed-view policy, retention limits, backup rules, and forbidden data blocks before any real evidence storage is implemented.

Data contract Permission gate Control Upload approval

Provider tiers

4

logical options only

Boundary layers

7

alias to audit

Signed-view rules

9

no public URLs

Runtime storage

0

no bucket or upload

Provider alias layer

Stores only logical aliases such as faeda_evidence_private, not provider names, secrets, keys, or URLs.

Allows future provider migration without changing evidence metadata truth.

Container boundary layer

Separates original, redacted, quarantine, backup, and deleted-pending-retention evidence containers.

Prevents restricted evidence from mixing with demo-safe proof.

Object key policy

Defines future object key shape using tenant, role, route, evidence ID, version, and privacy class references.

No public filenames, user names, CNIC, phone numbers, or private business names in object keys.

Encryption policy

Requires encryption at rest, envelope-key reference, rotation marker, and no raw key material in app or database.

Keys stay in a future KMS/vault boundary, never in frontend or source code.

Signed-view policy

Future evidence viewing must be short-lived, actor-scoped, reason-coded, watermark-ready, and auditable.

No direct public object URLs or reusable download links.

Retention policy

Defines retention duration, legal hold, deletion review date, restoration window, and audit-preserved tombstone.

Deletion is governed, not silent.

Incident and quarantine policy

Forbidden evidence or suspected leakage moves to quarantine/incident state before any view/export action.

Security review comes before convenience.

Provider candidate tiers

Logical choices, not integrations

Local encrypted private storage

future option

Pilot or low-volume evidence with strict local control.

Must still use private paths, encryption, backups, audit trail, and no public serving.

No storing evidence inside app source, public folder, repo, or browser storage.

S3-compatible object storage

future option

Scalable private object storage through a provider abstraction.

Provider credentials stay in vault/env; app stores only logical references.

No hardcoded bucket names, access keys, public bucket policies, or raw signed URLs in database.

Pakistan-region data residency store

future option

Sensitive local governance evidence where residency matters.

Must support encryption, access logs, retention, and contractual data protection review.

No cross-border evidence movement without governance approval.

Quarantine vault

required design

Forbidden or suspected sensitive evidence that must not be viewed broadly.

Security-only access, incident reason, maker-checker restore/delete workflow.

No founder demo, public export, generic QA view, or direct download.

Provider decision matrix

How storage choice must be governed

Data residency

Low risk: generic UI proof
High risk: customer/payment/founder evidence
Prefer local or residency-approved provider for high risk.

Privacy class

Low risk: public-safe
High risk: restricted/forbidden
Restricted routes to private or quarantine containers only.

View frequency

Low risk: rare audit review
High risk: frequent QA correction
Use signed-view policy for all views; never make public.

Retention need

Low risk: short QA correction
High risk: audit/legal dispute
Attach retention reason and review date before storage.

Export need

Low risk: internal note
High risk: auditor/investor/legal packet
Export requires redaction check and maker-checker.

Incident risk

Low risk: no sensitive content
High risk: secret or personal data found
Quarantine first, classify second, delete/retain under incident protocol.

Encryption boundary

Keys stay outside app truth

1

Encryption at rest must be mandatory for every future evidence object.

2

Encryption in transit must be mandatory for upload, view, export, restore, and delete flows.

3

Raw encryption keys must never be stored in frontend code, source files, database rows, logs, JSON previews, or screenshots.

4

Future KMS or vault references may be stored as aliases only, never as key material.

5

Restricted evidence must support stronger key policy than public-safe evidence.

6

Key rotation must not break evidence audit trails or metadata references.

7

Any decryption/view action must create audit evidence later.

Signed-view policy

Private viewing, never public URLs

1

Signed view links must be short-lived.

2

Signed view links must be actor-scoped.

3

Signed view links must be purpose/reason coded.

4

Signed view links must not be stored as permanent database truth.

5

Signed view links must not be copied into audit notes, emails, screenshots, or JSON previews.

6

Restricted evidence view should require maker-checker or security reviewer approval.

7

Watermark metadata should include viewer, timestamp, evidence ID, and privacy class later.

8

Downloads should be disabled by default unless export gate approves.

9

Every view should be logged as audit evidence later.

Retention controls

Lifecycle before files exist

Default retention

Set a default review period by privacy class; never retain forever by default.

Legal hold

Legal/dispute evidence can pause deletion but must show reason, owner, and review date.

Deletion tombstone

Deletion should preserve metadata tombstone and audit trail without retaining private file content unnecessarily.

Restore window

Restore requires incident or governance approval, not normal QA access.

Backup policy

Backups must follow encryption, residency, retention, and deletion propagation rules.

Export expiry

Export packets must have expiry/revocation strategy where practical.

Forbidden data blocks

What must not enter storage

CNIC or national identity

hard block

Personal identity must not enter QA evidence storage without a legal/privacy gate.

Wallet PIN, OTP, password, recovery code

hard block

Authentication secrets are never evidence.

Bank/account/card detail

quarantine

Finance proof must use partner-safe references, not screenshots of secrets.

Provider access key or token

hard block

Provider secrets must never be uploaded, logged, or previewed.

Raw customer support transcript

redact or block

Support content can include private customer data.

Internal cost/profit/ledger rows

restricted hold

Financial truth needs role scope and audit approval.

Device notifications or personal browser data

crop or block

Mobile QA should not leak personal device state.

Boundary workflow

Provider decision flow

01

Classify evidence contract

Read Phase 176 privacy class, storage lane, decision state, and redaction marker before choosing any provider path.

Provider selection follows contract truth.

02

Select logical provider alias

Assign a future provider alias and container class without naming secrets, public URLs, or implementation credentials.

Evidence remains portable and private.

03

Apply encryption and residency policy

Attach key alias, residency class, backup class, and rotation expectation before storage implementation is approved.

Security is designed before files exist.

04

Attach signed-view and export policy

Define who may view, for what reason, for how long, with watermarking and download restrictions.

No permanent public links.

05

Apply retention and incident policy

Set retention review, deletion tombstone, restore gate, quarantine rules, and forbidden data action.

Evidence lifecycle is governed end to end.

Hard rules

Provider boundary is not storage

1

Phase 177 is a provider boundary design gate only.

2

Do not create buckets, folders, local file storage, upload APIs, download APIs, signed URL APIs, migrations, database tables, queues, workers, or provider SDK integrations here.

3

Do not add provider credentials, bucket names, access keys, endpoints, signed URLs, private paths, or sample secrets to code.

4

Do not use public folders, app source folders, browser local storage, or logs as evidence storage.

5

Future implementation must pass security, privacy, retention, and maker-checker review before any real file can be stored.

Boundary packet

JSON preview

{
  "boundaryId": "evidence_storage_provider_boundary_design_177",
  "phase": "Phase 177",
  "route": "/business-pro/evidence-storage-provider-boundary-design",
  "sourceContract": "evidence_data_contract_design_176",
  "sourceGate": "FAEDA-EVIDENCE-DATA-CONTRACT-DESIGN-001",
  "designOnly": true,
  "createsProviderIntegration": false,
  "createsBucket": false,
  "createsUploadApi": false,
  "createsSignedUrlApi": false,
  "createsDatabase": false,
  "storageReferenceFields": [
    "storageProviderKey",
    "bucketOrContainerRef",
    "objectKeyRef",
    "redactedObjectKeyRef",
    "checksumSha256",
    "mimeType",
    "byteSize",
    "dimensions",
    "signedViewPolicyRef"
  ],
  "decisionStates": [
    "draft_review",
    "needs_redaction",
    "restricted_hold",
    "approved_internal",
    "approved_demo_safe",
    "rejected",
    "deleted_pending_retention",
    "restored_after_incident"
  ],
  "redactionMarkers": [
    "none",
    "crop",
    "blur",
    "mask_text",
    "remove_metadata",
    "replace_reference",
    "hard_block"
  ],
  "providerAliases": [
    "Local encrypted private storage",
    "S3-compatible object storage",
    "Pakistan-region data residency store",
    "Quarantine vault"
  ],
  "boundaryLayers": [
    "provider-alias",
    "container-boundary",
    "object-key-policy",
    "encryption-policy",
    "signed-view-policy",
    "retention-policy",
    "incident-quarantine"
  ],
  "signedViewRuleCount": 9,
  "forbiddenBlockCount": 7,
  "nextAllowedGate": "phase_178_evidence_upload_flow_approval_design"
}

Next build gate

Phase 178 is evidence upload flow approval design

After provider boundaries are accepted, the next safe move is designing upload approval steps without writing upload APIs.

Open upload approval