C.30:1 - Problem frame

Use this pattern when you need to decide what the architecture of one exact holon (U.Holon) is and what to do next. First distinguish actual relations and a selected structure from a candidate or expected structure, a claim about either, and a description or representation.

For a precise result, recover which subject relations actually obtain, which exact U.Structure is selected from them, whether the direct ArchitectureRelation obtains, what the C.2.1 claim says, the concern and admissible-use frame, and the next architecture move.

The first useful architecture move is small. In ordinary prose, name the holon; say whether the structure is actual, candidate, or expected; name the structure kind and architecture concern; state how any inspected material is being used; and give the next move. If one or two sentences make those values clear, stop.

For example: “For the payment system, the diagram shows a candidate module-interface structure, not an established architecture relation. Next recover the actual dependency relations before deciding whether to replace the fraud-scoring module.” This is already a usable result. Use the card below only when the result must be retained, compared, or handed on:

ArchitectureQuestionCard@Project:
  projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work
  architectureQuestionProjectUseRelationRef?: U.RelationRef, only when a named pattern defines this project-use relation and the occurrence obtains
  architectureClaimRef?: ArchitectureClaimRef
  describedHolonRef:
  architectureRelationDisposition:
    actualRelationNamed | actualRelationStillToRecover |
    candidateOrExpectedOnly | nonArchitectureQuestion
  architectureRelationRefs?: FinSet(U.RelationRef)
  claimScope?:
  effectiveReferenceScheme?:
  modelUseStructureRef?: only when one selected bounded model-use structure changes this architecture use
  architectureConcernCue:
  architectureConcernClaimRefs?: FinSet(U.EpistemeRef)
  sourcePhrase?, if useful:
  questionDisposition:
    concernCueOnly | problemCardReady | architectureClaimReady | nonArchitectureClaimReady
  selectedStructureRefs?: FinSet(U.StructureRef)
  candidateOrExpectedStructureRefs?: FinSet(U.StructureRef)
  selectedStructureKindRefs or candidateStructureKindRefs:
  inspectedMaterialUse, if current: claim content | description | view | representation | publication form | source | decision | mathematical lens | other exact use
  inspectedMaterialUseRelationRefs?: references to exact obtaining relations that establish the inspected-material use
  firstArchitectureMove:
  architectureDescriptionBridge, if durable description use is current:
  claimPatternRefs?: FinSet(PatternRef), if another claim is being made:
  non-admissible overread:

The card can stop before a durable claim. An actualRelationNamed result requires exact obtaining ArchitectureRelation occurrences and their A.22 structure participants. A candidate, planned, required, desired, expected, modeled, or diagrammed structure remains in candidateOrExpectedStructureRefs and makes no subject relation obtain. architectureConcernCue is recognition wording only until it helps choose one selected structure kind and one architecture move. When a controlled cue is useful, use changeLocalization, substitutionOrReplacement, flowBottleneck, controlOrRateMismatch, dataCustodyOrStateResidence, physicalSeparationOrPlacement, evidenceReuseOrAssuranceReuse, scaleWindowOrCoarseningLoss, runtimeFailureMode, crossScopeResidual, descriptionViewLoss, or otherDeclared. Local phrases such as change localization failure, hidden crossing, source return, generated-view loss, or state-residence uncertainty may remain in sourcePhrase? or Plain prose. If the described holon, distinction between actual and candidate structure, architecture concern, and first move cannot yet be named, set questionDisposition to concernCueOnly or problemCardReady; wording alone promotes neither a claim nor an obtaining relation.

ArchitectureQuestionCard@Project is a triage aid for choosing one architecture move. questionDisposition records whether to keep a concern cue, prepare a separate ProblemCard, constitute an ArchitectureClaim, or name the pattern for a non-architecture claim. architectureRelationDisposition separately records whether an actual direct relation has been recovered or the content is candidate or expected only. claimPatternRefs contains PatternIDs whose content defines, constrains, or tests any separate claim; it does not identify a pattern-application occurrence. The card is not an evidence record, gate, decision, release record, quality score, risk rating, or publication-use authority claim.

Across C.30, @Project in a record name is a compatibility and retrieval cue only. It identifies neither a project entity nor a composite project U.Work, and it establishes no context, authority, viewpoint, or parthood. When the card is genuinely local to one actual project, projectWorkOccurrenceRef identifies the exact composite U.Work recovered under A.15.6. Include architectureQuestionProjectUseRelationRef only when a named pattern defines the relation by which this card use concerns that Work and an occurrence of that relation obtains. A Work reference alone does not establish project locality. If that locality matters but the relation is not yet defined, record missing-governor; if locality does not matter, omit both project-local fields. Description publication and other project-local uses follow the same rule. A described holon, architecture claim, or architecture relation does not become project Work by retrieval suffix.

Use a conditional ArchitectureDescription bridge only when durable architecture-description use is current: cross-team reuse, regulated or safety use, reusable design, comparison, source or lens reuse, or another named full-mode description use. Ordinary use stops at ArchitectureQuestionCard@Project when it makes one next architecture move clear. If the architecture description itself becomes the EntityOfConcern under repair, use C.30.AD.

What goes wrong if C.30 is missed: the practitioner reasons from a document, module diagram, transformation-flow graph description, mathematical lens, benchmark, maturity score, or decision record instead of recovering the described holon, selected structures, first architecture move, and non-architecture claim kind.

What C.30 buys in practice: the practitioner stops treating a document or diagram as architecture. They can distinguish actual relations and selected structure from the architecture relation, claim, description, view, representation, publication occurrence, publication form, carrier, and source relation, then choose one small next move.

Do not use C.30 when the question does not concern the architecture of one exact holon, an obtaining ArchitectureRelation, a selected architecture-relevant structure, an ArchitectureClaim, or the thin architecture-description bridge needed for one architecture move. Use the pattern that defines or tests the actual source, description, view, publication-use, or other non-architecture relation. If one piece remains an architecture claim, use C.30 only for that piece. Common non-architecture claim boundaries are summarized in C.30:12.

Thin precision-restoration pointer: if the issue under repair is still whether architecture, architecture description, structural view, module diagram, model, source material, functional architecture, or a source label such as layer, level, tier, stack, block, expert, cache, router, or gate names an architecture claim, description, view, representation, publication form, source relation, structure, or claim defined or tested by another pattern, use C.30.P or C.30.STRAT as triggered before applying C.30 to the recovered architecture portion. If the recovered issue is mathematical-lens use, apply C.29; when no mathematical-lens use changes the architecture work, keep ordinary prose or use NoMathLensUseNeededNote under C.29 rather than creating a C.30-local lens result. Keep trigger tables in those patterns; C.30 is applied only after an ArchitectureClaim, exact selected architecture-relevant structure, conditional ArchitectureDescription bridge use, C.30.AD application, or other claim named by value is recoverable.