Sibling-homogeneity fails the scope test harder than object-focus did, and the exception it was supposed to justify was never written

The question

Verbatim: "Does sibling-homogeneity survive the same artifact-scope test that cleared FN.OPERATIONS.REAL_ESTATE, or is FN.CORE_PRODUCTION's abstract slot a genuine declared exception?"

Context: [[2026-08-22-bizbok-object-focus-invariance-real-estate]] resolved the REAL_ESTATE flag by finding the test mis-scoped rather than failed. It explicitly declined to extend that finding to CORE_PRODUCTION, whose flag rests on a different borrowed rule, and queued this question. Sibling-homogeneity is the second and last of the two normative rules the Organizational Platform imported from BIZBOK.

What we already know (from the vault)

• The rule as imported, and the flag it produced. [[2026-08-17-bizbok-operating-model-function-motion-mapping]] quoted sibling homogeneity as "capability principles, structure, and performance remain consistent at every level of hierarchical decomposition" and applied it: under Operations, "Core production" is "a deliberately abstract slot per PRINCIPLE.CORE_PRODUCTION_ABSTRACT while its three siblings are concrete named motions. That is level mixing on BIZBOK's terms." Its own verdict was that this is "probably the correct design" but should be a declared architectural exception.
• The parent brief ring-fenced it. [[2026-08-22-bizbok-object-focus-invariance-real-estate]] cleared REAL_ESTATE and IT.SECURITY, then wrote: "I would leave CORE_PRODUCTION's abstract-slot note alone: that one is about sibling homogeneity and level-mixing, a different rule, and this brief does not clear it."
• The decision memo recommended a note that never shipped. spec/00-template-decisions.md D-3 recommended adding declared_exception: to the two object-focus nodes "(and CORE_PRODUCTION's abstract-slot level-mixing, which [2] says should be a declared architectural exception)."
• The borrowed-rule inventory is exactly two items long. The grandparent brief's borrow row lists (a) object-focus invariance and (b) sibling homogeneity as tests; the other three borrows (organization-map lineage, value-stream vocabulary held in reserve, cross-mapping as a word) are naming and framing, not constraints. Answering this question exhausts the set of rules the platform inherited on borrowed authority.
• Related framing already in the vault. [[industry-process-reference-models]] records the round-level negative result: no external framework supplies a motion catalog, and the BIZBOK rules do not bind the org tree.

What the primary source says (VERIFIED-FROM-PRIMARY)

I downloaded and text-extracted the Business Architecture Guild's Business Architecture Metamodel Guide v3.0 (September 2024, free public whitepaper) rather than relying on the parent brief's excerpts. Page and section references below are from that extraction. The member-gated BIZBOK Guide capability chapter was not accessed; nothing below depends on it.

• The homogeneity sentence exists, verbatim, and its grammatical subject is "capability." Full sentence, §6.3: "Capability similarly accommodates elaboration through decomposition, whereby a given capability decomposes into more fine-grained capabilities. Capability principles, structure, and performance remain consistent at every level of hierarchical decomposition." The parent brief's quote is confirmed. It is also, on its face, scoped narrower than the object-focus rule was, because the constraint's subject is named in the sentence itself.
• The passage exists in order to draw a contrast with process decomposition, where levels are explicitly NOT homogeneous. The immediately preceding paragraphs describe process decomposition: "High-level processes decompose into lower-level elements, such as Subprocess or (atomic) Activity." The homogeneity sentence opens with "Capability similarly accommodates elaboration through decomposition" and then states what is different about it. So the rule is doubly capability-scoped: by its subject, and by the rhetorical work the sentence is doing.
• The organization domain has no counterpart rule. §5.4 states the whole of its decomposition discipline: "Organization mapping is not constrained to a specific format. A business unit is a sub-type of organization." And: "a business unit can decompose into more business units, enabling the creation of organizational hierarchies." The words "homogeneous," "sibling," and "peer" do not appear anywhere in the document; "consistent at every level" appears exactly once, in the capability sentence above.
• The guide's own exemplar organization map has heterogeneous siblings, by unit type. Figure 18's transportation org map lists at Business Unit Level 2 three siblings: Dispatch Center (Business Unit Type: Business unit), Customs Clearance Service, Ltd. (Business Unit Type: Partner), and Network Control (Business unit). An external partner company sits as a peer of two internal units at the same level, with a different unit type. This is not a permission granted in passing; it is the illustrative example the guide chose to show what an organization map looks like.
• Abstraction-then-instantiation is the metamodel's normal mode, not a deviation. §5.2: "Capability Instance: A specific realization of a capability, as it exists or is envisioned to exist, in the context of a given business unit or another situational context." The guide expects the abstract node to be the durable one and the concrete realization to vary. An abstract slot filled per context is the pattern, not the exception to it.
• Secondary sources add nothing that contradicts this. A survey of practitioner writing turns up level-consistency advice attached specifically to capability maps ("the level 1 capabilities on a capability map are always based on information concepts"), and organization-map writing that describes only enterprise-at-level-0 plus free decomposition (Biz Arch Mastery on organization mapping). No source states a homogeneity constraint for organization maps.

What the live repo says (VERIFIED-FROM-PRIMARY)

Read directly from ~/Documents/phdata-projects/organizational-intelligence/ on 2026-08-26:

• FN.OPERATIONS.CORE_PRODUCTION carries no declared_exception. Its frontmatter is four fields: id, sid: OP-10029, name, function. D-3's recommendation was never implemented on that node.
• The declared_exception field appears on exactly two pages platform-wide, fn-operations-real-estate.md and fn-it-security.md, both citing object-focus. The template's own scope line names the same closed set: "current set: FN.OPERATIONS.REAL_ESTATE, FN.IT.SECURITY — the object-focus flags from the BIZBOK brief."
• The field has zero machine consumers. No occurrence of declared_exception anywhere in tools/. It is reader-facing frontmatter plus a body note, nothing more.
• The tree cannot level-mix, structurally. It is exactly three authored tiers: 10 function pages, 36 motion pages, 80 role pages. No motion page carries a motions: key, so no L3 node exists, and DEFER.L3_EMERGENCE in spec/schemas/function-rules.yaml confirms L3 is deferred to first live use by design.
• CORE_PRODUCTION is structurally identical to its three siblings. Same section set, an explicit object statement matching the parent ("The object stays the same as every Operations motion — the unit of production"), a Configured-as table with all three rows populated, an exhaustive typical-workflows treatment, and three roles. Its siblings QUALITY_CONTROL, MAINTENANCE and REAL_ESTATE have the same shape.
• What PRINCIPLE.CORE_PRODUCTION_ABSTRACT actually says is about instantiation, not level. Verbatim: '"Core production" is deliberately abstract at L2 — the slot every industry fills with its own value-making work (KT: store ops + food production; insurance: underwriting + claims processing…).' It asserts the node sits at L2, the same level as its siblings.
• The object test, by contrast, is a live RDCO-authored house rule. All 10 function pages state one in their Primary objective section, and the template requires it. There is no corresponding house rule for level-cleanliness anywhere in the template or the schemas. The grandparent brief recommended sibling homogeneity as a test; it was never adopted.

Convergences and contradictions

• Convergence, and it is stronger than the parent brief's. Two independent lines both clear the node. The rule is capability-scoped by its own sentence and has no organization-map counterpart, and the node is not level-mixed on any reading, since the tree has no second level to mix with and the node's page shape matches its siblings exactly. Either finding alone would be sufficient. The parent brief needed a single scope argument; this one does not.
• The premise of the question is false on disk, which nobody had checked. The question asks whether CORE_PRODUCTION's abstract slot is "a genuine declared exception." There is no declared exception on that node to adjudicate. D-3 recommended one, and the authoring pass wrote the other two and silently dropped the third. The correct action is not to remove a note but to decline to add one.
• Contradiction with the backlog note's forecast, and it matters. The backlog framing predicted that clearing this rule would show declared_exception to be "unnecessary platform-wide." It does not. The template scopes the field to "where the platform knowingly deviates from its own design rules," and the object test is one of its own design rules, authored on all 10 function pages. What the parent brief actually dissolved is the BIZBOK attribution of that rule, not the rule and not the mechanism recording deviations from it.
• The one real asymmetry is naming, not structure. Three Operations motions are named for an activity; CORE_PRODUCTION is named for its position ("the industry's value-making work"). An architect reading the tree will notice that. It is a naming observation with no rule behind it, and it is already documented in the right place, as a machine-readable principle in function-rules.yaml.

Synthesis for RDCO

Verdict: sibling-homogeneity fails the scope test, more cleanly than object-focus did, and FN.OPERATIONS.CORE_PRODUCTION is not an exception to anything. The rule's own sentence names capabilities as its subject, sits in a passage written to distinguish capability decomposition from process decomposition, and has no counterpart in the organization domain, whose entire stated discipline is that mapping "is not constrained to a specific format." The guide's exemplar organization map then puts an external partner company beside two internal business units as level-2 siblings. Heterogeneous siblings are not tolerated in an organization map; they are demonstrated in the reference example. The recommendation is to write no declared exception on CORE_PRODUCTION, close D-3's third clause as answered rather than outstanding, and record that the borrowed-invariant inventory is now exhausted, since object-focus and sibling-homogeneity were the only two normative rules imported on BIZBOK's authority.

A second, independent argument gets to the same place without needing BIZBOK at all, and it is the one worth putting on the page if anyone ever asks. The tree has three authored tiers and no L3, so there is no lower level for CORE_PRODUCTION to be mixed with. The node states the same object as its siblings, carries the same section set, populates the same Configured-as dimensions and staffs three roles like a normal motion. "Abstract" in PRINCIPLE.CORE_PRODUCTION_ABSTRACT means industry-instantiated, not higher-level, and the principle text says so explicitly by locating the node at L2. Even a strict homogeneity reading applied to our artifact would pass it. That matters because it means the verdict does not depend on winning the scope argument twice.

But the backlog note's larger inference is wrong, and correcting it is the actionable finding. The hypothesis was that clearing this rule would make the declared_exception machinery unnecessary platform-wide. It does the opposite. The field is scoped by the template to deviations from the platform's own design rules, and the object test is exactly that: an RDCO-authored admission test written into all 10 function pages and into the content template, independent of whether BIZBOK inspired it. REAL_ESTATE really does depart from a rule the platform publishes about itself, and recording that is honest. So keep the field, keep both existing notes, and make the parent brief's correction narrower than it proposed. The edit is to the notes' citation, not their existence: they should say the node departs from the platform's object test, an internal RDCO admission heuristic, and drop any implication that a published external standard is being violated. This is a refinement of the parent brief's recommendation, which read as "retire the exception framing" and would, taken literally, delete a true statement about a real house rule.

The practical effect on the platform is that the abstract-slot question closes at zero cost and the tree is now clean ahead of the client YAMLs. Two frontmatter re-wordings on fn-operations-real-estate.md and fn-it-security.md, one line in spec/00-template-decisions.md marking D-3's CORE_PRODUCTION clause resolved-as-no-action, and nothing else. No node moves, no id changes, no re-parenting, and the dual-identifier work from [[2026-08-17-apqc-pcf-function-motion-mapping]] is not exercised. The one thing this brief does not clear is the MAINTENANCE / REAL_ESTATE naming overlap that the parent brief isolated as the single surviving defect. That remains open and still wants a founder read.

Why this is in the vault

This closes the third and last open item in spec/00-template-decisions.md D-3, which recommended a declared_exception on CORE_PRODUCTION that was never written, and it tells the authoring pass to leave the node alone rather than add one. It also corrects a specific instruction the parent brief was about to hand the same authoring pass: "retire the exception framing" was too broad, because the object test is a live house rule and the two existing notes have a real referent that survives the BIZBOK correction.

Open follow-ups

• The Intelligence Platform is the artifact that actually lives in the capability domain. It uses "capability" natively, in the same client room, and the platform's vocabulary guard exists precisely to keep the two words apart. Nobody has run object-focus invariance or sibling-homogeneity against it, where both rules would genuinely bind. That is the mirror of this question and it is unexamined.
• Should house rules carry a provenance field recording whether each is RDCO-authored or borrowed from a named external source, so a rule's authority can be re-audited without re-reading the brief that imported it? Two consecutive briefs have now been spent re-deriving where a rule came from.
• D-3's third clause was recommended and then silently not implemented. Was that a deliberate authoring judgment or a drop? Worth a sweep of D-1 through D-4 to see whether other decision-memo recommendations are partially implemented, since the memo is being treated as settled.
• DEFER.L3_EMERGENCE reopens this question in a different venue. Once client-specific L3 nodes emerge under motions, sibling heterogeneity at L3 becomes real and it will be on a client map rather than the universal tree. The scope argument here covers the platform artifact; it has not been tested against a client instantiation with genuinely uneven depth.

Related

• [[2026-08-22-bizbok-object-focus-invariance-real-estate]]
• [[2026-08-17-bizbok-operating-model-function-motion-mapping]]
• [[2026-08-17-apqc-pcf-function-motion-mapping]]
• [[industry-process-reference-models]]
• [[2026-08-21-apqc-pcf-80-channel-motion-leaves]]

Sources

Vault

• [[2026-08-22-bizbok-object-focus-invariance-real-estate]] — parent brief; the scope test this one extends, and the source of the ring-fence on CORE_PRODUCTION
• [[2026-08-17-bizbok-operating-model-function-motion-mapping]] — grandparent; imported both invariants and raised the abstract-slot flag
• [[2026-08-17-apqc-pcf-function-motion-mapping]] — dual-identifier scheme, cited for the cost arithmetic
• [[industry-process-reference-models]] — round-level concept article covering the framework survey
• [[2026-08-21-apqc-pcf-80-channel-motion-leaves]] — verification precedent for reading a primary against an imported claim

Primary artifacts read (Organizational Intelligence repo, phdata-projects)

• organizational-platform/03-motions/fn-operations-core-production.md (frontmatter and full body)
• organizational-platform/02-functions/fn-operations.md
• organizational-platform/03-motions/fn-operations-real-estate.md, fn-it-security.md (the two live declared exceptions)
• spec/00-template-decisions.md (D-3), spec/templates/org-platform-pages.md (declared-exception scope line, object-test template line)
• spec/schemas/function-rules.yaml (PRINCIPLE.CORE_PRODUCTION_ABSTRACT, DEFER.L3_EMERGENCE)
• tools/ — searched for declared_exception consumers; none found

Web

• Business Architecture Guild, Business Architecture Metamodel Guide v3.0, September 2024 — https://cdn.ymaws.com/www.businessarchitectureguild.org/resource/resmgr/whitepapers/business_architecture_metamo.pdf (primary; downloaded and text-extracted in full; §5.2 capability instance, §5.4 organization mapping, Figure 18 exemplar org map, §6.3 the homogeneity sentence)
• Biz Arch Mastery, "What's In A Word: How to Create a Capability Map That Unlocks New Value" — https://bizarchmastery.com/straighttalk/whats-word-how-create-capability-map-unlocks-new-value (secondary; level-consistency advice, capability-scoped)
• Biz Arch Mastery, "Demystifying An Organization: The Business Architecture Take on Organization Mapping" — https://bizarchmastery.com/straighttalk/demystifying-organization-business-architecture-take-organization-mapping (secondary; organization-map decomposition)

Not accessed

• The BIZBOK Guide capability chapter remains behind Business Architecture Guild membership. It was not accessed and no claim above rests on it. The free metamodel guide carries the homogeneity sentence in full, so the paywall did not block this question.