# Customer-Safe Output Boundary

Status: prepared  
Created: 2026-06-02  
Scope: Derived customer-safe vs internal-only boundary for review-derived Review Pack output

This document defines what Spec 347 may present as customer-safe, internal-only, or limitations-bearing output.

## 1. Boundary Principles

- customer-safe is a derived presentation boundary, not a new persisted entity
- internal-only is a derived presentation boundary, not a new persisted entity
- PII visibility must be explicit
- redaction visibility must be explicit
- diagnostics and raw/support detail remain secondary or hidden on default customer-safe paths
- non-certification disclosure is mandatory

## 2. Customer-Safe Minimum Conditions

A package may be described as customer-safe only when repo truth supports all of:

1. released review exists
2. current package artifact exists and is valid for download/use
3. evidence basis is not silently incomplete
4. required section limitations are either absent or clearly disclosed
5. no internal-only/raw/support detail is exposed by default
6. PII handling is explicit
7. redaction integrity is explicit
8. non-certification disclosure is present

If any of these are missing or ambiguous, the package must use a more conservative label.

## 3. Internal Package Conditions

A package should be treated as internal or review-required when any of these are true:

- evidence basis is incomplete, stale, or missing
- required sections are incomplete and limitations are material
- `include_pii` is true and external sharing still requires operator review
- export exists but customer-safe readiness is not fully supported by repo truth
- current wording would otherwise overclaim confidence

## 4. PII And Redaction Rules

Current repo truth already provides:

- `options.include_pii`
- `redaction_integrity.protected_values_hidden`

Spec 347 must make these visible in the output contract and/or workspace rendering.

Rules:

- `include_pii=true` must never be invisible on the operator decision path
- `protected_values_hidden=true` must be visible as redaction integrity context where relevant
- PII included does not automatically forbid sharing, but it does require explicit operator awareness

## 5. Disclosure Rules

Customer-safe default paths must show:

- what the package is
- what evidence basis it uses
- whether limitations exist
- whether PII is included
- what the next action is

Customer-safe default paths must not show by default:

- raw JSON
- raw payloads
- stack traces
- support-only diagnostics
- fingerprints unless explicitly needed and safe
- internal reason ownership or platform debug semantics

## 6. Download Boundary

Current signed downloads remain valid proof/artifact delivery.

Spec 347 must not treat download availability alone as sufficient proof of customer-safe readiness.

Download labeling should therefore distinguish between:

- customer-safe ready package
- package with limitations
- internal package

## 7. Executive Summary Boundary

The executive summary must:

- include a limitations note when the package is not clearly customer-safe ready
- retain non-certification disclosure
- avoid raw/internal-only detail

It may describe:

- published review
- evidence basis
- top findings
- accepted risks
- governance decisions
- next actions

It must not imply:

- certification
- legal attestation
- guaranteed compliance