§23 Portfolio Patterns

v2.0.0 · Locked · L1 · March 19, 2026

Multi-instance topology produces portfolio-level patterns that cannot be specified within a single substrate instance. When an organization operates multiple instances — or when multiple organizations share governance infrastructure through federation — five architectural patterns emerge: recursive viable system structure, constraint cascade with authority attenuation, portfolio management as emergent capability, federation as recursive pattern across legal entity boundaries, and depth-gated visibility.

These patterns are not additions to the primitive model. They are compositions of the nineteen primitives (§4) operating across instance boundaries, governed by the same ten behavioral invariants (§5), and grounded in the same control-theoretic foundation (§8). What changes at portfolio scale is the topology — how instances relate, how constraints propagate, and how authority attenuates through recursion.

This section specifies the portfolio-level patterns. §21 specifies what kinds of instances exist (EAS, BAS, PAS profiles). §22 specifies who participates and how actor identity persists across instances. §23 specifies what emerges when multiple instances form a governed topology.

Purpose

Portfolio patterns describe the emergent governance behaviors when instances compose across organizational boundaries. They operationalize Beer's viable system model at computational scale, enforce constraint cascade and authority attenuation across recursion levels, enable federation of independent governance domains, and provide depth-gated visibility that respects both organizational transparency needs and operational privacy boundaries.

Foundation

§23.1 Recursive Viable System Architecture

Professional services firms — and any organization with sufficient structural complexity — are recursive viable systems. The same governance pattern repeats at every level of organizational complexity, following Beer's recursion principle (§8.2): each viable system contains viable systems, each operating the same five subsystems (S1–S5) at its own scale.

The recursive pattern is not an analogy. It is a structural property of the substrate architecture. Every EAS node is a viable system with its own operations (S1), coordination (S2), control (S3), intelligence (S4), and policy (S5). The nineteen primitives compose the same way at every recursion level. The behavioral invariants enforce the same constraints at every recursion level. The state transformation model operates the same way at every recursion level.

The Recursive Pattern

Profile assignment — whether a node operates as EAS, BAS, or PAS — is determined by organizational complexity at each recursion level, not by position in the hierarchy.

A node operates as EAS when it has its own methodology or methodology specialization, contains subordinate operational units, requires its own governance framework, and manages a portfolio of engagements or relationships.

A node operates as BAS when it operates within a parent EAS's governance framework, has ongoing business rhythm but not subordinate units requiring their own governance, and manages relationships rather than portfolios.

A node operates as PAS when it is bounded in scope and time, has clear completion criteria, and archives on completion.

Illustrative recursion for a professional services firm:

Firm (EAS) → Service Line (EAS) → Region (EAS) → Client Engagement (BAS) → Project (PAS)

The depth is not predetermined — it emerges from organizational complexity. Recursion can branch by service line, geography, practice area, engagement complexity, or jurisdictional requirements. Any BAS node may graduate to EAS if it becomes complex enough to require its own governance substrate.

Table 23.1.1: Recursive Pattern Properties

Table 23.1.2: Illustrative Multi-Level Recursion

At every level, the same governance grammar operates. What differentiates levels is the threshold calibration, constraint envelope, and authority scope — not the architectural machinery.

§23.2 Constraint Cascade & Authority Attenuation

The Tighten-Only Rule

Each level in the recursion inherits its parent's constraints and may tighten but never loosen them. The constraint set at any node equals the intersection of all ancestor constraints plus the node's own constraints.

Constraint(node) = Constraint(root) ∩ Constraint(level-1) ∩ ... ∩ Constraint(parent) ∩ Constraint(own)

This applies to governance constraints, threshold values, AI graduation ceilings, and authority scopes. A child node cannot set any threshold looser than any ancestor. If the firm specifies Level 2 maximum AI autonomy for reasoning, no descendant can operate AI at Level 3 for reasoning — regardless of local context.

B6 — Constraint binds primitives (§5) — operates across instance boundaries. Constraints defined at a parent EAS bind primitive instances in all descendant nodes. The enforcement mode (Blocking, Warning, Logging, Advisory) cascades with the constraint.

Table 23.2.1: Threshold Cascade Example

Each row demonstrates the tighten-only rule. Values either inherit from the parent (no change) or tighten (more restrictive). No value loosens. The cascade is computable: given any node's position in the recursion, the effective threshold set is deterministically derived from the ancestor chain.

Authority Attenuation

Authority attenuates through recursion the same way it attenuates through delegation hops within a single instance. Each delegation between instances is a composition of primitives:

Delegation(parent → child) = Intent (purpose delegated to this level)

• Authority (scoped — parent delegates to child within bounds)
• Constraint (parent constraints inherited + child-specific added)
• Commitment (organizational commitment to operate this sub-unit)
• Work (scope of what this level handles)
• Account (why this level exists, under what terms)

Each level can narrow the authority scope but never widen it. A regional partner can delegate to engagement teams only within the scope the service line partner delegated to the region. Authority attenuation is monotonic through the recursion.

Constraint Relaxation Governance

The tighten-only rule governs delegation direction, not permanence. Loosening is possible through an evidence-driven process via the authority chain — but the constrained instance cannot self-loosen.

The relaxation process follows five steps:

1. Evidence accumulates at the constrained instance. Operational data surfaces an overly tight constraint — for example, a materiality threshold that forces unnecessary escalation volume.
2. Evidence surfaces as Signal to the constraining authority. The Signal routes per B8 (§5) — to an authority on the governance chain for the constrained object.
3. Constraining authority makes a Decision with Account based on the accumulated evidence. The Decision evaluates whether relaxation is warranted and records the rationale.
4. Modified delegation flows down. The adjusted constraint propagates to the constrained instance and its descendants. The modified constraint still cannot exceed the constraining authority's own position — a service line partner cannot relax a constraint beyond the firm-level ceiling.
5. Chain is recursive upward. If the constraining authority is itself constrained by its parent, relaxation at that level requires the same evidence-driven process one level up.

This ensures every loosening is a governed decision with evidence, authority, and lineage. The governance value is in ensuring that constraint evolution is accountable, not in permanent tightening regardless of operational evidence.

§23.3 Substrate Portfolio Manager (SPM)

Emergence

Substrate Portfolio Management is not a separate product or a distinct architectural component. It is the Actor Layer's (§22) portfolio view — the capability that surfaces automatically when a principal has multiple instances or when an EAS node has children.

Table 23.3.1: SPM Emergence Triggers

SPM capabilities emerge at any EAS node when it has children. A service line partner sees their regional portfolio. A regional leader sees their engagement portfolio. The firm sees the global portfolio. The same emergence logic applies at every recursion level.

Instance Relationship Types (Portfolio-Level)

Instance relationships at the portfolio level describe how instances relate across the recursive topology. Structural relationships between actors and instances (owner, sponsor, participant) are specified in §22. Portfolio relationships describe how instances relate to each other.

Table 23.3.2: Portfolio-Level Instance Relationship Types

Spawning as Delegation Event

Spawning a new instance is a delegation event — a composition of primitives that crosses instance boundaries:

Spawn(parent → child) = Intent (why this child instance exists)

• Authority (who authorized creation, with what scope)
• Constraint (parent constraint envelope inherited)
• Commitment (resources allocated, obligations established)
• Work (what this instance handles)
• Account (creation decision with full lineage)

The spawned instance inherits its parent's constraint envelope from the moment of creation. This inheritance is architectural — B6 (Constraint binds primitives) operates across instance boundaries. The spawning graduation stage is governed by the tighten-only rule: the parent chooses the child's starting graduation stage, up to and including the parent's own stage. The parent's stage is the upper bound. A parent at Stage B can start a child at Stage A or Stage B, but never at Stage C.

Cross-Instance Resource Flow

Each EAS tracks resource pools for its scope. Child instances receive allocations from the parent. Resources flow downward through the recursion and are tracked at each level.

Conflicts are detected when sum(allocations) > available at any level. SPM surfaces rebalancing recommendations at the level where the conflict occurs. If the conflict is unresolvable at the current level — all allocations are FIXED and the sum exceeds capacity — it escalates to the parent EAS.

SPM provides four portfolio capabilities:

• Unified resource view — aggregate resource allocation and utilization across all instances in the portfolio
• Cross-instance lineage — trace decisions, evidence, and authority relationships across instance boundaries
• Portfolio-level deviation measurement — detect drift patterns across multiple instances that are invisible within any single instance
• Capacity allocation — allocate and rebalance resources across instances with conflict detection and resolution

§23.4 Federated Professional Services Framework (FPSF)

Federation as Recursive Pattern

Federation is not a separate model from the internal recursive structure. It is the same recursive pattern with the instance boundary crossing legal entity lines rather than internal organizational lines.

Internal structure: Firm (EAS) → Service Line (EAS) → Region (EAS) → Client Engagement (BAS)

Federation structure: Parent Firm (EAS) → Practitioner (EAS) → Client (BAS)

The constraint cascade, authority attenuation, threshold inheritance, and spawning mechanics are identical. The architectural difference is the nature of the boundary: internal nodes share a legal entity; federation nodes are separate legal entities connected by licensing agreements. The licensing agreement is the Constraint primitive instantiated at the organizational boundary.

Table 23.4.1: Federation Licensing Tiers

Each tier represents a deeper constraint integration between licensor and licensee. At the Methodology Only tier, the licensing constraint specifies methodology adherence. At Full Federation, the licensing constraint extends to infrastructure standards, AI orchestration parameters, and shared quality frameworks. The constraint mechanics are identical to internal cascade — only the legal vehicle differs.

Table 23.4.2: Federation Party Roles

Federation Constraint Mechanics

The federation licensing agreement specifies constraints that cascade to the practitioner's child instances:

• Methodology constraints — practitioner must follow licensed methodology
• Quality constraints — practitioner must meet parent firm quality standards
• Reporting obligations — aggregate metrics flow upward, not client details
• Depth-gating rules — parent sees aggregate performance, not individual engagement data

These constraints cascade to the practitioner's child instances identically to how firm constraints cascade to internal child instances. The practitioner's client engagement (BAS) inherits constraints from both the practitioner's own EAS and, transitively, from the parent firm's EAS.

Depth-Gating

Recursive visibility follows a depth-gating rule at every level of the recursion, including across federation boundaries.

Each node sees:

• Its own instance data (full detail)
• Its direct children (full detail, subject to depth-gating for grandchildren)
• Aggregate patterns from deeper descendants

Each node does not see:

• Sibling instances at the same level
• Cousin instances in other branches
• Parent operational data (unless explicitly shared)

Sibling isolation is by design. Two service lines within the same firm cannot see each other's engagement detail. Two practitioners within the same federation cannot see each other's client data. Visibility follows the parent-child axis, never the sibling axis.

Table 23.4.3: Depth-Gated Visibility by Role

The federation parent's visibility is explicitly limited. At the Methodology Only licensing tier, the parent receives compliance attestation. At Full Federation, the parent receives aggregate performance metrics. At no tier does the parent receive individual client engagement detail — depth-gating enforces this boundary architecturally.

Connection to AI Orchestration

The five-dimensional routing space (§A1) operates at every recursion level. An AI actor in a leaf-node BAS routes against all five dimensions — AICAR cognitive type, decision type, consequence level, operating posture, and graduation stage — with thresholds set by the intersection of every ancestor EAS's calibration.

Federated AI actor delegation follows the same delegation-as-composition pattern. An AI actor registered at a parent EAS can be delegated to operate within a child instance. Parent EAS constraints travel with the delegation. The child instance can add constraints but not remove parent constraints. Authority attenuation applies: the AI actor's scope in the child instance is bounded by its scope in the parent.

Cross-instance posture shifts propagate through the recursive structure. When an EAS node declares an operating posture shift (e.g., emergency mode), the shift propagates to all child instances within that branch. A firm-wide emergency affects all service lines. A regional emergency affects only that region's engagements. Posture shifts at child level surface to the parent as Signals — the parent EAS's monitoring detects when child nodes operate under non-standard posture.

When threshold breach cascades work from one decision type scope to another, per-scope graduation governs routing authority at the destination scope. Cascade context — origin decision, cascade chain, accumulated evidence — travels with the work as lineage.

Governance

No Governance section for this document.

Substance

§23.5 SDK Constraints Summary

Table 23.5.1: §23 SDK Constraints

§23.6 Cross-References

Boundaries

No Boundaries section for this document.

Positions

No Positions section for this document.

Lineage

No Lineage section for this document.

Commitments

All SDK constraints listed in §23.5 are binding implementation requirements for DLP substrate builders.

Coverage

Complete specification of portfolio-level patterns including recursive viable system architecture, constraint cascade with tighten-only rule and relaxation governance, Substrate Portfolio Manager emergence, instance relationship types, spawning as delegation, cross-instance resource flow, Federated Professional Services Framework with licensing tiers, depth-gated visibility model, AI orchestration across recursion, and all mandatory constraints with design space parameters.