C.32.ACE:1 - 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 first has the A.13 core for candidate evaluation, and A.15.1 independently admits CandidateEvalWork-42, which enacts ArchitectureCandidateEvaluationMethod-7 and occurs within ProductFamilyEvaluationService-7. This first-minute record expressly represents evaluator accountability under EvaluatorAssignment-3, an obtaining occurrence of directly declared species EvaluatorAssignment, so it also includes the separate F.6 relation through the same A.13 assignment. A Work-only ACE record would omit those assignment and attribution refs, and failed F.6 would leave CandidateEvalWork-42 intact. CandidateLatencyReading-42 and CandidateEvidenceScopeFinding-42 are typed results established through their result patterns. Those results can become inputs for 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.
This pattern concerns 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 record in a C.32.ACE-local 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. When measurement validity, comparison policy, a selection result, G.5 result declaration, publication, or architecture decision is current, use the definition and test for that claim.
Ordinary working move: choose the declared criteria rows, bind the 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, recover each exact evaluator through A.13 and let A.15.1 independently admit the U.Work occurrence. Add evaluationWorkAttributionRefs only when the program or receiving use expressly represents precise assignment-bound attribution; missing or failed F.6 leaves the Work intact. Any A.6.1 operation application is an additional relation, not a substitute for the Method enacted by the Work. Return the typed results established through their result patterns 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 pattern. Use the record to frame readings of 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?:
evaluationWorkRefs?: FinSet(U.EntityRef constrained to U.Work)
evaluationWorkAttributionRefs?: FinSet(U.RelationRef constrained to obtaining performedUnderAssignment relations)
evaluationOperationApplicationRefs?: subject-pattern relation or A.6.1 application references
evaluationResultRefs?: typed result references accepted under the definition and test for each result
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 composite U.Work in projectWorkOccurrenceRef and the obtaining 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 evaluationWorkRef names one independently identified U.Work occurrence whose exact actual performers have A.13 cores and which A.15.1 admits independently. evaluationWorkAttributionRefs are optional and appear only when the record or receiving use expressly represents precise assignment-bound attribution; any present ref resolves through F.6 to the same obtaining A.13 assignment, and its absence or failure does not invalidate the Work ref. Any A.6.1 application binding and each typed result remain under the applicable patterns. A program, Method, MethodDescription, Work occurrence, operation application, assignment, attribution, 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 the candidates, bearers, or selected structures to be evaluated under the same parity frame, the declared result form, and which pattern for the next question may use the reading as feedback. When an actual result is claimed, the record cites that separately established result and its result form.
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, selected-set result declaration, actual publication, evidence, assurance, or project architecture decision.
Common exits by claim kind:
C.32.HCSandC.32.ACSbefore characteristic rows exist.C.16for measurement validity, readings, units, uncertainty, or comparability claims.C.25for Q-Bundles and composite quality families.E.13when an eval result or dashboard starts replacing the declared architecture concern.C.32for candidate synthesis,C.32.MLAOfor residual input, andE.23for repeated improvement feedback.A.19.CPMfor explicit comparison,A.19.SelectorMechanismfor set-returning selection,C.11for local choice, andG.5for selected-set result declaration. For publication, useE.17for a source-backed face and source return andE.24.PUBfor the publication occurrence and audience availability.A.10andB.3when evidence or assurance claims are being made.C.32.PADfor project decision.