#Architecture Characteristic Eval Programs

C.32.ACE · Cluster C.IV - Composite & Macro-Scale · Stable · Architecture eval-support 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: Architecture eval-support subpattern under C.32 Status: Stable Normativity: Normative unless explicitly marked informative

Use this pattern when an architecture team already has project architecture-characteristic rows and must evaluate the current architecture, compare candidate architectures, monitor evolution, or prepare a selection input.

#Keywords

• architecture-characteristic eval program
• eval result
• measurement boundary
• parity frame
• missing-data policy
• proxy risk
• comparison input.

#Relations

#Content

#Problem frame

Use this pattern when an architecture team already has project architecture-characteristic rows and must evaluate the current architecture, compare candidate architectures, monitor evolution, or prepare a selection input.

Primary working reader: an architect or evaluator preparing readings over declared architecture-characteristic criteria without turning those readings into the criteria or the decision.

Typical entry phrases:

"We have criteria rows; which eval reading shows how candidate A and candidate B compare under the same parity frame?"
"The monitor is useful, but is this a reading, a test failure, or a decision input?"
"Two methods, roles, system variants, or AI workflows need fair comparison against the same architecture characteristics."

First-minute use slice. A product-family team has ACS rows for substitutability, evidence reuse, and latency, plus safety as a monitored guardrail. Two candidate architectures look plausible. The practitioner writes one ACE program record with the same claim scope, selected context slices, reference scheme and plane, evaluation window, parity frame, and input projections for both candidates. EvalService-7, the admitted System holding EvaluatorAssignment-3, separately performs dated CandidateEvalWork-42 over both candidates under that assignment; its exact Method enactment or operation application is separately governed. CandidateLatencyReading-42 and CandidateEvidenceScopeFinding-42 are separately governed typed results, and any observed protected-safety loss remains explicit rather than being absorbed into one score. Those results can become inputs for [A.19.CPM](/generated/patterns/A.19.CPM) comparison or the next C.32 synthesis pass; neither the program record, Work, nor a result defines the criterion or decides the architecture.

The primary governed object is one architecture-characteristic eval-program record over declared criteria rows, Q-Bundle slots, candidates, bearers, or selected structures under a parity frame. It is a C.32.ACE-local record form, not a new U.* kind and not, by its program label, a U.Method, U.MethodDescription, U.WorkPlan, dated U.Work, or evaluation result. Measurement validity, comparison policy, selection results, G.5 publications, and architecture decisions remain with their receiving patterns.

Ordinary working move: choose the declared criteria rows, bind the exact claim scope, relevant context slices, reference scheme and plane, evaluation window, and input projections, and hold one parity frame for all variants. When evaluation actually occurs, identify the admitted System and role assignment performing the dated Work plus any exact Method enactment or operation application, then return the separately governed typed results as feedback for comparison or the next synthesis pass.

The first useful output is an ArchitectureCharacteristicEvalProgram@Project. This C.32.ACE-local working record states how one bounded architecture evaluation is to be framed over declared criteria. When a reusable way of evaluating is current, identify that separate U.Method under A.3.1; when a claim-bearing episteme describes that exact Method, test the same episteme for U.MethodDescription under A.3.2. A planned evaluation belongs to A.15.2, an actual dated evaluation to A.15.1, and each result to its direct measurement, comparison, evaluation, or assertion owner. The record reads characteristics through rows, slots, candidates, or structures; it is not any of those neighboring objects:

For a first pass, fill the exact claim scope and selected context slices, reference scheme and plane, evaluation window and input projections, evaluated rows or Q-Bundle slots, evaluated candidates or structures, parity frame, eval purpose, intended eval operation, result form, receiving use, and refresh or retire condition. Add project-use refs only for a claimed project-local program; add Method, MethodDescription, actual evaluation Work, operation-application, and typed-result refs only when those separate objects are current.

ArchitectureCharacteristicEvalProgram@Project:
  projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work
  architectureEvalProgramProjectUseRelationRef?: U.RelationRef governed by the exact eval-program-use or work-use pattern
  claimScopeRef: U.EntityRef referencing one U.ClaimScope
  selectedContextSliceRefs:
  effectiveReferenceScheme:
  referencePlane?:
  evaluationWindow:
  inputProjectionRefs:
  evaluatedCriteriaSetRef:
  evaluatedCriteriaRowRefs:
  evaluatedQBundleSlotRefs?:
  evaluatedCandidateRefs?:
  evaluatedBearerOrSelectedStructureRefs:
  evalPurpose: characterizeCurrentArchitecture | compareCandidates | monitorEvolution | prepareSelection | triggerNextSynthesis
  evalQuestion:
  parityFrameRef:
  evalScope: singleCriterion | coupledCriteria | qBundleSlice | variantPortfolio | holisticUseSlice
  evalOperation: measurement | simulation | benchmark | scenarioWalkthrough | test | monitor | expertReview | evidenceAudit
  triggerMode: onePass | batchComparison | continual | onChange | manualOnDemand
  resultForm: reading | band | rank | dominanceRelation | tradeoffFront | qualitativeState | evidenceFinding
  runContext: designTime | laboratory | pipeline | production | workReview | decisionPrep
  measurementOrObservationMethodRefs:
  methodDescriptionRefs?:
  evaluationWorkOccurrenceRefs?: U.EntityRef constrained to U.Work
  evaluationOperationApplicationRefs?: direct-owner relation or A.6.1 application references
  evaluationResultRefs?: typed result references governed by the selected direct owner
  uncertaintyAndMissingDataPolicy:
  proxyRisk:
  protectedCounterCharacteristicRefs:
  comparisonPolicyRef?:
  receivingUseRef:
  refreshOrRetireCondition:

Here @Project is a compatibility and retrieval cue only. It supplies no project entity, composite-work identity, context, authority, viewpoint, or parthood. A program local to one actual project names both the exact composite U.Work in projectWorkOccurrenceRef and the obtaining direct program-use relation in architectureEvalProgramProjectUseRelationRef; either field alone is insufficient. evalOperation states the intended operation family in the program record, not an actual run or application. Each value in evaluationWorkOccurrenceRefs denotes a separate dated U.Work; its admitted performer System, exact U.RoleAssignment, F.6 attribution, any enacted Method or actual direct-owner/A.6.1 application binding, and each typed result remain under their direct owners. A program, Method, MethodDescription, Work occurrence, operation application, and result never substitute for one another.

What goes wrong if C.32.ACE is missed: a project has architecture-characteristic rows but treats a test, monitor, dashboard, or source-side "fitness function" as the criterion or as the decision. The team may then reject useful losing variants as errors, optimize one indicator, or choose a candidate without fair comparison.

What C.32.ACE buys in practice: eval work is framed as typed evaluation over declared architecture criteria. A losing candidate can still add knowledge about the solution space, while an actual error remains a failure against an expectation that causes unplanned rework.

Adoption test: after using C.32.ACE, the record shows which variants were read under the same parity frame, what result form was produced, and which receiving pattern may use that reading as feedback.

Not this pattern when the characteristic rows do not exist yet. Also not this pattern when the current work is measurement validity, composite-quality modeling, explicit comparison, set-returning selection, local choice, publication of a selected set, evidence, assurance, or project architecture decision.

Common exits by claim kind:

• [C.32.HCS](/generated/patterns/C.32.HCS) and [C.32.ACS](/generated/patterns/C.32.ACS) before characteristic rows exist.
• [C.16](/generated/patterns/C.16) for measurement validity, readings, units, uncertainty, or comparability claims.
• [C.25](/generated/patterns/C.25) for Q-Bundles and composite quality families.
• [E.13](/generated/patterns/E.13) when an eval result or dashboard starts replacing the declared architecture concern.
• [C.32](/generated/patterns/C.32) for candidate synthesis, [C.32.MLAO](/generated/patterns/C.32.MLAO) for residual input, and [E.23](/generated/patterns/E.23) for repeated improvement feedback.
• [A.19.CPM](/generated/patterns/A.19.CPM) for explicit comparison, [A.19.SelectorMechanism](/generated/patterns/A.19.SelectorMechanism) for set-returning selection, [C.11](/generated/patterns/C.11) for local choice, and [G.5](/generated/patterns/G.5) for publication of a selected set.
• [A.10](/generated/patterns/A.10) and [B.3](/generated/patterns/B.3) when evidence or assurance claims are being made.
• [C.32.PAD](/generated/patterns/C.32.PAD) for project decision.

#Problem

Architecture synthesis is an optimization and learning activity under competing characteristics. It needs evals: deliberate measurement, simulation, benchmark, scenario, review, or monitoring runs that say how a current architecture or candidate architecture reads against declared criteria.

Testing for errors is a neighboring use. A test asks whether an expectation is violated. An eval asks how variants compare, how a candidate changes the trade-off front, which constraint is hit, or whether the next synthesis pass should open. A candidate that loses the eval is not automatically an error; it may be a deliberate probe that improves the architecture team's knowledge of the solution space.

Evolutionary-architecture sources often say "fitness function". In FPF that is source-side wording. The recoverable FPF object is an eval program over declared architecture-characteristic rows, Q-Bundle slots, candidate structures, and a parity frame. Some eval programs can be automated tests or monitors, but automation does not change the kind.

#Forces

#Solution

Create an architecture-characteristic eval program only after the evaluated criteria rows exist in C.32.ACS or a declared C.25 Q-Bundle slot.

Work in this order:

1. Reference the evaluated ACS criteria set, evaluated rows, and any Q-Bundle slots.
2. State the eval purpose: current characterization, candidate comparison, portfolio-frontier work, post-change impact measurement, monitoring, or trigger for the next synthesis pass.
3. Name the candidates, bearers, and selected structures being evaluated.
4. Establish one exact U.ClaimScope, the relevant A.2.6 U.ContextSlice membership, effective U.ReferenceScheme and reference plane, evaluation window, input projections, resource budget, units, admissible observation or evidence inputs, and missing-or-unknown policy. Record their parity requirement in parityFrameRef; the parity-frame record does not replace those bindings.
5. Choose eval scope: one criterion, coupled criteria, one Q-Bundle slice, a candidate portfolio, or a holistic use slice.
6. Choose eval operations. Use measurement, simulation, benchmark, scenario walkthrough, monitor, review, or evidence audit according to the claim. Use test only when the intended operation checks an expectation or hard constraint. When evaluation actually occurs, identify the dated U.Work, any enacted Method or actual direct-owner/A.6.1 application binding, and the typed result separately; the program record itself does not run.
7. Declare the result form: reading, band, rank, dominance relation, trade-off front, qualitative state, or evidence finding.
8. Name proxy risk and protected counter-characteristics before the eval result can drive work. Optimize only the cycle's chosen indicators; keep the remaining protected characteristics visible as guardrails or risk signals.
9. State the receiving use: C.32 synthesis input, C.32.MLAO residual input, E.23 improvement feedback, A.19.CPM comparison input, A.19.SelectorMechanism selection input, C.11 choice input, input for publishing a selected set under G.5, or architecture-decision input for C.32.PAD.
10. Refresh or retire the eval program when the evaluated row, C.32 candidate palette, bearer, selected structure, environment, parity frame, or source-currentness relation changes.

Stop condition. Stop C.32.ACE when the eval program names evaluated rows or Q-Bundle slots, evaluated candidates or structures, parity frame, eval purpose, eval operation, result form, receiving use, proxy risk, protected counter-characteristics, and refresh or retire condition.

Lowering condition. Keep the result as an eval result only while the evaluated rows, evaluated candidates or structures, parity frame, eval operation, result form, and receiving use still match the work being done. Lower the result to report-only when missing data, proxy risk, or parity-frame mismatch prevents synthesis, comparison, selection, publication of a selected set, choice, evidence, assurance, or decision use. Retire the eval program when its evaluated row, bearer, selected structure, environment, source-currentness relation, or receiving use no longer belongs to the current architecture work. Return to C.32.ACS when the criteria row is missing or wrong, to C.16 when measurement validity is current, to C.25 when the evaluated item is composite, and to the named receiving pattern when a stronger downstream claim is current.

#Worked slices

Latency candidate. A service candidate promises latency under 100 ms and an eval reads 240 ms. If the 100 ms band is a hard constraint, the candidate is inadmissible for this cycle. If the project is still exploring a trade-off front, the candidate is a losing variant with useful evidence about resource placement, interface burden, or control separation. Treat it as an error only when the project used that expectation to plan work and unplanned rework follows.

BIM digital twin. A built-asset team compares architecture candidates that combine placement, schedule, use-phase, maintenance, and cost structures. ACE does not treat the number of dimensions as the evaluation. The practitioner defines a parity frame and evals the ACS rows declared for the project, such as access, source-return cost, observability, and maintenance reach, then records results with the parity-frame and result-form fields needed by A.19.CPM.

Method-family architecture. A review-method family has ACS rows for evidence reuse, change reach, and role substitutability, plus a C.25 teachability bundle. ACE defines a batch eval over three method variants. One variant loses on teachability but reveals a reusable evidence relation; C.32 may use it as a stepping stone.

AI-agent workflow. A model-supported workflow has candidates with different function graphs and tool boundaries. ACE evaluates latency, evidence refresh, policy controllability, and rollback under the same task set and evidence window. A benchmark score is not the architecture decision; it supplies one eval reading inside the parity frame.

Role-team escalation. A hospital escalation team has ACS rows for decision latency, accountability clarity, evidence custody, and role continuity. ACE evaluates two role-boundary variants under the same incident scenarios and handoff evidence window. The result can feed comparison or the next synthesis pass; staffing choice remains with the receiving decision pattern.

#Kind and Receiving-Claim Boundary

C.32.ACE governs construction of the local architecture-characteristic eval-program record and the boundary among criterion, reusable evaluation Method, MethodDescription episteme, intended operation family, planned evaluation, actual dated evaluation Work, actual operation application, typed result, comparison input, selection input, and decision input. The local record admits no new U-kind. Use A.3.1, A.3.2, A.15.2, A.15.1, A.6.1, and the direct result owner when those neighboring claims are current. C.32.ACE does not govern starter characteristic selection, ACS scale-row construction, measurement validity, Q-Bundle normal form, candidate synthesis, comparison-policy design, final selection, local choice, publishing a selected set under G.5, or architecture decisions. Use C.32.HCS, C.32.ACS, C.16, C.25, C.32, A.19.CPM, A.19.SelectorMechanism, C.11, G.5, or C.32.PAD when those claims are being made.

#Conformance requirements

#Common failures and repairs

#Consequences

#Rationale

An architecture-characteristic eval program is the missing middle object between criteria rows and architecture selection. It answers "how did these candidates or structures read under this parity frame?" It does not answer "what is the criterion?", "is the measurement valid outside this use?", or "which architecture must be chosen?"

The pattern is architecture-specific because it evaluates selected structures and architecture characteristics. It stays holon-grounded because the same eval form can apply to admitted holons such as systems, organizations-as-systems, built assets, epistemes, work occurrences, disciplines, AI-agent setups, and C.36-recovered cultural-evolution cases. It can also evaluate method-side, role-side, work-side, or evidence-side structures after the described holon, governing owner pattern, bearers, and scale rows are rebound; it does not admit methods, roles, practices, or cultures as holon kinds by label.

#SoTA-Echoing

These rows document transfers from source practice into C.32.ACE. Keep a source citation only when the draft uses it to set or revise an eval-program field, result-use boundary, or refresh condition.

Source-currentness boundary. Use each source row only for the ACE eval-program field, result-use boundary, or refresh condition named in that row. Recheck the row when a named book edition, source presentation, FPF receiving pattern, metric practice, or evolutionary-architecture practice changes the transferred move. If the project wants criteria-row admission, measurement validity, Q-Bundle structure, explicit comparison, selection, publication of a selected set, local choice, evidence, assurance, or decision use, leave ACE and open the receiving pattern.

#Relations

• Builds on: C.32.HCS, C.32.ACS, C.16, C.16.P, C.25, A.2.6, A.19, E.13, E.22, E.23, and A.19.CPM; coordinates with A.3.1, A.3.2, A.15.2, A.15.1, and A.6.1 only for separately current Method, MethodDescription, planned Work, dated Work, or operation-application claims.
• Receiving uses: C.32.P2S actual-structure feedback and next-synthesis repair, C.32 candidate synthesis, C.32.MLAO residual optimization, C.32.CONWAY correspondence frames, C.32.FAIL repair, A.19.CPM comparison, A.19.SelectorMechanism selection, C.11 local choice, publication of a selected set under G.5, and architecture-decision work for C.32.PAD.
• Measurement boundary: Use C.16 when a reading, coordinate, unit, threshold, score, uncertainty, or cross-case comparability claim is made.
• Structural-information boundary: C.33, C.34, and C.35 can supply captured structure, lost structure, preservation adequacy, generated-carrier context, or discovered-carrier context for an eval only after C.32.ACS, C.16, or C.25 has declared what is being evaluated. ACE owns the eval-program framing and dispatches each actual typed result to its direct measurement, comparison, evaluation, or assertion owner; C.33, C.34, and C.35 do not define eval programs.
• Q-Bundle boundary: Use C.25 when the evaluated item is a composite quality family.
• Test boundary: Use test only as an eval operation for a declared expectation or hard constraint. Error recognition and architecture-synthesis repair use C.32.FAIL; non-architecture defects use the local defect-governing pattern.
• Decision boundary: An evaluation framed by an ACE record may reference separately governed readings, ranks, dominance relations, trade-off-front descriptions, and other typed results. When such a result is current, separately identify the admitted System, dated evaluation Work, applicable operation application, and selected direct measurement, comparison, evaluation, or assertion owner for that exact result. A separately governed result may serve as source material for an A.10 evidence relation when an evidence claim is current. Explicit comparison, set-returning selection, local choice, publication of a selected set, and project architecture decision belong to A.19.CPM, A.19.SelectorMechanism, C.11, G.5, and C.32.PAD.

#Footer marker

C.32.ACE closes when the eval program names evaluated criteria, evaluated candidates or structures, exact claim scope and selected context slices, effective reference scheme and plane, evaluation window and input projections, parity frame, eval purpose, scope, intended eval operation, trigger mode, result form, method refs, proxy risks, protected counter-characteristics, receiving use, and refresh or retire condition; when actual evaluation is claimed, its dated Work, direct method or operation-application binding, and typed result remain separately identified.

#C.32.ACE:End

Last Updated: 2026-08-04 — upstream FPF commit 67092138 (github.com/ailev/FPF)