Skill: HG Subsidiary Handling
Account research scoped to the right entity — parent or subsidiary, with the choice logged.
Overview
Make sure 'research Siemens' returns the 300,000-employee parent, not the 60,000-employee Healthineers subsidiary that happens to share the brand. Claude detects when a domain resolves to a subsidiary, follows the parent link if the workflow expected parent-level scope, and logs the choice so the AE can audit which entity was researched.
Use cases
Account briefs that don't mistake a subsidiary for the parent
When the user says 'research Siemens' but uploads a CSV that includes siemens-healthineers.com, Claude follows the parent link and produces a brief sized for Siemens AG — 316,000 employees, $88B revenue — instead of a brief sized for the medical-tech subsidiary alone.
Auditable disambiguation trail
Every parent-vs-subsidiary decision is logged in the run output so the AE can verify which entity the brief covered. 'Why did the spend look low?' answers itself when you can see the resolved company in the trace.
View full skill
HG Subsidiary Handling
When to use
- A workflow takes a domain or company name and the resolved hg_id might be a subsidiary.
- A prompt is iterating over a list of accounts that may include parent + subsidiary entries.
The 31-char hg_id rule (per ADR-007)
A 31-character hg_id in HG's identifier scheme is a subsidiary identifier. Canonical parent companies have shorter ids.
The failure mode (issue #1138 root cause):
- A workflow expects "Siemens" data.
- It calls
company_firmographicwithsiemens-healthineers.comand gets a 31-char hg_id pointing to Siemens Healthineers AG (the medical-tech subsidiary). - Downstream calls (technographic, spend, contracts) return data for the 60K-employee subsidiary, not the 300K-employee parent.
- The workflow output looks confident and is wrong.
See ADR-007 for the full reasoning.
Disambiguation flow
input domain
→ company_firmographic
→ if hg_id is 31-char AND parent_hg_id is non-null:
⤷ does the workflow expect parent-level data?
⤷ YES → follow parent_hg_id; re-fetch firmographic for the parent.
⤷ NO → keep the subsidiary id; document the choice in the output.
→ if hg_id is short OR parent_hg_id is null:
⤷ proceed with the resolved company.
When does the workflow "expect parent-level data"? Default to YES unless the user explicitly named the subsidiary by domain. Examples:
- User says "research Siemens" → parent.
- User says "research siemens-healthineers.com" → subsidiary.
- User uploads a CSV of domains, one of which is a subsidiary domain → ambiguous; default to parent and log the resolution.
Falling back to search_companies
If company_firmographic returns nothing for the input domain, fall back to search_companies with the company name (parsed from the domain or supplied directly). search_companies returns multiple candidates; the workflow should pick the highest-employee result by default (parents are larger than subsidiaries).
Logging the choice
Every disambiguation decision should be logged in the workflow's run output (not just the user-facing deliverable):
[hg-subsidiary-handling] Resolved siemens-healthineers.com → subsidiary hg_id (31-char). Workflow expects parent-level data → followed parent_hg_id to siemens.com. Final company: Siemens AG.
This makes downstream audits possible — "why did the spend number look low?" answers itself.
Common pitfalls
- Trusting the first hg_id without checking length. The 31-char check is the cheap test; do it.
- Following
parent_hg_idwhen the user wanted the subsidiary. Read the input intent. - Skipping the log line. Without it, the next person debugging a "wrong company" bug has no trail.
Reference
- ADR-007 — Remove MCP primary-identifier defaults
hg-firmographic—hg_idandparent_hg_idfieldshg-insights-api.md#firmographic