diff --git a/WORK-RECORDS.md b/WORK-RECORDS.md
index e731973..768bba1 100644
--- a/WORK-RECORDS.md
+++ b/WORK-RECORDS.md
@@ -457,4 +457,3 @@
 | intake | CUST-IN-0013 | closed | blue | intakes.md |
 | intake | CUST-IN-0014 | closed | blue | intakes.md |
 | intake | CUST-IN-0015 | open | blue | intakes.md |
-| intake | CUST-IN-0016 | open | green | intakes.md |
diff --git a/workplans/CUST-WP-0070-publication-repo-category.md b/workplans/CUST-WP-0070-publication-repo-category.md
deleted file mode 100644
index 6b54a6c..0000000
--- a/workplans/CUST-WP-0070-publication-repo-category.md
+++ /dev/null
@@ -1,126 +0,0 @@
----
-id: CUST-WP-0070
-type: workplan
-title: "Add the publication category to the Repo Classification Standard"
-domain: infotech
-repo: the-custodian
-status: active
-owner: claude-code
-topic_slug: custodian
-priority: medium
-created: "2026-09-05"
-updated: "2026-09-05"
-quality_dor: DoR-Ok
-quality_dor_at: "2026-09-05"
-quality_dor_by: claude-code
-quality_dor_note: "Classifying hall-of-helix exposed a real gap: a published corpus of authored records fits none of the six categories, and the fallback (project) is the only non-durable one, implying eventual retirement of a permanent record. The change is additive and no existing classification becomes invalid, so the enforcement points are known and bounded."
-related:
-  - HOH-WP-0001
----
-
-# Add the publication category to the Repo Classification Standard
-
-Classifying `hall-of-helix` had no honest answer. It is a curated, permanent
-corpus of authored first-person records — a record of who engaged on the Helix
-Forge platform. None of the six categories fit:
-
-- `research` is knowledge work answering "what do we need to understand?";
-- `tooling`, `product`, `business`, `experimental` are plainly not it;
-- `project` is the only **non-durable** category (`DURABLE_FLAVORS` in
-  `repo-manager/standards.py` contains the other five), reserved for bounded
-  work "not yet productized" that later resolves or retires. A hall of
-  remembrance does not retire.
-
-Today `hall-of-helix` has no classification file at all, so `resolve_flavor`
-falls through to `flavor = "tooling"` — misclassified, and silently.
-
-`publication` fills the gap as a **durable** flavor: repos whose purpose is to
-publish and keep a body of authored content for readers, where the corpus itself
-is the deliverable.
-
-**Population is currently one.** A scan of all 131 registered repos found no
-other true publication — `info-tech-canon` and `shard-wiki` are services that
-handle documents rather than published corpora. That is an argument for adding
-the category once and carefully, not for skipping it: the alternative is
-misfiling a permanent record as transient project work.
-
-**Version: 1.1, not 2.0.** §17 currently reads "changed allowed values" as a
-major bump. This addition is purely additive — no existing classification
-becomes invalid, and neither validator enforces a version match, so the 125
-repo files declaring `version: '1.0'` keep validating. T01 clarifies §17 to
-distinguish adding a permitted value (minor) from renaming or removing one
-(major), rather than leaving the rule silently contradicted.
-
-## Amend the standard and its machine-readable vocabulary
-
-```task
-id: CUST-WP-0070-T01
-status: todo
-priority: high
-```
-
-In `canon/standards/repo-classification-standard_v1.0.md`:
-
-- add `### 5.7 publication` following the shape of the existing entries — main
-  question, typical signs, examples — and the disambiguation against `research`
-  and `product`;
-- add `publication` to the §5 allowed-values block and to §3's field overview
-  where categories are listed;
-- clarify §17 so that adding a permitted value is a minor bump;
-- bump `version` in the frontmatter and the §17 current-version block to `1.1`.
-
-Keep the filename at `_v1.0.md` unless the canon's own convention says
-otherwise; check how previous minor bumps were handled before renaming.
-
-In `canon/standards/repo-classification.allowed.yaml`:
-
-- add `publication` to `categories`;
-- add `history` and `participation` to the `knowledge_and_evidence` capability
-  family, so hall-of-helix's tags do not warn as unrecognised;
-- bump `version` to `1.1`.
-
-## Teach repo-manager the new category
-
-```task
-id: CUST-WP-0070-T02
-status: todo
-priority: high
-```
-
-Three hardcoded lists in `~/repo-manager`, plus tests:
-
-- `src/repo_manager/classification.py` — `CATEGORIES` frozenset;
-- `src/repo_manager/standards.py` — add to `DURABLE_FLAVORS` (it is durable, so
-  `CATEGORIES` picks it up automatically);
-- `src/repo_manager/cli.py` — `--category` choices.
-
-Run the repo-manager test suite. Track under a companion `RMGR-WP` if the change
-turns out to be more than a vocabulary addition.
-
-## Classify hall-of-helix
-
-```task
-id: CUST-WP-0070-T03
-status: todo
-priority: medium
-```
-
-Write `hall-of-helix/.repo-classification.yaml`:
-
-```yaml
-category: publication
-domain: infotech
-secondary_domains: [agents]
-capability_tags: [knowledge, documentation, history, participation]
-business_stake: [technology, people]
-business_mechanics: [coordination, intention]
-```
-
-`participation` is the hall's own word — "we remember participation, not rank" —
-and avoids the compensation framing that "credits" would import. `people` in
-`business_stake` is deliberate and rare in the fleet: the hall exists to
-acknowledge participants, and classifying it as purely `technology` would
-describe the filesystem rather than the purpose.
-
-Clears C-24 and C-35 on that repo. Verify with the canon linter
-(`tools/validate_repo_classification.py`) and `statehub fix-consistency`.