LLM Wiki Public Private Routing

llm-wiki public/private routing

The firewall between client-attributed and abstracted content. Routes converted wiki pages to the correct repository surface and enforces the project-name abstraction rule with its public-availability exception.

This skill is invoked by llm-wiki-page-shape-contract Rule 8 before any public-wiki commit. It is NOT optional — every page bound for public llm-wiki clears this gate first.

The two surfaces

Both surfaces follow the same page-shape contract (Skill A). They differ only in routing rules.

The routing rule (verbatim from 2026-05-20 user directive)

"Exact client results will go into llm-wiki-<client> private repo; project name, client name abstracted results will go into llm-wiki public repo."

"Only client project names are to be abstracted. If project name is available public, can be used in the llm-wiki public repo provided all key data is publicly available."

Decoded routing matrix

The abstraction surface (public-bound content)

By default, abstract client project names in public-wiki content.

Examples:

• B1528 proj-a → Project Alpha (or a deepwater FSO project)
• mkt-a/<specific project> → a marine engineering project
• specific platform name → generic platform-class descriptor

What is NOT in the abstraction surface

• Industry-standard names (DNV-OS-E301, API RP 2SK, OCIMF MEG, ISO 19901): never abstracted
• Standard editions / revisions: never abstracted (defensibility requires explicit edition)
• Public operators in public roles (e.g., regulatory filing data — operator named in the filing): not abstracted per the exception below
• Generic methodology: no abstraction needed (no client tie)
• Open-source code / library references: not abstracted

What IS in the abstraction surface

• Client project names (engineering project identifiers, internal codenames)
• Project-specific numerical results (only the specific values, not the methodology)
• Project-specific dimensions / configurations when they would identify the asset

Client identity (the operator company) is governed by .legal-deny-list.yaml and .claude/rules/legal-compliance.md — this skill does not relax those rules.

The public-availability exception

A project name can be used as-is in public llm-wiki when both of the following hold:

1. Project name is in the public domain, evidenced by at least one of:

   • SEC filing (10-K, 10-Q, 8-K, S-1) naming the project
   • Operator press release naming the project
   • Conference paper (OTC, SPE, OMAE, ISOPE) naming the project
   • Regulator record (BSEE, BOEM, NOPSEMA, PSA, NSTA) naming the project
   • Public reservoir / pipeline database entry (e.g., BSEE production records)
   • Project's own public-facing website

2. All key data being cited is also publicly available, evidenced by:

   • The data appears in the same public source as the project name, OR
   • The data appears in a separate public source (conference paper, regulator filing) that can be cited alongside
   • "Key data" means: any numerical result, dimensional spec, or operational parameter the wiki page presents as derived from the project

Both conditions, or the project name gets abstracted. Name-only public availability without data backing fails the exception. Data-only without project-name backing has nothing to exception away — abstract the name as usual.

Worked examples of the exception

Pre-promotion decision tree

For each page bound for public llm-wiki:

page bound for public llm-wiki
  │
  ├── Page references a client project name?
  │     │
  │     ├── NO ──────────────────────────────► commit to public (no abstraction needed)
  │     │
  │     └── YES
  │           │
  │           ├── Is the project name publicly available?
  │           │     (SEC / press release / conference paper / regulator filing / public DB)
  │           │     │
  │           │     ├── NO ──────────────────► ABSTRACT project name → commit
  │           │     │
  │           │     └── YES
  │           │           │
  │           │           ├── Is ALL key data also publicly available?
  │           │           │     │
  │           │           │     ├── NO ──────► ABSTRACT project name → commit
  │           │           │     │
  │           │           │     └── YES ─────► EXCEPTION APPLIES → use actual name, cite public source(s)
  │
  └── Page also references client identity (operator, contractor)?
        │
        ├── Refer to `.legal-deny-list.yaml` and `.claude/rules/legal-compliance.md`
        └── Not governed by this skill

When in doubt: abstract. The exception is opt-in with evidence, not opt-out.

Pre-promotion checklist (public-bound page)

• Page references a client project name? (yes / no)
• If yes: is project name in public domain? (cite sources, otherwise abstract)
• If public domain: is all key data publicly available? (cite sources, otherwise abstract)
• If exception applies: public sources cited explicitly in the page's ## Sources section
• No raw numerical results that would identify a specific asset (sanitize to ranges or remove)
• No filenames / paths referencing client-private directories (mkt-a/, <client>-projects/)
• Client identity (operator company) check passes .legal-deny-list.yaml
• bash scripts/legal/legal-sanity-scan.sh --diff-only returns PASS
• Page's commit message records abstraction verdict: abstraction: applied | not-needed-exception-met | not-applicable-public-standard-only

Promotion from private to public

If a private-wiki page should also exist in public form:

1. Copy, don't move — the private page stays as the canonical client-attributed record
2. Create a new public page (different slug, abstracted content)
3. Run the full pre-promotion checklist
4. Cross-link: private page can wikilink to its public counterpart for "see also the abstracted version"; public page MUST NOT link back to the private page (the private repo is invisible to public readers)
5. Commit message on the public-wiki side: abstraction: applied; source private llm-wiki-<client> page-id <id> — the source reference stays in the commit message only, never in page body

Anti-pattern: replace-with-abstraction

Do NOT delete the private page after promoting an abstracted copy. The private page is the audit-trail; the public copy is the share-out.

Anti-patterns

• Name-substitution without data-substitution — replacing "B1528 proj-a" with "Project Alpha" while keeping a specific tension envelope from B1528. The number identifies the asset.
• "Public domain" by hand-wave — "I think it's been mentioned somewhere" doesn't qualify. Cite the source.
• Per-page abstraction without checklist — judgment calls drift across pages. Use the decision tree.
• Abstracted page in private wiki — abstraction has no purpose in the private surface; just write the actual name. (Private→public copies are the exception.)
• Exact-name page in public wiki without exception verification — the abstraction gate must clear; either abstract or document the exception.
• Promotion via git mv — never. Copy the file with a new slug to public; private original stays.
• Self-approving the exception — when the exception is borderline, route through audit per Skill B and defer to user.

Hand-off back to research/llm-wiki-page-shape-contract

Once routing is decided and the abstraction gate cleared:

# Public commit:
git -C /mnt/local-analysis/llm-wiki commit -m "wiki(<domain>): <slug> — <one-line>

abstraction: applied | not-needed-exception-met | not-applicable-public-standard-only

Refs: <upstream issue>
" -- wikis/<domain>/<page>.md wikis/<domain>/index.md wikis/<domain>/log/YYYYMMDD.md

# Private commit (per-client repo):
git -C /mnt/local-analysis/llm-wiki-<client> commit -m "wiki: <slug> — <one-line>

source: <upstream issue> | <upstream artifact path>
" -- wikis/<domain>/<page>.md wikis/<domain>/index.md wikis/<domain>/log/YYYYMMDD.md

Pathspec form per feedback_multi_agent_commit_serialization.

What this skill is NOT

• Not a replacement for .legal-deny-list.yaml — that enforces client identity rules; this skill adds the project-name layer above
• Not a replacement for coordination/client-llm-wiki-factory — that skill creates the private-wiki repo infrastructure; this skill governs routing decisions within the infrastructure
• Not a replacement for the data-layer boundary (#2727) — that defines what content is wiki-eligible at all; this skill decides which wiki
• Not for .gitignore / .git firewall mechanics — those are repo configuration, governed by feedback_per_repo_metadata_is_firewall

Related must-fire rules

• feedback_service_provider_data_routing — 6-row matrix; vendor brochures → off-repo; SEC / conference / regulator → public
• feedback_per_repo_metadata_is_firewall — license + .gitignore + per-repo .claude + .git are the file-system firewall
• feedback_credential_issuer_copy_paste_leak — never commit raw "save this token" output; same hygiene applies to client identifiers
• feedback_external_permission_email_hygiene — when a rights-holder approval email is supplied, record the minimum permission/citation conclusion needed for traceability; do not persist personal contact details, and do not inflate “citation looks appropriate” into unlimited bulk-copy permission
• feedback_never_offer_to_self_label_plan_approved — borderline exception cases route through user, not self-approval
• feedback_offrepo_intel_routing — for published repos, side-channel notes go to /mnt/ace/<repo-name>/docs/, not in-repo