Skip to content

Chapter 35: Zachman Coevolution with ice_ext

New in v1.4.1. The Zachman 6×6 enterprise-architecture framework has quietly been shaping one of FCC's JV partners — ice_ext (codename POLARIS) — since its v0.6.0.dev0 release. ice_ext introduced a Zachman cross-cut over its Model Management Service, explicit three-layer doc labelling, and a SAFe↔FCC reconciliation table. FCC v1.4.1 absorbs those patterns as canonical framework primitives, so every project in the ecosystem can use them without depending on ice_ext at runtime. This chapter is the story of that coevolution and the mechanics of the absorption.

Why Zachman now

Zachman is fifty years old. It pre-dates agent frameworks, cloud computing, and SAFe. Why is FCC absorbing it in 2026?

Because the ecosystem reached a scale where it was rediscovered organically. When ice_ext's architects sat down to organise the Model Management Service patent (US20250272473A1) across the repo's documentation, they reached for a framework that could hold "what" (data), "how" (function), "where" (network), "who" (people), "when" (time), and "why" (motivation) all in one grid. Zachman is that framework.

FCC absorbs the pattern under the Pattern Harvester principle: when a JV partner discovers a reusable abstraction, the framework authority adopts it rather than leaves every downstream project to reinvent it. The abstraction becomes canonical; the JV partner stops carrying it privately and starts consuming it from the framework.

The Zachman 6×6 matrix

For readers unfamiliar with Zachman, the canonical view is a 6×6 grid. Rows are perspectives (planner, owner, designer, builder, subcontractor, functioning enterprise). Columns are interrogatives (what, how, where, who, when, why).

flowchart TB
    subgraph Matrix["Zachman 6x6 (perspective x interrogative)"]
        direction LR
        subgraph RowA[" "]
            A1[Planner<br/>Scope]
            A2[Owner<br/>Business model]
            A3[Designer<br/>System model]
            A4[Builder<br/>Tech model]
            A5[Subcontractor<br/>Components]
            A6[Functioning<br/>Running system]
        end
    end

    Matrix --> Col["6 interrogatives:<br/>What / How / Where /<br/>Who / When / Why"]

    Col --> FCC["FCC personas classified<br/>by Zachman cell"]
    FCC --> ZCA[ZCA persona<br/>owns the classifier]
    FCC --> Span["zachman_cell span attribute<br/>(Chapter 32)"]
    FCC --> Evidence["Evidence graph cross-cut"]

    classDef matrix fill:#fff9c4,stroke:#f57f17,stroke-width:2px;
    classDef result fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px;
    class Matrix,Col matrix;
    class FCC,ZCA,Span,Evidence result;

Every FCC persona is assigned to exactly one cell. The assignments are stored in src/fcc/data/personas/zachman_classifications.yaml and reviewed per PI by the ZCA persona.

The ZCA persona

ZCA — Zachman Classifier Agent (category knowledge_engineering). This is the canonical 6×6 classifier and is upstream-owned by FCC. Its responsibilities:

  • Classify every new persona into a Zachman cell at persona-spec creation time.
  • Review existing classifications per PI for drift or misassignment.
  • Emit the zachman_cell attribute on every span the persona's actions produce (the zachman_cell is a static persona attribute, not a runtime inference — see Chapter 32).
  • Expose a read-only API at fcc.zachman.classify(persona_id) that downstream tooling (ice_ext, constellations, plugins) can consume.

The ZCA's constitution is tiered hard-stop: a persona without a Zachman cell cannot pass the v1.4.1+ fcc audit personas --strict gate.

The three-layer doc convention

Alongside Zachman, v1.4.1 adopts the three-layer doc convention from ice_ext. Every doc-as-code artefact in the ecosystem is now labelled with its layer:

  • Layer 1 — ROADMAP. The long-horizon "why are we doing this?" layer. Portfolio epics sit here (Chapter 31).
  • Layer 2 — SAR (Strategic Architecture Review). The mid-horizon "how are we structuring this?" layer. Program epics sit here.
  • Layer 3 — AGENTS. The short-horizon "who is doing what?" layer. Feature-level deliverables and per-PR context sit here.

The convention is enforced by the TLDR (Three-Layer Doc Reconciler) persona, new in v1.4.1 and owned under docs_as_code. TLDR audits every doc file for a layer label and for layer-consistency — e.g. a ROADMAP file that describes sprint-level tasks is flagged for rewrite.

The label lives in the YAML frontmatter:

---
title: "..."
layer: 2  # 1 = ROADMAP, 2 = SAR, 3 = AGENTS
---

Layer 2 is the default if no layer is declared — most docs are SAR-tier.

The SAFe ↔ FCC reconciliation table

The ice_ext team also shipped an explicit reconciliation table between SAFe vocabulary and FCC vocabulary. FCC v1.4.1 adopts this table as authoritative; it lives at docs/safe/safe-fcc-vocabulary.md.

The table in summary (full version in the SAFe doc):

SAFe Zachman cell affinity FCC layer FCC artefact
Portfolio Epic Planner × Why Layer 1 ROADMAP section
Program Epic Owner × Why Layer 2 SAR section
Capability Designer × How Layer 2 MkDocs nav section
Feature Builder × How Layer 3 Merged PR
Enabler Story Builder × What Layer 3 Tech-debt ticket
Iteration Builder × When Layer 3 Sprint
PI Owner × When Layer 2 Program Increment
I&A Owner × Why Layer 2 Retrospective

The table is the bridge: SAFe vocabulary for cadence, Zachman classification for cross-cut, and FCC layer for authoring context. All three compose without collision.

The pattern-absorption proposal template

To keep future absorption principled, v1.4.1 introduces a new issue template at .github/ISSUE_TEMPLATE/pattern-absorption-proposal.md. A downstream project proposing that the framework absorb a pattern fills out:

  • Pattern name and origin repo.
  • What problem it solves at the downstream.
  • Why it should be canonical (not just reusable).
  • Costs of absorption — who owns it, what breaks.
  • Costs of non-absorption — what is duplicated, how much drift results.
  • Proposed absorption vehicle — new persona, new gate, new module, new convention.

The PHV (Pattern Harvester) persona, new in v1.4.1 and owned under docs_as_code, reviews these proposals. PHV mines not just explicit proposals but also latent patterns — it walks the sibling repos quarterly looking for abstractions that are getting reinvented in multiple places and should be proposed for absorption.

Coevolution timeline

The ice_ext → FCC coevolution has a tangible timeline worth recording for posterity.

timeline
    title FCC and ice_ext coevolution
    section 2026 Q1
        FCC v1.3.5   : ecosystem registry vendored from RC
        ice_ext v0.5 : Model Management Service prototype
    section 2026 Q2 early
        FCC v1.3.9   : docs/patent/ tree, IP Evaluation Analyst
        ice_ext v0.6 : Zachman cross-cut introduced<br/>3-layer doc labels<br/>SAFe reconciliation table<br/>SHA-256 vocab drift CI
    section 2026 Q2 mid
        FCC v1.4.0   : 10 constellations public
        ice_ext v0.6.0.dev0 : STATUS.md lists<br/>"Open items for FCC"
    section 2026 Q2 late
        FCC v1.4.1   : Zachman + 3-layer + SAFe + SHA drift<br/>all absorbed as canonical<br/>ZCA, PHV, TLDR, SMC, SFBI, VDS<br/>personas added
    section 2026 Q3 projected
        FCC v1.4.2-4 : dual-bus, patent delegation,<br/>industry paper pipeline

Lessons from coevolution

Four lessons from the ice_ext → FCC coevolution that inform future JV-partner relationships:

  1. Framework authority is not framework origination. A well-run ecosystem has JV partners that ship primitives the framework hasn't yet imagined. The framework's job is to notice and absorb, not to gatekeep.
  2. Pioneering patterns should live locally first. Zachman and 3-layer docs both sat in ice_ext for a minor release before FCC absorbed them. That bake-time was the gap between "this works in our context" and "this is canonical for the ecosystem."
  3. Absorption is not imitation. FCC did not copy ice_ext's Zachman YAML verbatim; it re-expressed the same classification in a structure that suited FCC's persona registry. The abstraction is the same, the encoding adapts.
  4. Document the coevolution. The timeline above and the pattern-absorption issue template exist specifically so the next absorption doesn't have to be re-argued from scratch. Process memory is a deliverable.

What stays with ice_ext

Important counter-point: not everything in ice_ext gets absorbed. The implementation of the Model Management Service remains with ice_ext — both because US20250272473A1 anchors it there and because MMS is an application of the framework, not a framework primitive itself. FCC absorbs the cross-cut; ice_ext keeps the MMS.

Similarly, lyra_ext (codename LYRA, projected future JV partner for graph-of-thought and harmonic memory) is expected to pioneer primitives that FCC will absorb in v1.5.x — but LYRA's specific graph-of-thought implementation will stay with LYRA.

How auditors see this

The Zachman cross-cut adds a new evidence dimension to the audit walk (Chapter 30). Every persona now has a Zachman cell; every OTel span carries a zachman_cell attribute; the evidence graph grows a new edge type (classified_as) linking personas to cells. An auditor can now ask "which personas satisfy Article 10 of EU AI Act in the Data / Owner cell?" and get a focused answer instead of a full-matrix readout.

Key takeaways

  • FCC v1.4.1 absorbs four patterns from ice_ext v0.6.0.dev0: the Zachman 6×6 cross-cut, the three-layer doc convention, the SAFe↔FCC reconciliation table, and the SHA-256 vocabulary drift CI pattern.
  • Six new personas support the absorption: ZCA, TLDR, PHV, SMC, SFBI, and VDS.
  • Every FCC persona is now classified into a Zachman cell; every OTel span carries a zachman_cell attribute.
  • The pattern-absorption proposal template institutionalises future absorption.
  • Coevolution is explicit: ice_ext pioneers, FCC absorbs, ice_ext consumes from upstream. The model is designed for lyra_ext and future JV partners.