The phData-Derived Public Content Redaction Checklist: A Reusable Pre-Flight Gate at the Constraint-Class Level

The question

Draft a reusable confidentiality pre-flight redaction checklist (no client names, no internal tool names, constraint-class only) gating all phData-derived public content - what exactly goes in it? Context: the founder is a phData Deal Solutions Architect (started 2026-05-26, his MAIN bet) who also publishes (Sanity Check, X, FDE lead magnets) and wants to mine phData-derived lessons without leaking confidential material. This operationalizes the established RDCO boundary into a concrete gate; it is the direct deliverable of open-follow-up #4 of [[2026-06-19-phdata-experiment-fde-positioning-proof-point]].

What we already know (from the vault)

• The boundary is artifact-based, and the carve-out cuts both ways. [[feedback_employer_client_content_boundary]]: the line that gets crossed is actual confidential artifacts (real contracts, client data dumps, internal phData strategy/IP docs); what is fine is generic technical knowledge, public facts (a publicly-listed client like Lionsgate; standard vendors like Microsoft Copilot Studio), and anything "from his head." Founder explicitly corrected over-anonymization (2026-06-03). Critical nuance for this checklist: that memory governs what is fine to file in the vault — for published content the bar is higher (see next two bullets). The checklist must not over-redact genuinely public facts, but must still mask client identity and engagement fingerprints in public artifacts.
• The constraint-class rule is already the named gate for the proof-point piece. [[2026-06-19-phdata-experiment-fde-positioning-proof-point]]: the dominant risk is the employer-confidentiality boundary; the write-up "must stay at the methodology/constraint-class level (generic 'hostile corporate perimeter,' not phData's specific blocked-connector inventory, internal tooling names, or any client/engagement detail)," and "strongly consider writing it without naming phData at all." That brief's open-follow-up #4 is this checklist.
• A MASK/KEEP split plus a re-identification test already exists, validated against the web. [[2026-06-12-anonymized-client-case-study-shape]]: MASK = client name, location, niche product descriptors, granular titles, table/column/BRD names, any absolute number that fingerprints; KEEP = industry/sector, size/stage prestige markers, regulatory/operational context, the full methodology, deltas/ratios. Every metric must pass a re-identification test (if a number could only belong to one company, convert to a ratio). The protection is "no published fact is client-specific," not a flimsy "anonymous" label.
• A working grep wordlist + scrub procedure is already in production. [[mac-landing/2026-05-05-build-spec]] has a MANDATORY confidentiality scrub: replace specific client + model names with abstract framing, strip table names (silver_fct_*, gold_opp_pipeline), remove fingerprinting counts (the exact "3,227 rows"), keep illustrative deltas (14 → 95 test count). [[2026-05-21-mammoth-client-field-study-feasibility]] adds the sharpest warning: a persona-class reader can re-identify a thinly-anonymized client in ~60 seconds, so safety must come from methodology-focus, not an identity label.

What the web says

• The default legal posture is "all client info is confidential unless publicly filed or written-approved." Independent-consultant guidance: strip client names, specific financial figures, and proprietary processes; generalize outcomes to methodology; reference only your own role; "describe the type of innovation without specifics" for anything not publicly filed (Business Talent Group, Thomson Reuters).
• NDAs explicitly exclude public-domain info from "confidential." Information already in the public domain through a source other than the parties is not confidential — which is the legal basis for the RDCO public-facts carve-out (phData exists, founder works there, standard vendors are public). The line is non-public specifics, not the engagement's existence (Business Talent Group).
• The MASK/KEEP split is industry-standard and near-identical to RDCO's. MASK: client name/logos, location, niche/proprietary descriptors, individual titles/names, the client's own confidential processes. KEEP: industry category, size markers, quantifiable results/metrics, your own methodology, universal challenges (1827 Marketing, Equinet Media).
• The governing principle is a calibration, not maximal redaction. "Enough context to feel authentic, not enough to identify the client" — credibility comes from the precision of the environment description (regulatory pressure, growth stage, stack constraints), not the brand name (1827 Marketing). This is the web's own anti-over-redaction guardrail and it matches the founder's 2026-06-03 correction.
• For an employee (not just a contractor), the protected set is concrete. Do not disclose proprietary code, unreleased roadmaps, nonpublic financials, customer lists, security credentials, or anything courts classify as trade secrets; you can share titles, high-level responsibilities, and skills you developed (anexpertresume, Olivera Coaching). An employer-views-disclaimer ("opinions are my own") is a standard, cheap trust/cover practice.
• Composites and aggregate language are the escape hatch for strict NDAs — but must be disclosed as composites. "Across recent engagements, X rose ~N% on average" preserves proof while masking identity; honesty requires labeling a composite as a composite (UX Research Blog).

Convergences and contradictions

• Strong convergence: vault and web independently land on the same MASK/KEEP seam and the same re-identification test. RDCO did not invent its discipline; the checklist below is a near-verbatim merge of [[2026-06-12-anonymized-client-case-study-shape]] and the consultant/case-study literature. That agreement is what makes the checklist trustworthy to ship as a standing gate.
• One reconciled tension — vault-filing rule vs publish bar. [[feedback_employer_client_content_boundary]] permits naming a publicly-listed client in the vault; the publish literature says mask the client name in public artifacts. No contradiction: same artifact-line, different surfaces. The checklist applies only to public content and therefore inherits the stricter publish bar — while still refusing to strip facts that are genuinely public (don't pretend phData doesn't exist).
• The anti-over-redaction guardrail is unanimous. Both the founder's correction and the web's "authentic-not-identifying" principle warn that gutting environment detail kills credibility for zero confidentiality gain. The checklist therefore includes a KEEP column and an explicit "did I over-redact?" final check — the gate is calibration, not a scorched-earth scrub.

Synthesis for RDCO

This is a clear, reusable gate. Every phData-derived public artifact (Sanity Check piece, X post/thread, FDE lead magnet, reference/SEO page, deck, conference talk) runs the checklist below before it ships. The checklist is built on one organizing idea borrowed verbatim from the proof-point brief: publish the method and the constraint-class, never the engagement specifics. "A hostile corporate perimeter where every connector is blocked and federated SSO breaks the secrets CLI" is publishable; "phData's [specific blocked-connector inventory / internal repo name / client X's pipeline]" is not. The strongest default is to not name phData or any client at all unless the fact is independently public and naming it adds real value — abstraction to "a locked-down enterprise deployment" carries the full proof with zero exposure.

Calibrate against the RDCO boundary in both directions. The failure mode the founder corrected (2026-06-03) was over-redaction — stripping public facts and hyper-anonymizing generic work. So the checklist redacts confidential artifacts and re-identifying specifics, and deliberately keeps public facts (phData is a Snowflake/data consultancy; the founder works there; standard vendors), generic methodology (eval design, RAG, MAC matrices, the two-layer portability model), and "from-his-head" knowledge. Methodology is the credibility engine and is the founder's to publish; identity and engagement fingerprints are the line.

Two mechanical aids make the gate fast and reliable. (1) A grep blocklist run on every draft, seeded from [[mac-landing/2026-05-05-build-spec]] and extended for the phData era — client names the founder has worked (Lionsgate, Mammoth Growth / MG, Progress, Nutrafol), internal table/model names (silver_fct_*, gold_opp_pipeline, etc.), and phData-internal tool/repo/project codenames as they surface. Maintain this wordlist in the vault so it compounds. (2) The re-identification test on every metric and environment detail: if a number, stack combination, or descriptor could only belong to one company, convert it to a ratio/delta or generalize it. Absolute fingerprinting counts out; illustrative deltas (14 → 95) in.

The gate rule (non-negotiable): every phData-derived public piece runs this full checklist AND routes through the founder for a final read before publish. The checklist does not replace the founder gate — it makes the founder gate fast and consistent. No autonomous publish of phData-derived content, ever. (This mirrors [[feedback_no_autonomous_external_email]]: Ray drafts, founder ships.)

The Pre-Flight Redaction Checklist (run on every phData-derived public draft)

A. Hard blocks — must all be checked before publish:

• No client names. No current or past client named unless that client relationship is independently, verifiably public (e.g., a vendor case study the client itself published) AND naming adds real value. Default: abstract to "an enterprise SaaS client," "a Series B DTC brand."
• No internal phData tool / repo / model / project names. No internal repo names, project codenames, table/column/model names (silver_fct_*, gold_opp_pipeline-class), internal Slack/Notion/Confluence references, or proprietary internal frameworks.
• No engagement-specific deal facts. No real deal sizes, contract terms, named-account pipeline, win/loss specifics, internal margin/comp, or hiring-plan detail tied to a deal or account.
• No confidential artifacts reproduced or quoted. No text from a real contract/SOW/BRD, no client data dump, no internal phData strategy/IP doc, no nonpublic financials, no security credentials/config.
• Constraint described as a CLASS, not a specific engagement. "A hostile corporate perimeter / every connector blocked / federated SSO breaks the secrets CLI" — yes. The specific blocked-connector inventory or environment config of a real engagement — no.
• Every metric passes the re-identification test. Any number that could only belong to one company is converted to a ratio/delta or removed. Illustrative deltas kept; absolute fingerprinting counts cut. Composites disclosed as composites.
• Grep blocklist run clean. Draft greps clean against the maintained wordlist (client names, internal table/model names, internal tool/repo/codenames). No hits.
• No re-identification via stack + stage + detail combination. Even with the name removed, the union of details does not fingerprint one company in ~60 seconds (the persona-reader test).

B. Calibration checks — guard against over-redaction (the founder's correction):

• Public facts NOT stripped. Genuinely public facts kept where useful (phData is a Snowflake/data consultancy; the founder works there; industry-standard vendors). Don't pretend the engagement's existence is secret.
• Methodology kept intact and attributed to RDCO/the founder. The transferable method (two-layer portability model, MAC matrices, eval design, discovery practice) is published in full — it is the credibility engine and it is his to publish.
• Environment precision preserved. Industry, growth stage, regulatory pressure, stack class, and operational context kept — credibility lives here, and removing it buys zero confidentiality.
• "Did I over-redact?" final pass. Re-read for hedging/genericness that adds no protection; restore any detail whose removal only weakens the piece.

C. Surface hygiene:

• Personal-opinion / not-my-employer disclaimer present where the surface warrants it (X bio, post framing, lead-magnet footer).
• Composite framing labeled if metrics are aggregated across engagements.

D. The gate:

• Founder final read + explicit go before publish. Checklist clean is necessary, not sufficient. Ray drafts; the founder ships. No autonomous publish of phData-derived content.

Open follow-ups

1. Maintain the grep blocklist as a living vault artifact. Where does the canonical wordlist live (extend the MAC scrub list), who appends to it as new clients/internal names surface, and should it be wired into a /confidentiality-scrub skill that auto-greps any draft tagged phData-derived?
2. Wire the checklist into the existing verification pattern. Should this become a fresh-eyes critic (a /verify-phdata-content sibling to [[verify-vault-write]] / [[verify-strategic-output]]) so a zero-context subagent runs the gate before the founder sees it, rather than relying on the producer's biased self-scrub?
3. Name-phData policy default — codify it. The proof-point brief leans "don't name phData at all." Should that be the hard default in the checklist (abstract unless an explicit founder override), and does that default differ by surface (X vs lead magnet vs reference page)?
4. Does the cc-wrapped harness IP settlement interact with phData-era content? [[2026-06-12-anonymized-client-case-study-shape]] flagged whether the IP-boundary settlement covers authored content about the harness; confirm it doesn't add a constraint the checklist is missing for phData-deployment write-ups.

Related

• [[2026-06-19-phdata-experiment-fde-positioning-proof-point]] — the parent brief; this checklist is its open-follow-up #4
• [[2026-06-12-anonymized-client-case-study-shape]] — the MASK/KEEP split + re-identification test this checklist merges and generalizes
• [[2026-05-21-mammoth-client-field-study-feasibility]] — the ~60-second re-identification warning; methodology-focus over identity-label
• [[mac-landing/2026-05-05-build-spec]] — the production confidentiality-scrub procedure + grep wordlist seed
• [[2026-06-05-compliant-work-agent-productizable]] — adjacent brief that first attached the confidentiality gate to the locked-down-deployment playbook
• [[feedback_employer_client_content_boundary]] — the artifact-based boundary and the public-facts carve-out the checklist is calibrated to
• [[feedback_no_autonomous_external_email]] — the drafts-vs-ships precedent the founder-gate rule mirrors

Sources

Vault:

• ~/rdco-vault/06-reference/research/2026-06-19-phdata-experiment-fde-positioning-proof-point.md
• ~/rdco-vault/06-reference/research/2026-06-12-anonymized-client-case-study-shape.md
• ~/rdco-vault/06-reference/research/2026-05-21-mammoth-client-field-study-feasibility.md
• ~/rdco-vault/06-reference/research/2026-06-05-compliant-work-agent-productizable.md
• ~/rdco-vault/01-projects/mac-landing/2026-05-05-build-spec.md
• ~/.claude/projects/-Users-ray/memory/feedback_employer_client_content_boundary.md
• ~/.claude/projects/-Users-ray/memory/feedback_no_autonomous_external_email.md

Web:

• Business Talent Group — Independent consultant confidentiality guide: https://resources.businesstalentgroup.com/btg-blog/independent-consultant-confidentiality-guide
• Thomson Reuters — NDAs and confidentiality agreements: https://legal.thomsonreuters.com/en/insights/articles/confidentiality-agreements
• 1827 Marketing — Showcasing success without naming names: https://1827marketing.com/smart-thinking/client-confidential-how-to-showcase-success-without-naming-names/
• Equinet Media — How to write a case study without naming the client: https://www.equinetmedia.com/blog/how-to-write-a-case-study-anonymous-client
• UX Research Blog — Case studies when work is under NDA: https://www.uxresearchblog.com/post/how-to-write-ux-research-case-studies-when-work-is-under-nda
• An Expert Resume — Is your LinkedIn disclosing confidential data: https://www.anexpertresume.com/avoid-sharing-confidential-data-on-linkedin/
• Olivera Coaching — Can my employer dictate what I write on LinkedIn: https://www.oliveracoaching.com/post/can-my-employer-dictate-what-i-write-on-my-linkedin-profile-or-forbid-me-from-being-active-on-linke