docs: distinguish client agencies from contractors

SKILL.md

@@ -236,7 +236,7 @@ Keep each field explicitly unknown when evidence is absent. Do not substitute DN
 
 A procurement or support notice can directly establish production cloud hosting even when it does not name the supplier or cloud provider, but only when its body explicitly says that the production system operates in the cloud infrastructure covered by the service (for example, rental and operation of the cloud infrastructure **in which the named chatbot runs**). Record `model: cloud`, describe the environment as unnamed, retain the provider as unidentified, quote the decisive wording, and do not infer AWS, Azure, GCP, ownership, region, tenancy, or supplier identity. Before attaching this evidence to canonical analysis, inspect every observation grouped under that system identity. If the label is generic—such as “intelligent chatbot”—scope it to the client first unless direct evidence proves all grouped observations are the same shared system. When scoping creates a new system ID, migrate only the client-specific evidence to the scoped ID and leave the former generic record unknown unless it has independent system-wide evidence.
 
-See [`references/cross-client-system-registry.md`](references/cross-client-system-registry.md) for the full identity, provenance, generation, validation, and continuous-research method. When contractor/provider observations need a first-class cross-client view, follow [`references/derived-contractor-registry.md`](references/derived-contractor-registry.md) for evidence-preserving entity extraction, stable `CTR-*` identities, navigation, test-first generation, and deployment validation. On generated client pages, keep every named contractor attached to the exact system observation where its role is evidenced and link the entity to its derived `CTR-*` contractor card; leave unknown placeholders explicit and unlinked. Validate complete Client→system→contractor-card link coverage both during generation and against rendered production routes. For canonical per-system cloud/on-premises, kickoff, and latest-release fields—including evidence objects, exact-coverage validation, identity migration, and automation rules—follow [`references/system-infrastructure-lifecycle-analysis.md`](references/system-infrastructure-lifecycle-analysis.md).
+See [`references/cross-client-system-registry.md`](references/cross-client-system-registry.md) for the full identity, provenance, generation, validation, and continuous-research method. When contractor/provider observations need a first-class cross-client view, follow [`references/derived-contractor-registry.md`](references/derived-contractor-registry.md) for evidence-preserving entity extraction, stable `CTR-*` identities, navigation, test-first generation, and deployment validation. On generated client pages, keep every named contractor attached to the exact system observation where its role is evidenced and link the entity to its derived `CTR-*` contractor card; leave unknown placeholders explicit and unlinked. Classify the entity before creating a `CTR-*` record: a government ministry, agency, authority, or other client body is not a contractor merely because it operates or centrally provides a shared service. Preserve that public-service relationship in the observation, keep/research the body as a Client when in scope, and exclude it from contractor extraction unless direct evidence establishes a genuinely separate contracting entity and role. Validate complete Client→system→contractor-card link coverage both during generation and against rendered production routes. For canonical per-system cloud/on-premises, kickoff, and latest-release fields—including evidence objects, exact-coverage validation, identity migration, and automation rules—follow [`references/system-infrastructure-lifecycle-analysis.md`](references/system-infrastructure-lifecycle-analysis.md).
 
 ## Batch Execution Discipline
 

references/derived-contractor-registry.md

@@ -14,6 +14,8 @@ Treat the contractor registry as a **derived view**, never as a second editable
 
 Do not turn `Not publicly identified`, “suppliers not named”, descriptive prose, or an ambiguous composite phrase into entities. Do not silently upgrade one role into another: development does not prove hosting or current support.
 
+Classify the entity itself before deriving a contractor card. A ministry, agency, authority, or other government body does not become a contractor merely because an observation calls it an operator, centralized service provider, platform owner, or public-sector implementer. If that body is itself an investigation subject, retain it in the Clients registry and preserve its exact service relationship as observation text, but exclude it from `CTR-*` extraction and contractor links. Research its own systems and commercial delivery partners from its Client dossier. Add an explicit, reviewed exclusion rule when free-text parsing would otherwise promote the body; do not hide the relationship or rewrite the public agency as a commercial supplier.
+
 ## Identity and stable routes
 
 Normalize only safe textual differences for matching. Preserve the displayed source name and keep ambiguous composites separate until evidence supports a split or merge. Generate stable `CTR-*` IDs and slugs from a durable normalized identity key rather than sequence position. Sequence numbers may order generated files but must not define identity.