How Private POC Pain Becomes Public-Safe Product Capability

1. Private pain is a signal, not public proof

A private POC may reveal that something is confusing, incomplete, unsafe, nondeterministic, or incorrectly classified. That is valuable research input. It can justify investigation, a backlog item, a design question, or an owner conversation. It does not support a public product claim merely because the observation was compelling, urgent, or witnessed by a trusted team.

The first boundary is therefore a classification boundary: write down the observation as private and provisional. Do not turn a local scan result, screenshot, transcript, count, or narrative into a public success story. The observation may be wrong, too narrow, tied to an unrepeatable setup, or inseparable from private identity. A public capability needs its own support. legacy.baseline.safety-validation.v1 treats safety validation as a guardrail for committed summaries, not authorization to publish private scan artifacts; that is the right posture for the first step too.

2. Abstract the failure class

Remove the repository, organization, application, person, infrastructure, path, object name, record value, configuration, and incident identity. Describe the dangerous general behavior instead. A useful abstraction says what a deterministic tool must not lose or overstate, without preserving a private breadcrumb trail.

• an in-scope source silently disappearing;
• two identities collapsing because their labels match;
• reduced coverage being presented as complete;
• a generated artifact retaining unsafe material; or
• a workflow requiring undocumented tribal knowledge.

These are generic failure categories, not disclosures of actual private events. Redaction alone does not transform private evidence into public proof. A redacted label, a hash, or an aggregate can still be enumerable, correlatable, identity-bearing, or unsupported by a checked-in contract. The abstraction must be reviewed for both meaning and disclosure risk before it becomes a fixture or article claim.

3. Reproduce independently

Build the smallest synthetic fixture that exhibits the abstract failure class. It must be newly designed for the public contract, not a renamed copy of private source. The fixture should make the expected identities, rule IDs, evidence tiers, provenance, spans, coverage, gaps, and deterministic output observable. Counts can be useful, but counts alone do not show whether identity, provenance, or a gap was preserved.

The fixture's test should assert the safe shape: which neutral input was in scope, which rule-backed fact or gap was emitted, which tier and coverage label survived, and whether repeated runs produce the same ordering and artifact identity. legacy.sample-smoke-catalog.safety-validation.v1 validates catalog metadata, redaction, claim floors, and deterministic output; its limitations also make clear that metadata validation does not inspect raw sample repositories or raw scan output.

Keep the tier vocabulary exact: Tier1Semantic is compiler-resolved semantic evidence, Tier2Structural is a known structural pattern, Tier3SyntaxOrTextual is syntax or textual evidence, and Tier4Unknown is an analysis gap. A regression fixture and an owner/reviewer decision are separate records: the first checks behavior deterministically, while the second decides whether the checked-in evidence is safe to describe publicly.

If the failure cannot be reproduced independently, keep it private or research-only. Do not promote the origin story, and do not imply that a public reader can verify a behavior that the public fixture cannot show. The gap guide is the correct destination when the public contract can record uncertainty but cannot resolve it.

4. Turn the failure into a contract

A failure becomes product work only when each promotion step is explicit. The bounded chain is:

1. private observation: record the local signal as provisional research input.
2. abstract failure hypothesis: remove identity and state the dangerous general behavior.
3. synthetic fixture: create an independent neutral reproduction with a known expected outcome.
4. rule/invariant: give the failure a deterministic invariant or versioned rule with documented limitations.
5. implementation: make the product preserve or refuse the behavior the invariant describes.
6. regression: check identities, rule IDs, tiers, provenance, spans, coverage, gaps, and deterministic output on every relevant change.
7. public-safe candidate: assemble only the reviewed summary fields and attach the correct proof path and limitations.
8. bounded claim: state the smallest public sentence that the checked-in evidence supports.

Every arrow requires review and may stop. A fixture without an invariant is a test case, not a durable product contract. An implementation without a regression is a hypothesis, not a stable capability. A public-safe candidate without a proof path is a summary awaiting review, not a public claim. legacy.evidence-pack.claim-boundary.v1 records what an evidence pack may say; it does not upgrade the underlying evidence tier. For the broader hardening pattern, read how a gap becomes a rule and how review pressure becomes reviewable work.

5. Promotion is a separate decision

Do not treat status words as a ladder that private evidence climbs by itself. The repository uses several vocabularies for different contracts:

These terms must stay attached to the contract that defines them. A private or local artifact cannot promote itself. A catalog entry, hash, redacted label, or validator pass alone is not public proof. The legacy.evidence-pack.safety-validation.v1 rule describes a guardrail for redacted artifacts, while docs-export.gap.claim-level-hidden.v1 keeps hidden evidence from being promoted by display names alone. Promotion requires the repository's safety validation, claim-level review, proof path, limitations, and owner decision.

6. What may survive into public evidence

Depending on the reviewed public-safe contract, a summary may retain a neutral synthetic fixture identity, a rule ID or rule family, an evidence tier, a coverage label, a limitation, a safe category or bounded aggregate, a deterministic artifact identity, a public repository path or route, a public proof path, or an owner question. These fields are useful because they let a reader inspect the claim boundary without receiving the private origin story.

None of those fields is always safe. Each remains subject to the governing public-safe contract, its source context, its enumeration risk, and its limitation. public.demo.summary.v1 describes public demo workflow status and artifact references, not scanner facts or runtime, deployment, production, release, vulnerability, or compatibility proof. Follow the proof-source catalog and evidence explorer to keep the surviving fields connected to the route and evidence family that actually supports them.

7. What must remain private

Keep the following outside public copy and public-safe artifacts unless a separate contract explicitly permits a reviewed abstraction:

• private source, source snippets, raw facts, SQLite content, raw logs, and analyzer output;
• local paths and remotes;
• private repository, application, employer, customer, or person identity;
• screenshots or narration from private systems;
• configuration values, endpoint and infrastructure names;
• credentials, connection strings, SQL, and record values;
• hidden validation counts, chronology, and raw review transcripts;
• incident details; and
• private artifact hashes when they create an enumerable or correlatable identity.

A category-only statement can still be too revealing if the category is unique, timed, or easy to correlate. The safe default is omission or a neutral category with a limitation and owner handoff. The docs-export.validation.unsafe-value-rejected.v1 rule names these storage boundaries as validation targets and rejects unsafe values; it does not authorize publishing the rejected material.

8. The public claim stays smaller than the lesson

One completely synthetic example makes the boundary concrete. Imagine a neutral scan fixture in which an expected source is intentionally inaccessible or unsupported while the first draft reports complete coverage. That is a hypothesis about a failure class, not a description of any private repository or incident. The independent fixture must require a typed failure or explicit reduced coverage with a rule-backed gap. Its regression asserts identity, rule ID, evidence tier, provenance, spans, coverage, gap state, and deterministic output—not only a count. The product implementation then preserves that invariant, and the public-safe summary can say only that this synthetic contract keeps the coverage boundary visible under the stated limitation.

The public claim is supported by the checked-in synthetic fixture and contract, not by the private scan that suggested the investigation. The lesson may be broad; the sentence remains bounded. It makes no customer success claim, no claim about a private application, and no disclosure of private behavior. It makes no runtime, production, deployment, migration, compliance, vulnerability, or release-safety conclusion; it does not claim prevalence; and it does not say that public-safe means risk-free or automatically declassified. There is no production claim. docs-export.validation.prohibited-claim-wording.v1 supports this wording boundary, while the limitations page keeps unresolved questions visible.

For adjacent hardening stories, read what a proof path is and the bugs hiding in graph history. A private origin can inspire a public-safe capability, but only the reviewed deterministic evidence path can carry the claim.