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