06-reference/research

bizbok object focus invariance real estate

2026-08-22·research-brief·source: deep-research·by Ray Data Co (deep-research synthesis)
business-architecturebizbokorganizational-platformschema-designtaxonomy

The object-focus rule is real, absolute, and aimed at a different artifact than ours

The question

Verbatim: "Is there a sanctioned BIZBOK pattern for a capability decomposition that legitimately changes object focus, and does FN.OPERATIONS.REAL_ESTATE qualify as a recorded exception or is it a modelling error?"

Context: [[2026-08-17-bizbok-operating-model-function-motion-mapping]] named object-focus invariance the single most borrowable thing it found, applied it to the live Organizational Platform tree, and flagged FN.OPERATIONS.REAL_ESTATE as the tree's weakest node. That node was added by founder ruling on 2026-08-08 to close a real coverage gap, so the flag is a question about a deliberate decision, not an oversight.

What we already know (from the vault)

What the web says

Primary source is the Business Architecture Guild's Business Architecture Metamodel Guide v3.0 (September 2024), a free public whitepaper. I fetched and extracted it in full rather than relying on secondary summaries. The BIZBOK Guide's capability chapter itself remains member-gated and I did not access it; nothing below rests on it.

Convergences and contradictions

Synthesis for RDCO

Verdict: FN.OPERATIONS.REAL_ESTATE is neither a recorded exception nor a modelling error. It is a correct node judged by a mis-scoped test. BIZBOK's object-focus invariance rule governs capability decomposition, where capabilities are defined by their derivation from value streams and constrained to one set per ecosystem. Our function/motion tree is not that artifact, on our own prior analysis and on the metamodel's own definitional test. For the artifact we actually built, BIZBOK's stated discipline is one sentence long: organization mapping is not constrained to a specific format. There is nothing for REAL_ESTATE to be an exception to. The recommendation is therefore keep the node, and retire the exception framing rather than keep either the node-under-caveat or a re-parenting plan.

This is not a reversal of the founder's 2026-08-08 ruling. It confirms it, and it removes the caveat the ruling was carrying. That matters because a declared_exception: note is not free: it is a standing admission of a defect, published on a page a client or a reviewing architect will read, asserting a violation of a rule that does not apply. The honest version of that note is smaller and stronger. My recommendation for the frontmatter on both flagged nodes is to replace declared_exception with a scope note that says the object test is an internal RDCO admission heuristic borrowed from BIZBOK's capability domain, that BIZBOK imposes no object constraint on organization maps, and that these two motions are where the heuristic and the artifact diverge. Same transparency, accurate claim. The same correction applies to FN.IT.SECURITY, whose declared exception rests on identical reasoning and dissolves the same way. 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 one defect that survives is the MAINTENANCE / REAL_ESTATE overlap on the word "facilities," and BIZBOK hands us the instrument for it. Both motions claim facilities scope in their names, and both pages already narrate the seam in prose, with REAL_ESTATE describing handover and MAINTENANCE describing the building arriving "as a finished asset." The disambiguation is genuinely already there in the bodies; what is missing is that the names do not carry it. This is exactly the "functional redundancy" the metamodel says an organization-to-capability cross-map is for surfacing. The cheap fix is naming, not structure: rename MAINTENANCE toward asset care and REAL_ESTATE toward site development so the shared word disappears from both titles. That is a name: field change on two pages with no id movement and no re-parenting, and it is the piece the parent brief correctly said needs a founder read either way.

On id stability, the constraint the backlog entry worried about has largely already been dissolved, and it no longer forces the timing. The entry warned that re-parenting later breaks every client file citing FN.OPERATIONS.REAL_ESTATE. Since that was written, the dual-identifier scheme from [[2026-08-17-apqc-pcf-function-motion-mapping]] shipped: the node carries sid: OP-10032, the client function map already cites the sid with the old id demoted to a comment, and build_registry.py sidifies node refs on emit so downstream generated artifacts are sid-keyed. What still holds positional ids is authored source, principally four catalog_motion and anchor references in the client roles file plus prose links across the platform pages. So the three options price out as: keep (recommended) costs nothing and requires two frontmatter edits plus an optional pair of renames; re-parent now costs roughly a dozen authored-file edits, which is small, but buys a fix for a problem this brief finds does not exist; re-parent later is no longer materially more expensive than re-parenting now, which is precisely why there is no deadline pressure to decide against the evidence. If the tree ever does re-parent a motion for a real reason, the dual-identifier work means the blast radius is authored prose, not generated data.

Why this is in the vault

This closes the open follow-up that spec/00-template-decisions.md explicitly queued as a gate: it decided to add declared_exception: notes and wait for this brief before touching the tree. The answer unblocks two concrete edits to the Organizational Platform content template ahead of the hand-section lock, and removes a published self-flagged defect from two motion pages before client YAMLs and the client-facing organizational map cite them.

Open follow-ups

Related

Sources

Vault

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

Web