#Architecture-Bearing Family Characteristic Starter Packs

C.32.HCS · Cluster C.IV - Composite & Macro-Scale · Stable · Architectural characterization subpattern under C.32 · Normative unless explicitly marked informative · Part C - Kernel Extension Specifications

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Type: Architectural characterization subpattern under C.32 Status: Draft Normativity: Normative unless explicitly marked informative

Use this pattern when a practitioner must begin architecture-characteristic narrowing for a described holon, or for adjacent method-side, role-side, work-side, evidence-side, or cultural-evolution material after the governing pattern has been recovered, and the available source catalogues are too broad to choose the first project criteria rows.

#Keywords

• architecture-bearing family characteristic starter pack
• architecture characteristic heads
• source catalogue narrowing
• first criteria questions
• characteristic transfer.

#Relations

#Content

#Problem frame

Use this pattern when a practitioner must begin architecture-characteristic narrowing for a described holon, or for adjacent method-side, role-side, work-side, evidence-side, or cultural-evolution material after the governing pattern has been recovered, and the available source catalogues are too broad to choose the first project criteria rows.

Primary working reader: an architect or architecture-responsible practitioner choosing a small first set of architecture-characteristic heads for an admitted holon family, or for a recovered architecture-bearing family whose described holon, source-bearing episteme or publication context, and governing pattern are already named.

Typical entry phrases:

"The source catalogue has hundreds of quality names; which few heads should we inspect first?"
"The source calls this a review practice or method; what described holon, method-side structure, work family, and role-side structure are actually under pressure?"
"A role assignment, organization, built asset, or evidence workflow has reliability-like pressure, but the bearer and scale are unclear."

First-minute use slice. A review lead sees a long quality catalogue and a software-oriented checklist, while the source wording calls the object a reusable review practice. Using C.32.HCS, the practitioner first restores the source label: the live holon is the review organization-as-system or bounded review-work context; the adjacent governed structures include a method relation structure, method descriptions, role assignments for role-holding systems, work-product structures, and evidence records. Only then does the practitioner inspect repeatability, transferability, evidence reuse, exception growth, and role-assignment substitutability, record teachability as a likely C.25 Q-Bundle, and carry only those starter heads and first project questions to [C.32.ACS](/generated/patterns/C.32.ACS). The project starts from a small recovered architecture-bearing set instead of copying hundreds of names or admitting "practice" as a holon kind.

The primary EntityOfConcern is one architecture-bearing family starter pack for beginning to turn broad architecture-characteristic names into project criteria rows. A starter head is only a possible characteristic head before project bearer, scale, use class, proxy risk, and protected counter-characteristics are bound. HCS hands starter heads to ACS; Q-Bundles, measurements, eval programs, candidate palettes, comparison rules, G.5 publications, and architecture decisions stay with their receiving patterns.

Ordinary working move: choose the starter pack for the admitted holon family or recovered architecture-bearing family, keep only the heads that plausibly fit the project, ask the first project question for each head, then hand those heads to [C.32.ACS](/generated/patterns/C.32.ACS) for bearer, scale, and use-class binding.

The first useful output is an ArchitectureBearingFamilyCharacteristicStarterPack@FPF. It is a working starter record under C.32.HCS: it suggests heads and first questions for one admitted holon family or one recovered architecture-bearing family. It does not introduce a new U.* kind and does not by itself create project criteria, scale rows, Q-Bundles, measurement methods, eval programs, or a universal holon ontology:

ArchitectureBearingFamilyCharacteristicStarterPack@FPF:
  architectureBearingFamilyRef:
  describedHolonOrCarrierContextRef?:
  governingRecoveryPatternRefs?:
  typicalSelectedStructureRefs:
  starterCharacteristicHeads:
    - architectureCharacteristicHead:
      usualBearerOrSelectedStructureRefs:
      likelyQBundleBoundary?:
      firstProjectQuestion:
      usualReceivingPatternRef:
  nonUniversalCaution:
  criteriaRowPatternRef: C.32.ACS

What goes wrong if C.32.HCS is missed: the team faces hundreds of -ility or quality names, copies a catalogue, or starts from a software-module list even when the source object is called a method, role, culture, practice, built asset, or evidence workflow and still needs owner recovery.

What C.32.HCS buys in practice: the practitioner has a short architecture-bearing starting point before [C.32.ACS](/generated/patterns/C.32.ACS) turns starter heads into project criteria rows, three to five optimization indicators, and monitored guardrails.

Adoption test: after using C.32.HCS, the project has a short starter set and first project questions; it has not copied a catalogue and has not yet claimed bearer, scale, use class, or optimization status.

Not this pattern when the project already has admitted architecture-characteristic rows with bearers, scales, and use classes. Also not this pattern when the current work is composite-quality modeling, measurement, eval design, candidate synthesis, comparison, publication of a selected set, local choice, or project architecture decision.

Common exits by claim kind:

• [C.32.ACS](/generated/patterns/C.32.ACS) for project criteria rows.
• [C.25](/generated/patterns/C.25) for Q-Bundles and composite quality families.
• [C.16](/generated/patterns/C.16) for measurement and [C.32.ACE](/generated/patterns/C.32.ACE) for eval programs or eval results.
• [E.13](/generated/patterns/E.13) when a source-looking cue, score, benchmark, or dashboard starts replacing the architecture concern.
• [C.32](/generated/patterns/C.32) for candidate synthesis after project criteria rows exist.
• [A.19.CPM](/generated/patterns/A.19.CPM) for explicit comparison and [A.19.SelectorMechanism](/generated/patterns/A.19.SelectorMechanism) for set-returning selection.
• [G.5](/generated/patterns/G.5) for publication of a selected set, [C.11](/generated/patterns/C.11) for local choice, and [C.32.PAD](/generated/patterns/C.32.PAD) for project decision.

#Problem

Architecture characteristics recur more than functions do. Reliability, substitutability, change reach, evidence reuse, control separation, or coordination load can appear across admitted holons and across adjacent governed method-side, role-side, work-side, evidence-side, and cultural-evolution structures. The recurrence does not mean that the bearer, scale, governing pattern, or use is identical, and it does not make U.Method, U.Role, practice, or culture an admitted holon kind.

Functions and functional demands depend on the bearer and owner. A saw-as-system can cut, a system holding a role assignment can carry responsibility, a method description can guide work, an enacted work family can be repeatable, an organization-as-system can coordinate, and a culture or practice label must be restored into systems, disciplines, method and work families, role assignments, canon or memory epistemes, recognition and selection regimes, and mediation systems before architecture-characteristic reuse. A project therefore needs starter packs that suggest common architecture-characteristic heads while forcing owner, bearer, and scale rebinding before optimization.

#Forces

#Solution

Choose a starter pack by the described holon's declared family. Use the pack only to start narrowing starter heads into project criteria rows; then hand the result to C.32.ACS for the project criteria set.

#Starter pack construction

Build or use a starter pack in this order:

1. Name the admitted holon family. If the source label is method, role, practice, culture, tradition, style, or evidence practice, first name the described holon, or name the source-bearing episteme or publication context when the label is only a description-side family, and then name the governing patterns that recover the label.
2. List a small set of starter characteristic heads that often matter for that family.
3. For each head, name likely bearers or selected structures, not only a quality word.
4. Record likely C.25 Q-Bundle boundaries when a head is usually composite.
5. State a first project question that helps the practitioner decide whether the head belongs as a draft row in the project criteria set.
6. Hand the resulting starter heads to C.32.ACS; do not optimize or measure inside HCS.

#Built-in starter packs

In HCS, source-return cost is a starter head only when a holon family repeatedly pays effort, latency, or risk to move from a derivative, coarsened, extracted, rendered, or reused publication or evidence carrier back to the named source expression, source U.EpistemePublication, source-bearing relation, evidence-provenance entry, evidence relation, transform record, or direct governing-pattern handoff needed before stronger reliance. It is not a generic source-quality name. If the project is only asking whether a catalogue term is useful, keep the wording as source catalogue wording; if recoverability itself is the concern, carry source-return cost to C.32.ACS.

#Rebinding rule

When a starter head is reused at another admitted holon family, declared holon level, or recovered architecture-bearing family, rebind it. The reusable item is the head, not the row.

Example: availability for an engineered service may use time-window and service-scope measures. A method-family analogue may concern whether a method step and evidence relation are available to a role in the work situation. A role-family analogue may concern substitutable responsibility coverage. These are different bearers and scales.

Refresh the starter pack when its starting assumptions no longer hold: the admitted holon family changes, source-label recovery changes the governing-pattern selection, a B.2 whole reidentification changes the bearer or scale, a source catalogue changes the available vocabulary, repeated ACS project-row uses show that a head never survives project binding, or repeated ACS project-row uses reveal a missing head for that family. Refresh only starter-pack fields and blocked overreads. Existing project criteria rows remain with C.32.ACS; measurements remain with C.16; eval programs remain with C.32.ACE.

#ACS Criteria-Row Use

HCS stops with starter heads and first project questions. The next C.32.ACS use governs:

• whether C.32.ACS admits the head as a draft project criteria row;
• whether it is one characteristic or a C.25 Q-Bundle;
• whether the project uses it as an optimization indicator, monitored guardrail, or context-only row;
• which scale, reading, and receiving pattern apply.

Before ACS criteria-row use, ask one proxy-resistance question for each carried starter head: what architecture concern would worsen or disappear if the visible catalogue entry, domain term, benchmark row, or dashboard value looked better? Such visible catalogue, benchmark, dashboard, or publication material is not yet an architecture-characteristic starter head. Carry it forward only when the holon family, likely bearer, likely scale, Q-Bundle boundary, first project question, source catalogue entry, source U.EpistemePublication ref, benchmark row, dashboard row, publication row, source-to-use path from that catalogue, benchmark, dashboard, or publication row, and reopen condition for stronger use remain recoverable. If no worsening or lost concern can be named, keep the wording as source catalogue wording or remove it from the starter pack.

Stop condition. Stop C.32.HCS when the starter pack names the described holon family, starter heads, likely bearers or selected structures, likely composite-quality boundaries, first ACS questions, and any blocked overread. The next project criteria-row work belongs to C.32.ACS.

Lowering condition. Lower a starter head to source catalogue wording or remove it from the starter pack when the holon family is not declared, the likely bearer or likely scale is missing, the composite-quality boundary is still unresolved, the first ACS question is absent, repeated ACS uses reject the head for that holon family, or the item is being used to smuggle measurement, eval, comparison, publication, local choice, or decision work into HCS. Use C.25 when the head is composite, C.32.ACS when the project criteria-row question is ready, and the named receiving pattern when the stronger claim is current.

#Worked slices

Engineered-system family. A field-device project starts from reliability, maintainability, substitutability, evidence reuse, locality, and source-return cost. C.32.ACS later marks only maintainability, substitutability, and evidence reuse as optimization indicators; safety and availability remain guardrails.

Method-side family. A source calls a reusable review method "the practice." HCS restores the described review organization-as-system or bounded review-work context, then treats method relation structure, method descriptions, work products, role assignments, and evidence records as adjacent governed structures. The starter heads are repeatability of enactment, transferability, evidence reuse, exception growth, and role-assignment substitutability. Teachability belongs to C.25 because it combines learner scope, measures, mechanisms, and evidence.

AI-agent workflow. A retrieval-action setup starts from evidence refresh, policy controllability, latency, observability, and rollback. Benchmark performance stays a benchmark signal or comparison input until an architecture bearer and scale row are named.

Starter-pack proxy near-miss. A review team copies availability, throughput, and testability from a software quality catalogue because the list looks mature. The copied heads make the starter pack look complete, but they hide exception growth, evidence reuse, and role-assignment substitutability, which are the architecture concerns that will later govern review work. C.32.HCS keeps the catalogue terms as source catalogue wording, restores the method-side and role-side governing patterns, and carries only rebound questions to C.32.ACS.

#Receiving-Claim Boundary

C.32.HCS governs architecture-bearing family starter packs. It does not govern project scale rows, Q-Bundles, measurements, eval programs, candidate synthesis, comparison, selection, publication of a selected set, local choices, or project architecture decisions. It also does not admit U.Method, U.Role, practice, culture, tradition, or style as holon kinds. Use C.32.ACS, C.25, C.16, C.32.ACE, C.32, A.19.CPM, A.19.SelectorMechanism, G.5, C.11, or C.32.PAD when those claims are being made.

#Conformance checklist

#Common failures and repairs

#Consequences

#Rationale

The 300-to-3 problem needs a middle step. A project cannot optimize from a catalogue, but it also should not invent criteria from scratch. Architecture-bearing starter packs give a small, recognizable entry while project criteria-row construction, measurement, eval, comparison, selection, publication of a selected set, local choice, and project architecture decision work stays with its receiving pattern.

#SoTA-Echoing

These rows document transfers from source practice into C.32.HCS. Keep a source name only when the draft uses it to set or revise a starter-pack field, an ACS criteria-use condition, or a blocked overread.

Source-currentness boundary. Use ISO/IEC 25010:2023 as ICT product-quality vocabulary, not as holon-family ontology. Use the O'Reilly architecture-characteristic and evolutionary-architecture sources for recurring starter heads and for later metric or eval work after the heads are named. Use an FPF row only for the claim governed by the named receiving pattern. Reopen HCS when a named source edition changes starter-head guidance, when a receiving pattern changes how it handles that source family, when repeated C.32.ACS uses show that a starter head never survives project binding, when repeated project uses reveal a missing head for the admitted holon family or recovered architecture-bearing family, or when governing-pattern recovery for source labels changes.

#Relations

• Receiving use: C.32.ACS project criteria-set construction, including scale rows and use classes when the project later needs them; C.32.P2S when starter heads are needed before the architecturing flow can bind project criteria, candidate synthesis, eval, and refresh.
• Uses: C.25 when a starter head is composite; C.30 and C.30.ASV when the selected structures are not yet recoverable.
• Boundary: HCS is not a catalogue, measurement pattern, Q-Bundle pattern, optimization method, or architecture decision pattern.

#Footer marker

C.32.HCS closes when the practitioner can name an architecture-bearing starter pack, any needed described holon, source-bearing episteme or publication context, governing pattern refs, starter architecture-characteristic heads, likely bearers, likely Q-Bundle boundaries, and first project questions for C.32.ACS.

#C.32.HCS:End

Last Updated: 2026-07-08 — this section last modified in upstream FPF commit c927fef1 (github.com/ailev/FPF)