C.30:4.5 - Architecture characteristic assignment

C.30 recovers the exact bearer before any quality, fitness, measure, metric, score, modularity, or ility wording carries an architecture-adequacy claim. Those words are triggers, not stable architecture adequacy by themselves.

ArchitectureCharacteristicAssignment:

A. SystemQualityAffectedByArchitecture
   Bearer: exact described U.Holon, named product holon, or named system holon
   Applicable pattern: C.25 Q-Bundle or C.16
   Examples: maintainability, evolvability, resilience, availability, safety, observability

B. ArchitectureStructuralCharacteristic
   Bearer: one exact selected U.Structure, obtaining ArchitectureRelation,
           actual subject relation or constraint, or separately admitted
           module or interface relation
   Applicable pattern: C.16, A.17-A.19, C.25, or the direct
                      characteristic-space or Q-bundle pattern
   Examples: coupling, cohesion, interface alphabet, substitutability,
             hidden coupling, reusable-structure share

C. ArchitectureDescriptionOrViewAdequacy
   Bearer: one exact architecture-description episteme, one exact view episteme,
           one exact correspondence model, or one exact publication-use object
   Applicable pattern: C.30.AD, C.30.ASV, E.17.0, E.17, C.16.Q, or C.16
   Examples: viewpoint coverage, correspondence adequacy,
             source-return adequacy, description modularity

An ArchitectureClaim may state a characteristic claim, but the claim episteme is not automatically the characteristic bearer when its content names the holon, direct architecture relation, or selected structure. Select the exact bearer using the pattern that defines or tests that characteristic claim. Likewise, a diagram or publication cannot inherit the subject’s quality by describing it.

C.30 keeps only a thin bridge from structural characteristics to Q-Bundle relevance. If the claim says architecture causes an outcome improvement, assign causal use to C.28. If a structural characteristic is used as a mechanism, constraint, predictor, proxy, evidence relation, or causal hypothesis for a Q-Bundle slot, start with ArchitectureStructuralCharacteristicQBundleClaimLine rather than a formula such as low coupling = maintainability.

ArchitectureStructuralCharacteristicQBundleClaimLine is claim content for first contact, not a U.Relation occurrence or reusable relation declaration:

ArchitectureStructuralCharacteristicQBundleClaimLine ::= {
  architectureClaimRef?: ArchitectureClaimRef,
  entityOfConcernRef:
    architectureBearingHolonRef | architectureRelationRef |
    selectedStructureRef | directStructuralRelationRef |
    structuralCharacteristicRef,
  effectiveReferenceScheme: U.ReferenceScheme, byValue,
  claimScope?: U.ClaimScope, byValue,
  structuralCharacteristicCueOrRef,
  affectedQBundleSlotRef,
  relationClaimKind:
    structuralCharacteristicRelevantToQBundleSlot |
    structuralCharacteristicConstrainsQBundleSlot |
    structuralCharacteristicPredictsQBundleSlot |
    structuralCharacteristicProxiesQBundleSlot |
    structuralCharacteristicCausalHypothesisForQBundleSlot |
    structuralCharacteristicEvidenceRelationForQBundleSlot,
  relationGroundingKind:
    modelBased | empirical | causalModelBased | expertJudgement |
    sourceLineageOnly | SoTAActionLineage | reportOnly,
  directRelationDisposition:
    noDirectRelationClaimed | admittedRelationAndOccurrence |
    missingGovernor,
  admittedRelationKindOrDeclarationRef?,
  obtainingRelationOccurrenceRefs?: FinSet(U.RelationRef),
  missingRelationParticipantRefs?,
  proposedPredicate?,
  affectedUse?,
  futureDefinitionNeed?,
  evidenceOrCausalPatternLocator?,
  nonAdmissibleUse
}

The line supports an inspectable next question without claiming measurement, modularity score, evidence sufficiency, assurance, gate passage, or causal proof. admittedRelationAndOccurrence is available only when the direct characteristic, evidence, or causal rule defines the relation kind or declaration, participant meanings, obtaining predicate, applicability, and occurrence identity and the referenced occurrences actually obtain. missingGovernor instead names the actual participants, proposed predicate, affected use, and missing definition need. If no defining rule exists for a needed reusable relation, use A.6.RCD; neither a local token, PatternID locator, nor this line admits one.

Minimal structural-characteristic claim-line examples:

Structure kind	Structural characteristic cue or relation	Affected Q-Bundle slot	Relation grounding note	Non-admissible use
`ModuleInterfaceStructure`	Stable interface specification plus substitution policy.	Evolvability or replaceability.	Replacement without global retesting.	Open label as substitutability proof.
`PlacementDeploymentStructure`	Controller placed near plant or edge-node locality.	Latency, resilience, or jurisdictional compliance.	Reduced communication delay and bounded data custody.	Placement diagram as performance or regulatory acceptance proof.
`InformationDataStructure`	State bearer, residence, provenance, and custody boundary.	Observability, privacy, or auditability.	Recoverable state lineage and bounded custody.	Data schema as evidence sufficiency.
`MaterialSpatialStructure`	Physical separation, adjacency, or energy path.	Safety, maintainability, or energy efficiency.	Isolation, accessibility, or loss reduction.	Geometry as safety proof.
`ControlStructure`	Observer-controller-plant loop with rate envelope.	Stability, controllability, or safety.	Feedback and bounded actuation relation.	Control diagram as proof.
`TransformationFlowStructure`	Path crossing, bottleneck, buffer boundary, or waiting-line boundary.	Latency, throughput, or resilience.	Recoverable path, crossing, capacity, and valuation relation.	Flow diagram or mathematical graph description as performance or causal proof.
`SecurityTrustBoundaryStructure`	Trust boundary, privilege path, or untrusted-input crossing.	Security, abuse resistance, or privacy.	Reduced exposed authority and bounded trust crossing.	Risk color or compliance label as security proof.
`EvidenceAssuranceStructure`	Evidence package reused across variants.	Assurance maintainability or release readiness.	Explicit affected-structure and source-return boundary.	Evidence-structure view as assurance verdict.
`WorkMethodStructure`	Method description, work plan, or work enactment relation with explicit exception path.	Operability, auditability, or maintainability.	Bounded repeatability and recoverable exception handling.	Work-method diagram as work authorization or evidence sufficiency.

ArchitectureCharacteristicQBundleClaim is the triggered full claim episteme. Use it only when publication, comparison, causal use, evidence reliance, assurance, gate, decision, or reusable cross-case reliance needs a durable bounded claim and the thin line cannot keep the content inspectable.

ArchitectureCharacteristicQBundleClaim ::= {
  claimEpistemeRef: U.EpistemeRef,
  entityOfConcernRef:
    architectureBearingHolonRef | architectureRelationRef |
    selectedStructureRef | directStructuralRelationRef |
    structuralCharacteristicRef,
  effectiveReferenceScheme: U.ReferenceScheme, byValue,
  claimScope?: U.ClaimScope, byValue,
  architectureClaimRef?: ArchitectureClaimRef,
  architectureStructuralViewRef?,
  architectureDescriptionRef?,
  structuralCHRRefs,
  affectedQBundleRefs,
  assertedParticipantRefs: {
    structuralCharacteristicRef,
    qBundleSlotRef
  },
  relationClaimPolarity:
    positive | negative | unresolved | candidateOnly,
  relationClaimKind:
    structuralCharacteristicRelevantToQBundleSlot |
    structuralCharacteristicConstrainsQBundleSlot |
    structuralCharacteristicPredictsQBundleSlot |
    structuralCharacteristicProxiesQBundleSlot |
    structuralCharacteristicCausalHypothesisForQBundleSlot |
    structuralCharacteristicEvidenceRelationForQBundleSlot,
  relationGroundingKind:
    modelBased | empirical | expertJudgement |
    sourceLineageOnly | SoTAActionLineage | causalModelBased | reportOnly,
  directRelationDisposition:
    noDirectRelationClaimed | admittedRelationAndOccurrence |
    missingGovernor,
  admittedRelationKindOrDeclarationRef?,
  obtainingRelationOccurrenceRefs?: FinSet(U.RelationRef),
  missingRelationParticipantRefs?,
  proposedPredicate?,
  affectedUse?,
  futureDefinitionNeed?,
  scopeOrScaleWindow?,
  viewpointRef?,
  qualifiers?,
  witnessExpectations?,
  admissibleSemanticChangeClasses?,
  bridgeOrLossBoundary?,
  admissibleUse,
  nonAdmissibleUse,
  evidenceOrCausalPatternLocator?
}

The full claim keeps the proposal inspectable through assertion polarity, the exact structural-characteristic and Q-Bundle-slot referents, scope or scale window, viewpoint when it changes interpretation, qualifiers, witness expectations, admissible semantic change classes, and bridge or loss boundary. These are claim-content fields. They neither declare a reusable relation kind nor make an occurrence obtain; a direct relation still needs an admitted kind, exact participants, a defining predicate and applicability rule, and occurrence identity.

Reusable product-quality vocabularies may supply candidate characteristic names, but they do not become architecture theory. Claim content may connect exact bearers and Q-Bundle slots. A direct relation obtains only when its participants and predicate pass the test defined for it. Use the applicable patterns for measurement, modularity scoring, reusable-structure accounting, bespoke-residue accounting, evidence, assurance, gate, causal, and scale-audit claims.