C.32.ACS:1 - Problem frame
Use this pattern when a project must turn architecture-characteristic pressure into a small project criteria set for architecture improvement, candidate synthesis, residual optimization, and later eval work.
Primary working reader: an architect or architecture-responsible practitioner turning broad quality names into project criteria rows for the next improvement cycle.
Typical entry phrases:
"Maintainability matters, but which bearer and scale make it an architecture criterion here?"
"We can optimize only a few rows; which characteristics drive optimization and which guard against loss?"
"Architecture around a Method, local system-role kind, separate System-classification judgment, assignment, AI workflow, or built asset has trustworthiness or teachability pressure; what is the exact characteristic bearer and which Q-Bundle slot or ACS row is current?"
First-minute use slice. A product-family architect has HCS starter heads and source catalogue names for maintainability, substitutability, evidence reuse, safety, availability, latency, and scale amenability. Using C.32.ACS, the practitioner builds project rows and gives each row its bearer, exact U.ClaimScope, relevant A.2.6 U.ContextSlice membership, effective reference scheme and plane, qualification or evaluation window, scale form, proxy risk, protected losses, and source-return condition. Maintainability, substitutability, and evidence reuse become optimization indicators; safety and availability remain monitored guardrails. The source phrase “scale amenability” remains only a starter cue until ACS admits a concrete characteristic row, such as exception growth or interface-grammar variation, with its bearer and scale form; a claim that one alternative is preferable under a declared scale window remains a separate C.31.ASAP object. C.32 can now synthesize candidates against declared criteria instead of a loose list of quality words.
This pattern concerns one project architecture-characteristic criteria-set record for improvement cycles. Its rows can supply C.32 synthesis, C.32.MLAO residual work, C.32.ACE eval programs, and later patterns for the next questions. The set and its rows are C.32.ACS-local record forms, not new U.* kinds; starter packs, U.Characteristic values, Q-Bundles, measurement methods and results, eval programs and results, candidate palettes, comparison rules, selection results, G.5 result declarations, actual publications, local choices, and architecture decisions remain separate objects.
Ordinary working move: make one row per project architecture characteristic, bind its bearer and scale, mark whether it drives optimization, guards against loss, or only gives context, and record what eval reading can reopen synthesis.
The first useful output is ArchitectureCharacteristicCriteriaSet@Project:
For a first pass, fill the described holon, architecture use, a small set of draft row names, and for every row the bearer or selected structure, exact claim scope and selected context slices, reference scheme and plane, qualification or evaluation window, scale form, use class, protected losses, receiving use, and reopen condition. Add readings, target bands, and eval-program references only when the current receiving use needs them; add a selected BoundedModelUseStructure only when it independently changes interpretation of the row use.
ArchitectureCharacteristicCriteriaSet@Project:
projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work
architectureCriteriaProjectUseRelationRef?: U.RelationRef governed by the exact criteria-use or work-use pattern
describedHolonRef:
architectureUseRef:
holonFamilyStarterPackRef?:
sourceCatalogueRefs?:
draftProjectCriteriaRows:
- architectureCharacteristicRef:
sourceHeadOrStarterPackRef?:
bearerOrSelectedStructureRefs:
rowClaimScopeRef: U.EntityRef referencing one U.ClaimScope
selectedContextSliceRefs:
modelUseStructureRef?:
effectiveReferenceScheme:
referencePlane?:
qualificationOrEvaluationWindow:
endpointShape: singleCharacteristic | qBundle | qBundleSlot | sourceVocabularyOnly
qBundleRef?:
architectureQuestion:
scaleFormRef:
polarity:
useClass: optimizationIndicator | monitoredGuardrail | contextOnly
currentReadingRef?:
targetBandOrStopCondition?:
readingMethodRefOrNoReadingReason:
evalProgramRefs?:
proxyRisk:
protectedCounterCharacteristicRefs:
receivingUseRef:
sourceReturnCondition:
optimizationIndicatorRowRefs:
monitoredGuardrailRowRefs:
contextOnlyRowRefs?:
improvementCycleRef?:
reopenCondition:
For ArchitectureCharacteristicCriteriaSet@Project and ArchitectureCharacteristicImprovementRow@Project, @Project is a compatibility and retrieval cue only; it establishes no project entity, composite-work identity, context, authority, viewpoint, or parthood. A criteria set or improvement row local to one actual project names both the exact composite U.Work in projectWorkOccurrenceRef and the obtaining direct use relation for that exact record in architectureCriteriaProjectUseRelationRef; either field alone is insufficient, and a relation occurrence about the set is not silently reused for a distinct row. Otherwise the record remains retrieval-only and no project locality is asserted.
draftProjectCriteriaRows are draft project criteria rows. They are not candidate architectures, selected architectures, or a selected set returned by A.19.SelectorMechanism.
What goes wrong if C.32.ACS is missed: the team says that the architecture should be more maintainable, scalable, modular, safe, or evolvable, but no one can say which selected structures carry the characteristic, which few rows are criteria for the next optimization, which rows only guard against loss, which C.25 Q-Bundle is involved, or which eval result can reopen synthesis.
What C.32.ACS buys in practice: the practitioner can reduce broad catalogue and starter-pack material to draft project criteria rows, then to three to five optimization indicators, while keeping other important characteristics as monitored guardrails against Goodhart-style proxy loss.
Adoption test: after using C.32.ACS, the project can name the few rows that drive optimization, the guardrail rows that protect against loss, and the bearer, scale, proxy risk, receiving use, and reopen condition for each live row.
Not this pattern when the current work is choosing the holon-family starter pack, modeling a Q-Bundle, validating a measurement method, designing an eval program, synthesizing candidates, comparing or selecting candidates, choosing locally, declaring a selected-set result, publishing it to an audience, or deciding the project architecture.
Common exits by claim kind:
C.32.HCSfor holon-family starter packs.C.25for Q-Bundles and composite quality families.C.16for measurement templates, readings, units, thresholds, or comparability claims.C.32.ACEfor eval-program framing and typed-result classification over declared rows; obtain each actual result separately under the pattern that defines and tests its kind and exact predicate or constraint.E.13when an indicator, score, or dashboard starts replacing the declared architecture concern.E.22andE.23for improvement-question framing and repeated improvement method.C.32for candidate synthesis andC.32.MLAOfor residual-reducing candidates.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.10for source recovery and bounded reliance,G.6when an addressable provenance path is needed, andB.3for an actual named assurance claim; use the direct pattern that defines or tests any additional evidence or validity claim.C.32.PADfor project decision.