Entity structure diagram

Cannot detect diagram type. Start your text with 'genogram', 'ecomap', 'pedigree', 'phylo', 'sociogram', 'timing', 'logic', 'circuit', 'blockdiagram', 'ladder', 'sld', 'entity-structure', 'fishbone', 'venn', 'flowchart', 'mindmap', 'matrix', or 'orgchart'.

Corporate ownership / legal entity / tax structure diagrams. Standardized corporate structure charts for legal, tax, M&A, VC/PE, family office, and estate planning.

References (industry conventions + related standards):

• SEC Regulation S-K, Item 601(b)(21) — Exhibit 21 subsidiary disclosure format conventions for public companies
• IRS Form 8832 — Entity Classification Election (C-Corp / pass-through / disregarded entity classification)
• ISO 3166-1 alpha-2 — Country/region codes (used for jurisdiction badge)
• ISO 20275:2017 — Entity Legal Forms classification framework in Legal Entity Identifier (LEI)
• OECD Transfer Pricing Guidelines (2022) — Conventions for representing cross-border IP licensing / royalty / service fee in structure diagrams
• ACTEC Fundamentals of Estate Planning (2023) — Standard representation of trust / grantor / trustee / beneficiary roles in structure diagrams
• Big 4 tax memo conventions (EY / PwC / KPMG / Deloitte) — De-facto standard for cross-border tax structure diagrams
• Carta / Pulley cap table visualization conventions — Modern practices for cap table visualization

Note: No single ISO/IEEE standard governs entity structure diagrams. This standard synthesizes the above sources plus practitioner conventions to form a programmatically renderable specification.

1. Structure

Entity structure diagrams express ownership / control / role relationships between legal entities. They consist of three layers:

1. Entity nodes — each legal entity (corporation, LLC, partnership, trust, foundation, natural person)
2. Relationship edges — ownership (%), control, management, distribution, licensing, services
3. Jurisdiction grouping (optional) — clusters entities by jurisdiction for visual clarity

Typical use cases:

• Legal: corporate structure due diligence, shareholder structure mapping, contract counterparty relationships
• Tax: cross-border tax planning, transfer pricing structures, pre/post transaction comparison
• M&A: transaction step diagrams, pre/post restructuring comparison, blocker corp structures
• VC/PE: cap tables, fund structures, portfolio holdings
• Family office: trust structures, estate planning, asset-isolation LLCs
• Public companies: Exhibit 21 subsidiaries visualization

Differences from other diagram types:

• Not a genogram (genogram shows bloodline relationships + gender symbols; entity structure shows legal/economic ownership + entity-type symbols)
• Not an org chart (org chart shows HR management reporting lines; entity structure shows legal entity ownership)
• Not a flowchart (flowchart shows process flow; entity structure is a static ownership snapshot)

2. Entity Types

The core of entity structure diagrams is visually distinguishing entity types. A single diagram may contain C-Corp, LLC, LP, Trust, and Individual — each legal form has different tax treatment and liability protection, so they must be immediately identifiable at a glance.

2.1 Entity Type Symbol Conventions

2.2 Node Size and Content

Each entity node contains:

• Shape (see table above)
• Entity name (12px, 600 weight, centered)
• Entity type label (10px, 500 weight, centered below name)
• Jurisdiction badge (2-letter ISO 3166-1 alpha-2, 9px, top-right corner, 18×12 with border)
• Tax classification label (optional, 10px, bottom-left)
• Issuance/formation date (optional, italic, 10px)

Default sizes:

• Corp / LLC / LP / Disregarded: 160 × 60
• Trust: ellipse rx=100, ry=40
• Individual: circle r=30 (standard) / r=35 (grantor/primary)
• Foundation: pentagon width 140, height 70

2.3 Fill Colors (by Tax Classification)

Colors are driven by --schematex-entity-* CSS custom properties and can be fully overridden by consumers. Default palette:

2.4 DSL for Entity Definition

entity <id> "<display name>" <type>@<jurisdiction> [properties]

Example:

entity parent "Acme Global, Inc." corp@DE
entity ie-holdco "Acme Ireland Holdings" corp@IE
entity ie-ip "Acme IP Ltd" corp@KY [tax: ccorp]
entity smith-trust "Smith Family Irrevocable Trust" trust@DE [est: "2024-03-15"]
entity alice "Alice Chen" individual [role: "CEO"]
entity esop "ESOP Pool" pool [note: "reserved, unissued"]

3. Jurisdiction Badge

3.1 Jurisdiction Code

2-letter codes per ISO 3166-1 alpha-2. Common codes:

Note: US state-level jurisdictions (Delaware, Wyoming, Nevada) are extremely common in US legal/tax contexts and are treated as "sub-national jurisdictions." The 2-letter state codes (DE, WY, NV, NY, CA) are permitted as jurisdiction badges. The DSL must explicitly indicate whether a code refers to a state or country; @DE is resolved as Delaware by default (most common in legal contexts).

3.2 Badge Rendering

• Position: top-right corner of node
• Size: 18 × 12 (2-letter) / 24 × 12 (3-letter, e.g. BVI)
• Background: white fill + 1px muted stroke
• Font: 9px, 600 weight, letter-spacing 0.5px
• Corner radius: rx=2

4. Ownership Edges

4.1 Edge Types

4.2 Ownership Percentage Labels

• Displayed by default: all ownership edges must carry a % label
• Showing 100%: displayed as "100%" by default; configurable with showHundredPercent: false to hide (common in blocker structure diagrams to reduce visual noise)
• V / E split (voting vs economic interest separation):

  parent -> sub : V 75% / E 50%

  Rendered as V 75% / E 50%, on one or two lines depending on configuration.
• Share class:

  vc -> acme : 20% [class: "Series A Pref"]

  Rendered: primary label 20%, secondary label Series A Pref (10px muted).

4.3 Edge Path Routing

Follows Schematex's orthogonal routing convention (same as genogram parent-child edges):

1. Start from the bottom-center of the parent node (parent_x, parent_y + height/2)
2. Go vertically down to the branch Y (midpoint between parent bottom and child top)
3. Move horizontally to the child's center X
4. Go vertically down to the child's top (child_x, child_y - height/2)

Multiple children share the same branch Y, forming a typical "E"-shape bus.

Special cases:

• If child's X aligns with parent's X: degenerates to a straight line
• Convergence routing (multiple sources → single target, e.g. cap table): reversed routing — sources connect down to a branch bar, branch bar converges to target top
• Non-hierarchical (e.g. trustee to the right of trust): horizontal straight line

4.4 Edge Label Rendering

• Position: centered on the horizontal branch segment, 2px above
• Background: white fill, light muted stroke (prevents illegibility when overlapping with edge)
• Font: 10px, 600 weight (primary) / 9px, 500 weight (sub label, e.g. share class)
• Corner radius: rx=2-3
• Padding: 4px horizontal, 2px vertical

5. Jurisdiction Cluster (Optional)

When a structure spans multiple jurisdictions, a dashed rectangle groups entities in the same jurisdiction, helping readers immediately identify regional groupings.

5.1 Cluster Rendering

• Shape: <rect> dashed stroke, stroke-dasharray="6,4", stroke 1.2px
• Color: Can be assigned by region (US = blue / EU = green / Asia = red / other = neutral gray)
• Label: top-left corner, 11px, 600 weight, letter-spacing 0.5px; white background rectangle to avoid overlap with cluster border
• Padding: 20-30px around entities inside the cluster

5.2 DSL

jurisdiction <code> "<display name>" [color: <hex>]

Example:

jurisdiction US "United States" [color: "#3b82f6"]
jurisdiction IE "Ireland" [color: "#059669"]
jurisdiction SG "Singapore" [color: "#dc2626"]

entity parent "Acme Global" corp@US
entity ie-holdco "Acme Ireland" corp@IE
...

When an entity's @jurisdiction matches a declared jurisdiction definition, it is automatically included in that cluster's rendering. If jurisdiction is not declared, only the badge is shown — no cluster is drawn.

5.3 Mixed-Jurisdiction Cluster

A single cluster may contain multiple jurisdictions (e.g. "Ireland / Cayman IP Structure" containing IE + KY entities):

cluster "Ireland / Cayman IP" [members: ie-holdco, ie-ip, nl-bv, color: "#059669"]

6. Pre/Post-Transaction Comparison

M&A, restructuring, and trust formation scenarios frequently require side-by-side display of pre-event / post-event structures.

6.1 Rendering Modes

Mode A: Side-by-side (external HTML layout)

• Two independent SVGs, "Pre-Transaction" on the left, "Post-Transaction" on the right
• Differentiated by title

Mode B: Single diagram with diff annotations (small delta)

• Single SVG with delta annotations on changed entities:
  • New entity: green stroke (#059669) + "NEW" label in top-left corner
  • Eliminated entity: red stroke + diagonal strikethrough + "ELIMINATED" label
  • Changed ownership: yellow stroke + edge annotation "was X% → now Y%"
  • Unchanged: default styling

6.2 DSL for Transaction Delta

entity newsub "NewSubCo, LLC" llc@DE [status: new]
entity oldsub "OldSubCo, Inc." corp@DE [status: eliminated]
entity changed "ChangedCo" corp@DE [status: modified]

parent -> changed : was 50% -> 100%

7. Layout Rules

7.1 Tier-Based Hierarchy (Default)

1. Topological sort — sort all entities topologically by ownership direction (parent → child); no cycles (ownership cycles are handled specially by Cross-ownership, see 7.4)
2. Tier assignment — each entity's tier = max(tier of all parents) + 1
3. Horizontal centering within tier — entities within the same tier are arranged left-to-right in order of first appearance, centered
4. Vertical gap between tiers — default 130px (sufficient space to render ownership % labels)

7.2 Width Calculation

• Each entity defaults to 200px width (including 20px padding)
• Tier width = Σ entity widths
• Canvas width = max(all tier widths) + 2 × 50px padding

7.3 Horizontal Alignment

• When a parent has multiple children, the parent is horizontally centered between the children's midpoints
• When a child has multiple parents (cap table scenario), the child is horizontally centered between the parents' midpoints

7.4 Special Layouts

Cap Table mode (multiple sources → single target):

• All shareholders (individual + LP + pool) placed in the top tier
• Target company in the bottom tier, centered
• Branch bar between tiers, converging multiple edges

Trust mode (hub + spokes):

• Grantor at top
• Trust at center of Tier 2 (ellipse)
• Trustee to the right of Trust (same tier, outside the hierarchical chain)
• Beneficiaries to the left of Trust (same tier, receiving distributions)
• Tier below Trust: Family LLC → Asset LLCs

Cross-ownership (two entities holding each other):

• Special case expressed with bidirectional arrows or two separate edges
• Does not break tier structure; S-curve edge routing used to avoid clutter

7.5 Spacing Rules

8. DSL Grammar (EBNF)

document        = header (jurisdiction_def | cluster_def | entity_def | edge_def)* legend?
header          = "entity-structure" quoted_string NEWLINE
                | "entity-structure:" quoted_string NEWLINE

jurisdiction_def = "jurisdiction" CODE quoted_string properties? NEWLINE

cluster_def     = "cluster" quoted_string properties? NEWLINE

entity_def      = "entity" ID quoted_string ENTITY_TYPE ("@" CODE)? properties? NEWLINE

edge_def        = ID edge_op ID (":" percentage)? properties? NEWLINE

edge_op         = "->"       # standard ownership (solid arrow)
                | "==>"      # voting-only control (double line arrow)
                | "-.->"     # dashed ownership (pool, conditional)
                | "-~->"     # licensing / service / management (purple dashed)
                | "-->"      # distribution (green dashed, when context is trust)

ENTITY_TYPE     = "corp" | "llc" | "lp" | "trust" | "individual" | "person"
                | "foundation" | "disregarded" | "branch"
                | "placeholder" | "tbf" | "pool"

CODE            = /[A-Z]{2,3}/   # ISO 3166-1 alpha-2 or 3-letter exception (BVI)

percentage      = /[0-9]+(\.[0-9]+)?%/
                | "V" ws /[0-9]+%/ "/" "E" ws /[0-9]+%/   # V/E split

properties      = "[" property ("," property)* "]"
property        = "class:" quoted_string            # share class
                | "label:" quoted_string            # edge text label
                | "status:" STATUS                  # new | eliminated | modified
                | "tax:" TAX_CLASS
                | "est:" quoted_string              # formation date
                | "role:" quoted_string             # for individuals
                | "note:" quoted_string
                | "color:" HEX
                | "members:" "[" ID_LIST "]"        # for cluster def
                | kv_prop

STATUS          = "new" | "eliminated" | "modified" | "normal"
TAX_CLASS       = "ccorp" | "passthrough" | "scorp" | "trust"
                | "disregarded" | "foundation" | "individual"

ID              = /[a-zA-Z][a-zA-Z0-9_-]*/
HEX             = /#[0-9a-fA-F]{3,8}/
quoted_string   = '"' /[^"]*/ '"'

9. Test Cases

Case 1: PE Holding Structure (3 tiers · 4 entities · all Delaware)

Corresponds to sample 01-pe-holding.svg. Demonstrates a typical PE holding structure: LP → Blocker Corp → 3 portfolios.

entity-structure "Acme Holdings Fund I — Portfolio Structure"

entity lp "Acme Holdings Fund I" lp@DE
entity blocker "Acme Blocker Corp" corp@DE
entity widgets "Acme Widgets, Inc." corp@DE
entity services "Acme Services, LLC" llc@DE
entity intl "Acme International, Inc." corp@DE

lp -> blocker : 100%
blocker -> widgets : 100%
blocker -> services : 100%
blocker -> intl : 100%

Verify:

• LP node renders as a notched-corner polygon (distinct from Corp sharp corners and LLC rounded corners)
• All nodes carry "DE" jurisdiction badge
• 3 children branch from the same branch bar below Blocker
• Each edge carries a "100%" label

Case 2: Startup Cap Table (Post-Series A · 5 shareholder types → 1 C-Corp)

Corresponds to sample 02-startup-captable.svg. Demonstrates cap table layout with multiple sources → single target.

entity-structure "Acme Technologies, Inc. — Cap Table (Post-Series A)"

entity alice "Alice Chen" individual [role: "Co-founder · CEO"]
entity bob "Bob Martinez" individual [role: "Co-founder · CTO"]
entity carol "Carol Wei" individual [role: "Co-founder · VP Eng"]
entity vc "Sequoia Fund XX" lp@DE
entity esop "ESOP Pool" pool [note: "reserved, unissued"]
entity acme "Acme Technologies, Inc." corp@DE [note: "Fully diluted: 10M shares"]

alice -> acme : 30% [class: "Common"]
bob -> acme : 25% [class: "Common"]
carol -> acme : 15% [class: "Common"]
vc -> acme : 20% [class: "Series A Pref"]
esop -.-> acme : 10% [class: "Option Pool"]

Verify:

• 5 sources placed in the same tier (top tier)
• Individual renders as circle + name below + role label
• ESOP as dashed rounded rectangle (gray fill)
• VC (LP) as notched-corner polygon
• Series A Pref edge and label are blue and bold (distinct from common stock)
• Option Pool edge is dashed
• All edges converge to the bottom C-Corp

Case 3: Cross-Border Tax Structure (5 jurisdictions · with IP licensing)

Corresponds to sample 03-international-tax.svg. Demonstrates jurisdiction clusters + non-ownership relationships.

entity-structure "Acme Global — International Holdings Structure"

jurisdiction US "United States" [color: "#3b82f6"]
jurisdiction IE "Ireland" [color: "#059669"]
jurisdiction KY "Cayman Islands" [color: "#059669"]
jurisdiction NL "Netherlands"
jurisdiction SG "Singapore" [color: "#dc2626"]

cluster "Ireland / Cayman IP" [members: [ie-holdco, ie-ip, nl-bv], color: "#059669"]
cluster "Singapore APAC" [members: [sg-holdco, sg-apac], color: "#dc2626"]

entity parent "Acme Global, Inc." corp@DE [note: "Ultimate Parent"]
entity ie-holdco "Acme Ireland Holdings" corp@IE
entity sg-holdco "Acme Singapore Pte" corp@SG
entity ie-ip "Acme IP Ltd" corp@KY [note: "holds group IP"]
entity nl-bv "Acme EU Distribution" corp@NL [note: "EMEA ops"]
entity sg-apac "Acme APAC Trading" corp@SG [note: "APAC ops"]

parent -> ie-holdco : 100%
parent -> sg-holdco : 100%
ie-holdco -> ie-ip : 100%
ie-holdco -> nl-bv : 100%
sg-holdco -> sg-apac : 100%

ie-ip -~-> nl-bv [label: "IP License · royalty"]

Verify:

• US / Ireland-Cayman / Singapore — 3 clusters enclosed by dashed borders in different colors
• Each entity carries the correct jurisdiction badge (DE / IE / SG / KY / NL)
• IP License edge is purple dashed (distinct from ownership edges which are solid black)
• 3-tier hierarchy is clear with correct parent-child relationships

Case 4: Family Trust Structure (Grantor + Trust + Trustee + Beneficiaries + Asset LLCs)

Corresponds to sample 04-family-trust.svg. Demonstrates trust mode + 3 semantic edge types (ownership / distribution / management).

entity-structure "Smith Family — Trust & Asset Holding Structure"

entity grantor "John Smith" individual [role: "Grantor / Settlor"]
entity trust "Smith Family Trust" trust@DE [est: "2024-03-15", note: "Irrevocable Dynasty Trust"]
entity trustee "Northern Trust" individual [role: "Independent Trustee"]
entity beneficiary1 "Emma Smith" individual [role: "Beneficiary (50%)"]
entity beneficiary2 "Liam Smith" individual [role: "Beneficiary (50%)"]
entity famllc "Smith Family Holdings" llc@DE
entity realestate "Smith Real Estate" llc@DE [note: "property holding"]
entity investment "Smith Investments" llc@DE [note: "liquid assets"]

grantor -> trust [label: "Settles · funds"]
trustee -~-> trust [label: "Manages"]
trust --> beneficiary1 [label: "Distributions"]
trust --> beneficiary2 [label: "Distributions"]
trust -> famllc : 100% [label: "100% Owner"]
famllc -> realestate : 100%
famllc -> investment : 100%

Verify:

• Trust renders as a purple-fill ellipse, centered in tier 2
• Grantor renders as circle r=35 (primary size), tier 1
• Trustee positioned to the right of Trust (non-hierarchical position), purple dashed line indicates management
• Beneficiaries positioned to the left of Trust, green dashed lines indicate distribution
• Family LLC in tier 3 below Trust
• 2 asset LLCs in tier 4, each 100% owned by Family LLC
• 3 distinct edge colors (solid black / purple dashed / green dashed) clearly differentiated

Case 5: Pre/Post Transaction Comparison (M&A · builds on Case 1)

entity-structure "Acme Holdings — Pre vs Post Acquisition"

# Pre-transaction
entity parent "Acme Holdings" corp@DE
entity target "TargetCo" corp@DE [status: normal]
parent -> target : 40%

# Post-transaction
entity newparent "Acme Holdings" corp@DE [status: normal]
entity newtarget "TargetCo" corp@DE [status: modified]
entity mergesub "MergeSub" llc@DE [status: new, note: "formed for merger"]
newparent -> mergesub : 100%
mergesub -> newtarget : was 40% -> 100%

Verify:

• "MergeSub" entity renders with green stroke + "NEW" label
• "TargetCo" renders with yellow stroke (modified)
• Edge label clearly annotates "was 40% → 100%"

10. Accessibility

• Every SVG must include <title> + <desc>
• Each entity node carries a <title> description (screen reader-friendly)
• Entity name is plain <text>, not replaced by an image
• ARIA roles: role="graphics-document" on SVG, role="graphics-symbol" on each entity

11. Interaction Hooks (future)

• data-entity-id on each entity node (foundation for external interaction)
• data-from / data-to on each edge
• data-ownership-pct on ownership edges
• data-jurisdiction on entity node
• data-entity-type on entity node
• data-tax-class on entity node
• CSS hover classes: .schematex-entity-node:hover customizable by consumers

12. Implementation Priority

13. Coverage Matrix

Verifies complete coverage of this standard across all 4 sample cases:

Conclusion: The entity types, edge types, layout rules, jurisdiction clusters, and DSL grammar defined in this standard collectively cover the full visual requirements of all 4 sample cases, and can directly drive parser + renderer implementation.