WP6 INV-2 — Content-Type Semantics Archaeology

WP6 INV-2 — Content-Type Semantics Archaeology

Date: 14/05/2026 · Wave: S236 WP6 INV-2 (Investigator) · Author: INV-2 sub-agent Branch: content-items-investigation · Scope: CV 04 content_type semantic-overlap pairs Pairs investigated: policy vs compliance; methodology vs capability

---

1. Executive Summary

No authoritative spec defines the content_type semantic boundary for either pair. Search across docs/specs/, docs/reference/, docs/ontology/, docs/plans/, .planning/.archive/.specs/, .planning/.archive/.audits/ and .planning/.archive/.research/ returned zero hits for content-type definitional prose. Mempalace search returned the same null result.

The closest related artefact is docs/reference/classification-prompt.md v4.7 (validated 06/04/2026), which provides DOMAIN-classification disambiguation rules (e.g. “Methodology/Quality vs Compliance/Audit” §6g) and a content_type SIGNAL guide that maps each value to a domain hint. This is adjacent to the question but does not define what makes a content_items row a policy vs a compliance artefact at the structural level.

The B1 verifier already documented this gap (Escalation §6) and Liam’s “identify where this landed” invitation appears to assume work that did not in fact land. Recommended C1 action: add a Notes block to 04-content-type.md recording that the boundary is Liam-decision-pending; do not invent a rule.

---

2. Search Log

Tool	Query	Result
grep -rln docs/reference/	policy|compliance|methodology|capability	32 hits — only classification-prompt.md, classification-architecture.md, SCHEMA-QUICK-REFERENCE.md material
grep -rln docs/specs/ .planning/.archive/	content_type mentions in classification context	20 hits — all about the enumeration (15 values), not boundaries
grep -rln docs/ .planning/	policy.*vs.*compliance|methodology.*vs.*capability	0 hits
grep -rln docs/ .planning/	definition.*content_type|content_type.*semantic	6 hits — none define semantics; mostly Phase-0 ontology pipeline + INV-2 prompts
find docs/ -name "*classification*" -o -name "*content-type*"	classification + content-type files	6 results — already covered above
mempalace_search	content_type policy compliance methodology capability semantic boundary disambiguation	30 candidates → 0 boundary definitions; 1 KB-appropriate types table (one-line gloss per value, not authoritative)
mempalace_search	policy compliance content_type boundary distinction definition KB-appropriate	15 candidates → same null result
git log --all --grep	content.type|content_type|OQR1-12|CV 04	10+ commits — all enum-list / scaffolding / Zod-harness work; none on semantics
mcp__supabase__execute_sql	SELECT content_type, COUNT(*) … WHERE content_type IN (4 values)	17 compliance, 7 methodology, 19 policy, 0 capability

---

3. Authoritative Source(s) Located

No source defines content_type boundaries. The two adjacent artefacts that exist:

3.1 docs/reference/classification-prompt.md v4.7 (last validated 06/04/2026)

This is the Python pipeline’s classification system prompt. It provides a “CONTENT TYPE SIGNAL GUIDE” that maps content_type values to domain hints (not content-type definitions). Verbatim extract (§“CONTENT TYPE SIGNAL GUIDE”, lines 330-349):

content_type	Platform	Signal
q_a_pair	extraction	Bid library import — classify on question text + answer content
policy	upload	Formal policy document — likely SECURITY or COMPLIANCE
case_study	any	Typically CORPORATE/references unless the question explicitly asks about domain practices
certification	upload	COMPLIANCE/certification or SECURITY/iso-27001
capability	any	PRODUCT-FEATURE or METHODOLOGY
product_description	any	PRODUCT-FEATURE
article	web	General knowledge — classify on content substance
note	manual	Internal note — classify on content substance
methodology	any	METHODOLOGY (but verify — the content_type is a hint, not a rule)
document	upload	General document (Word, uploaded files) — classify on content substance

Important: content_type is a signal, not a deterministic rule. A document labelled policy might actually describe a methodology. Always classify on substance.

Note that compliance is absent from this signal table, and the prose explicitly says the values are signals, not definitions. This is the Python pipeline’s view of what the values mean operationally — the closest thing to “how does the system already use them?” — but it is one-way mapping (content_type → domain hint), not a structural definition (what kind of artefact is a compliance content_item?).

3.2 docs/reference/classification-prompt.md v4.7 §6g — DOMAIN-level disambiguation

The same prompt also disambiguates the DOMAIN boundary between methodology and compliance (lines 475-488):

6g. Methodology/Quality vs Compliance/Audit

• Quality management in project delivery (testing strategy, defect management, acceptance criteria, continuous improvement) → METHODOLOGY/quality
• Formal audit and compliance assurance (audit trails, evidence gathering, compliance monitoring, third-party audits) → COMPLIANCE/audit

This is a domain rule, not a content_type rule. It tells the classifier how to choose domain=METHODOLOGY vs domain=COMPLIANCE when the subject matter is ambiguous. It does not say what makes the artefact (the content_items row) a content_type='methodology' vs content_type='compliance'.

3.3 docs/ontology/04-content-type.md (current) — explicitly flags the gap

The CV 04 markdown that drafter A1 produced already records the gap (lines 65-67, 105-107):

policy vs compliance — distinction is currently implicit; needs definitional clarification per source §2.1 “what’s missing”. …

• Definitional gaps exist: policy vs compliance, methodology vs capability overlap rules are tribal per source §2.1.
• Source policy and compliance may both apply to a regulation document — the editor sub-agent should propose disambiguation rules.

3.4 docs/plans/phase-0-investigation/phase-b-prerequisite-1-onthology-pipeline.md line 77

Phase-B prerequisite 1 explicitly identifies this as one of the missing CV artefacts, verbatim:

No definitions per term. content_type='policy' vs 'compliance' — what’s the distinction? lifecycle_type='regulation' vs 'date_bound' — overlap rules? These distinctions live implicitly in code and tribal knowledge, not in a definition register.

This phrasing — “tribal knowledge, not in a definition register” — matches the B1 verifier’s wording exactly and confirms the boundary was never documented.

3.5 docs/specs/wp6-ontology-harness/verifier-reports/B1-md-vs-db-drift.md §4 row 2 + Escalation §6 item 6

The B1 verifier (current S236 wave) reached the same conclusion (lines 125, 150):

Prod-data evidence: policy 19 rows vs compliance 17 rows (live ambiguity confirmed); methodology 7 rows vs capability 0 rows. No semantic disambiguation rule found in code or specs. Recommend C1 escalate to Liam (§5) — needs a definitional ruling.

CV 04 content-type — policy/compliance and methodology/capability semantic boundaries undocumented. Both pairs have prod-data evidence of co-existence. Liam needs to either (a) define the boundary, (b) accept ambiguity and note “either is valid”, or (c) consolidate (e.g. drop compliance, fold into policy). Tribal knowledge is not survivable past v1.

This confirms there is no work to find — the question is genuinely open.

---

4. Semantic-Boundary Resolution per Pair

4.1 policy vs compliance

NO RESOLUTION FOUND.

What the system implicitly suggests (synthesised across the adjacent artefacts above; NOT a ratified definition):

• policy — the organisation’s own statement of intent / rule / position (e.g. “Information Security Policy”, “Equal Opportunity Policy”). The artefact is authored by the org and prescribes behaviour. Classification prompt v4.7 says policy documents are likely SECURITY or COMPLIANCE domain.
• compliance — evidence of adherence to external requirements (e.g. audit reports, regulatory filings, compliance attestations, RoPA records). The artefact responds to or evidences an external regime. Classification prompt §6g treats compliance as the audit/evidence-gathering side at the domain level.

Live tension: any policy document could legitimately be classified policy (because Phew authored it) OR compliance (because it exists to satisfy a regulatory regime). Prod data confirms — 19 policy and 17 compliance rows co-exist with similar counts.

Recommendation for C1: mark this as Liam-decision-pending in §Notes; do not invent a rule. The plausible options Liam should pick from:

1. Author-vs-evidence rule — policy = the org’s prescriptive statement; compliance = evidence/attestation/filing showing adherence.
2. Accept ambiguity — note “either valid; classifier picks based on primary purpose; no migration of existing rows”.
3. Consolidate — drop compliance, fold all 17 rows into policy (or vice versa). Reduces the enum to 14 values. Schema migration required.

4.2 methodology vs capability

NO RESOLUTION FOUND.

What the system implicitly suggests (synthesised; NOT ratified):

• methodology — how we work (delivery approach, framework usage, process prescription — Agile, PRINCE2, Lean). The classification-prompt §6b distinguishes “Implementation vs Methodology” with the key signal “How do you work? = METHODOLOGY”.
• capability — what we can do (a skill/competency the org offers — penetration testing capability, accessibility-audit capability). Classification-prompt v4.7 maps capability → PRODUCT-FEATURE or METHODOLOGY domain (overlap is admitted in the prompt itself).

Live tension: the boundary between “what we can do” and “how we do it” is slippery — a “capability” statement typically describes both (the skill + the method used to deliver it). Prod data: methodology 7 rows; capability 0 rows. The capability content_type is currently aspirational.

Recommendation for C1: mark this as Liam-decision-pending in §Notes; flag the 0-row count as evidence the value may be safe to retire. Plausible options:

1. Skill-vs-process rule — capability = a competency offered to clients (output-facing); methodology = the org’s delivery approach (process-facing).
2. Retire capability — 0 prod rows; can be removed in v1 schema migration with no data loss. Reduces enum to 14 values; classification prompt’s capability → PRODUCT-FEATURE/METHODOLOGY line drops out cleanly.
3. Accept ambiguity — keep both, note “either valid; substantive content determines classification”.

---

5. Prod-Data Evidence

Live query (project rovrymhhffssilaftdwd, prod):

SELECT content_type, COUNT(*) AS n
FROM content_items
WHERE content_type IN ('policy','compliance','methodology','capability')
GROUP BY content_type ORDER BY content_type;

content_type	rows
compliance	17
methodology	7
policy	19
capability	0

Assessment:

• policy (19) and compliance (17) — close-enough counts to confirm both values are in active editorial use. The classifier (or human author) is routinely making the choice both ways; without a documented rule that choice is statistically near-random for ambiguous artefacts. The ambiguity is live, not theoretical.
• methodology (7) — moderate use; signals editors do reach for it. The classification-prompt v4.7 admits it’s a “hint, not a rule”.
• capability (0) — zero prod usage despite being in the enum since it was introduced. Strong signal the value is aspirational / dead. The B1 verifier already flagged this (§3 CV 04 row 3): “capability is 0 rows in prod — suggests capability may be aspirational. Worth a Liam follow-up but not blocking.”

The prod data does NOT match any documented boundary because no boundary is documented. It does, however, support consolidation as a viable option for both pairs (compliance close enough to policy to absorb; capability cleanly retire-able with zero data migration).

---

6. Recommended C1 Action for 04-content-type.md

Given no authoritative source exists, C1 should NOT invent a definition. Instead, replace the existing §Notes section with the block below, and add prod-data observations.

6.1 §Notes — replacement block

Replace the current 3-bullet §Notes with:

## Notes

- **Definitional gap — Liam decision pending.** `policy` vs `compliance` and
  `methodology` vs `capability` semantic boundaries are not documented in any
  spec, reference doc, or code artefact (verified S236 INV-2; see
  `docs/specs/wp6-ontology-harness/investigations/INV-2-content-type-semantics.md`).
  The closest related artefact (`docs/reference/classification-prompt.md` v4.7
  §"CONTENT TYPE SIGNAL GUIDE" + §6g) defines DOMAIN-classification
  disambiguation, not content_type semantics. Pending Liam ratification, the
  classifier and human authors choose based on tribal knowledge.

- **`policy` vs `compliance` — three plausible resolutions** (Liam to pick):
  (a) author-vs-evidence rule (policy = org's statement; compliance =
  evidence of adherence to external regime); (b) accept ambiguity ("either
  valid"); (c) consolidate (drop `compliance`, fold 17 prod rows into
  `policy`).

- **`methodology` vs `capability` — three plausible resolutions** (Liam to
  pick): (a) skill-vs-process rule (capability = competency offered;
  methodology = delivery approach); (b) **retire `capability`** (0 prod
  rows; safe schema migration; reduces enum to 14 values); (c) accept
  ambiguity.

- **Prod-data evidence (verified 14/05/2026):** `policy` 19 rows,
  `compliance` 17 rows (live ambiguity confirmed — counts too close for the
  values to be reliably differentiated without a rule); `methodology` 7
  rows; `capability` **0 rows** (aspirational — strong retire candidate).

- **`q_a_pair` is the dominant prod content_type** (395 of 629 rows, ~63%);
  `document` (0), `pdf` (0), `blog` (0), `product_description` (0) are
  enum-only with no prod usage. Worth tracking for v2 trim decisions.

- Closed enum for v1; client-extensible content types are research-deferred
  to v2 per §6.2 of the WP-ONTO-R1 doc.

- The full list mirrors `phase-b-prerequisite-1-onthology-pipeline.md` §2.1
  row 4 verbatim.

6.2 §Synonyms / Acronyms — replacement

Replace the existing two-bullet §Synonyms / Acronyms with:

## Synonyms / Acronyms

- `policy` vs `compliance` — semantic boundary undocumented; see §Notes.
  Pending Liam ratification per WP6 escalation §6 item 6 (B1 verifier
  report).
- `methodology` vs `capability` — semantic boundary undocumented; see §Notes.
  `capability` has 0 prod rows and is a candidate for retirement.
- `q_a_pair` — current shape; once `q_a_pairs` is promoted to a peer Layer-5
  class (S16 spike), historic content_items with `content_type='q_a_pair'`
  migrate.

6.3 §Definition — minor addition

Append one sentence to the existing §Definition:

Two semantic-overlap pairs (`policy`/`compliance` and `methodology`/`capability`)
have no documented boundary — see §Notes for the open Liam decision.

6.4 Do NOT add

• Do NOT add definitional prose to §Definition or §Baseline values that invents a boundary rule. That is exclusively Liam’s call.
• Do NOT retire capability from baseline_values without explicit Liam ratification — even if 0 prod rows, the value is in the live CHECK constraint and Zod tuple.

---

Appendix — Verification SQL

SELECT content_type, COUNT(*) AS n
FROM content_items
WHERE content_type IN ('policy','compliance','methodology','capability')
GROUP BY content_type ORDER BY content_type;

Result (14/05/2026, project rovrymhhffssilaftdwd):

content_type	n
compliance	17
methodology	7
policy	19
capability	0 (no row returned)

(GROUP BY omits empty values; capability confirmed 0 by absence.)