ahmido
12ea7f9924
Implemented the output contract and readiness semantics for review packs. Also added spec 348. Includes changes to ChooseEnvironment, CustomerReviewWorkspace, GenerateReviewPackJob and related blade views. Added comprehensive tests. Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #419
111 lines
3.3 KiB
Markdown
111 lines
3.3 KiB
Markdown
# 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
|