#CAL Authoring: Calculi - Acceptance - Evidence

G.4 · Stable · Part G - Discipline SoTA Patterns Kit

#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.

Use this when. A team has typed characteristics and now needs to publish reusable operators, acceptance clauses, and legal compositions before any candidate is actually evaluated. The working object is one design-time CAL Pack@CG-Frame, not an evaluation run, verdict, selector outcome, assurance case, or decision.

First move. Write one plain acceptance sentence for one task: “For subject x in Context C, apply declared operator O to named C.16 result episteme E; return pass | fail | unknown under clause A, threshold/policy P, and stated currentness window.” Then turn only the nouns needed by that sentence into stable CAL declarations.

Smallest viable CAL pack. Publish one Context charter, one typed operator card, one acceptance clause with unknown/failure behavior, one legal flow, one evidence/currentness profile, one proof-or-gap row, one worked declaration example, and a minimal TaskMap that cites their ids. Stop there when this pack answers the task; method-family extensions, archive surfaces, crossing records, and additional policy pins enter only when the case actually needs them.

What changes in practice. Thresholds and failure behavior stop hiding in code, illegal arithmetic becomes an authoring defect, and runtime workers can cite stable declarations without pretending that a card, flow, manifest, proof row, or stored evidence ref performed an evaluation.

Not this pattern. Use C.16 for the measurement result, A.19 for comparison/selection, A.15.1 and A.6.1 for dated evaluation work and actual bindings, C.2.1 for the verdict episteme, A.10/G.6 for provenance, G.11 for currentness, B.3 for assurance, and C.11 for a decision. If the immediate question is whether a declared clause actually ran and what result obtained, go directly to the declaration-to-runtime boundary in §4.4a.

A CG‑Frame has:

#Keywords

• CAL Pack@CG-Frame
• Context charter
• typed operator card
• acceptance clause
• legal flow
• pass | fail | unknown
• evidence/currentness profile
• proof-or-gap row
• TaskMap
• declaration/runtime boundary
• dated EvaluationWork
• actual A.6.1 bindings
• verdict episteme.

#Relations

#Content

#Problem frame

A CG‑Frame has:

• a declared CG-FrameContext (scope, EntityOfConcern, plane),
• a plurality of method traditions and claims (SoTA inputs), and
• CHR‑typed measurement constructs (Characteristic/Scale/Coordinate + legality guard macros).

Before any run‑time selection, comparison, aggregation, or selected-set formation is executed downstream, the CG‑Frame needs an explicit, auditable CAL Pack that:

1. defines what operators exist and what they are allowed to do over CHR types,
2. externalizes fit‑for‑purpose acceptance as typed predicates (with Context‑local thresholds), and
3. binds these choices to an evidence wiring surface (lanes, provenance anchors, policy pins, and refresh triggers) so that downstream selection, logging, parity, and shipping can cite stable ids rather than re‑inventing semantics.

This pattern provides the design‑time authoring kit and the publication surface for CAL artifacts, while delegating Part‑G‑wide invariants to G.Core and CN-Spec and CG-Spec legality to CG‑Spec/CN‑Spec.

#Problem

Teams repeatedly face drift and ambiguity in the CAL Pack that sits between “typed measurements exist” and “a selector/dispatcher runs”:

• Illicit operations slip in (implicit cardinalization, unit laundering, ordinal arithmetic).
• Acceptance is scattered (thresholds embedded in code or in CHR prose; predicates not typed; unknown handling inconsistent).
• Evidence wiring is underspecified (which provenance anchors matter, what policy ids are in force, what is plane‑scoped, what changes must trigger refresh).
• Cross‑context imports are silent (hidden reuse of constructs across contexts or planes/editions without published GateCrossings and loss accounting).
• Tooling artifacts become semantics (vendor flags or implementation details substitute for a conceptual specification).

#Forces

• Expressiveness vs legality. CAL must allow useful comparisons/aggregations while staying lawful under CHR typing and legality gates.
• Pluralism vs comparability. Multiple method traditions must coexist without forcing premature unification, yet remain cross‑citable and auditable.
• Decision support vs auditability. CAL must support selection and selected-set formation while preserving explicit, reviewable assumptions and proofs.
• Exploration vs assurance. CAL must support exploratory regimes (probing, novelty, open‑ended search) without letting un‑assured outputs silently become dominance claims.
• Locality vs portability. CAL must be Context‑local by default but prepared for explicit reuse via Bridges and published crossing bundles.

#Solution — author the smallest lawful CAL pack

#Practitioner authoring path C1–C9

Complete these actions in order; widen a step only when its stated input is needed by the current task.

1. C1 — Charter the scope. Name CG-FrameContext, the exact entityOfConcern, ReferencePlane, task, and the editions of the governance and legality records being relied on. State the assumption envelope in ordinary language.
2. C2 — Declare one typed operator. Give it a stable id, CHR-typed signature, preconditions, result kind, and failure behavior. This is an A.6.1 operation declaration, not evidence of an application.
3. C3 — Declare one acceptance clause. Bind the exact Characteristic/result episteme, threshold or predicate, Context, unknown handling, and stop/degrade/abstain behavior. If the clause claims statistical risk or coverage control, also name the loss, target, calibration population and window, sampling/exchangeability or shift assumptions, and the exact policy that owns the guarantee.
4. C4 — Compose only a legal flow. Cite the operators and gating clauses, preserve the lawful result kind, and keep a selected set when no lawful scalarization exists. A declared DAG is possible composition, not performed work.
5. C5 — Name the minimum evidence/currentness need. Cite the exact A.10 source/provenance anchors and G.11 window needed to judge the clause. Do not turn an evidence profile, citation, or graph membership into a verdict or actual reliance.
6. C6 — Add an extension only when the task needs one. Select its current governing pattern first, then pin only the descriptor, distance, insertion, exploration, branch, or path records that change the present CAL action. Otherwise omit the extension.
7. C7 — Record proof or an explicit gap. For every operator, flow, or clause, cite the legality/monotonicity/boundedness justification actually required; when it is missing, publish the gap and the consequent degrade/abstain behavior.
8. C8 — Exercise declaration behavior. Provide one worked authoring example and focused conformance tests for illegal operations, pass | fail | unknown, freshness, and failure behavior. The example and test remain declarations/test records unless separately grounded dated work is named.
9. C9 — Publish and hand off. Mint stable ids and continuity notes, then emit the smallest TaskMap from the task to eligible operator/flow ids, gating clause ids, and required evidence/currentness refs. Send change refs to G.11; do not make G.4 the refresh or runtime owner.

The authoring path is complete when a cold reader can reconstruct the plain acceptance sentence from the published ids and can also say what still has to happen at runtime. The owner-facing manifests, schemas, interfaces, and optional extension blocks below make the same pack machine-citable; they do not add another practitioner sequence.

#G.Core linkage (normative)

Builds on: G.Core (Part‑G core invariants; citation/delegation hub)

GCoreLinkageManifest (normative). Canonical shape, Nil‑elision, and the Expansion rule are defined in G.Core.

`GCoreLinkageManifest := ⟨ CoreConformanceProfileIds := { GCoreConformanceProfileId.PartG.AuthoringBase, GCoreConformanceProfileId.PartG.TriStateGuard, GCoreConformanceProfileId.PartG.UTSWhenPublicIdsMinted, GCoreConformanceProfileId.PartG.ShippingBoundary },

CorePinSetIds := { GCorePinSetId.PartG.AuthoringMinimal, GCorePinSetId.PartG.CrossingVisibilityPins },

CorePinsRequired := { UTSRowId[], // CAL artefacts are public ids (Name Cards plus public-id continuity notes) ΓFoldRef.edition? // only when an explicit Γ‑fold override is pinned (otherwise use DefaultId) },

// consumed iff no explicit ΓFoldRef.edition override is pinned DefaultsConsumed := { DefaultId.GammaFoldForR_eff },

RSCRTriggerSetIds := { GCoreTriggerSetId.SoTAHarvestSynthesis }, RSCRTriggerKindIds := { // deltas (Expansion rule applies) RSCRTriggerKindId.PenaltyPolicyEdit, RSCRTriggerKindId.DefaultGoverningDefinitionChange, RSCRTriggerKindId.BaselineBindingEdit } ⟩`

By the G.Core Expansion rule, the effective conformance ids / trigger kinds / pin obligations for G.4 are the expansions of the referenced profiles/sets/pin‑sets plus the explicit deltas above.

Notes (normative intent, delegated semantics):

• The semantics of tri‑state outcomes, penalty routing, set‑return discipline, crossing visibility, P2W split, typed RSCR causes, and the Default Governing Definition Index are governed in G.Core and are not redefined here.
• EvidenceGraph/Path pins (when used) are declared only via G.4:Ext.EvidenceGraphWiring in G.4:4.5 (so G.Core linkage stays minimal and does not “pull in” G.6 by default).
• Method‑specific pins (e.g., QD descriptor/distance/insert policy pins; open‑ended transfer rules pins) MUST appear only in Extensions blocks (see G.4:4.5) and MUST NOT introduce competing defaults.

#CAL Pack@CG-Frame surface (kit governed by this pattern)

CAL Pack@CG-Frame is the CG‑Frame’s published CAL Pack. Minimally, it provides:

• CAL.Charter@Context — scope anchor for this CAL pack:

  • cites CG-FrameContext, entityOfConcern, ReferencePlane,
  • cites the governance card and legality gate (CNSpecRef, CGSpecRef) by edition pins,
  • records the “assumption envelope” that acceptance predicates rely on (without minting a new governance card or legality gate).
  • emits TaskMap@Context (TaskMap) as the canonical handoff record to G.5 (task→gates/flows/evidence pins).

• CAL.Operator[] — UTS‑published typed operation declarations governed by A.6.1; a card declares possible arguments, result kinds, and conditions but does not assert that an operation ran:

  • explicit signature over CHR types,
  • explicit preconditions/postconditions (incl. legality guard macros references),
  • explicit provenance/evidence hooks (by ids/pins, not by tool behavior).

• CAL.Acceptance[] — typed predicate declarations with Context‑local thresholds; a clause declares how an actual application is judged but is not itself a verdict:

  • binds to CHR characteristic ids (and, when inducing numeric comparison/aggregation, to CG‑Spec.characteristic ids),
  • exposes unknown handling and failure behavior via policy pins.

• CAL.Flow[] — legality‑checked declarations of possible operator composition; a declared DAG is not performed work:

  • declares result kind (scalar only when lawful; selected-set / set-result when partial orders remain partial orders),
  • records which acceptance clauses gate which flows.

• CAL.EvidenceProfiles — evidence wiring surface:

  • lane tags (F/G/R) / provenance anchors / policy pins needed for SCR and audit surfaces,
  • explicit freshness/decay hooks (freshness window + decay/Γ_time selectors) as pinned policies/refs (not prose).
  • explicit ReferencePlane + penalty routing policy ids (Φ(CL), Ψ(CL^k), Φ_plane) as citable pins; any such policy family is justified in CAL.ProofLedger (monotone + bounded).

• Optional CAL.NQD[] — QD/OEE‑related calculus surfaces when declared:

  • descriptor/distance/insertion artifacts are pinned by ids/editions,
  • semantics are governed by method‑specific governing definitions (e.g., C.18, C.19) and not redefined by CAL.

• CAL.ProofLedger — a proof/justification ledger:

  • links legality, monotonicity, boundedness, and other soundness obligations to operator/flow/clause ids.

• Publication artifacts:

  • UTS Name Cards (twin labels) for all public ids,
  • RSCR tests ids and Worked‑Examples ids,
  • deprecation notices and edition bump notes as public-id continuity records.

Boundary discipline (normative):

• No shadow specs: CAL artefacts cite CN‑Spec/CG‑Spec and do not introduce competing “local specs” (delegated; see CC‑GCORE‑CN‑CG‑1 via CC‑G4‑CoreRef).
• No shipping governance: CAL does not govern shipping; see CC-GCORE-SKP-1 via CC-G4-CoreRef.
• No refresh governing-definition assignment: CAL does not govern refresh orchestration; it only publishes pins/payload for refresh (governing definition: G.11).

Minimal schema fragments (notation‑independent; fields for citation, not an implementation schema):

CAL.Pack@CG-Frame :=
 ⟨ calPackId, charterId, taskMapId, operatorIds[], acceptanceClauseIds[], flowIds[],
 evidenceProfileIds[], proofLedgerId, nqdIds[]?,
    utsRowIds[], workedExampleIds[], rscrTestIds[], publicIdContinuityNoteIds[] ⟩

CAL.Operator :=
  ⟨ operatorId(UTS), signature(CHR-typed), preconditions[], postconditions[],
  evidenceProfileRefs[]?, failureBehaviorRef?, crossingRefs[]? ⟩

CAL.Acceptance :=
  ⟨ clauseId(UTS), characteristicRefs[], cgSpecCharacteristicRefs[]?,
    predicateRef, unknownHandlingRef, failureBehaviorRef,
    evidenceProfileRefs[]?, crossingRefs[]? ⟩

CAL.Flow :=
  ⟨ flowId(UTS), dag(operatorIds, edges), gateClauses(acceptanceClauseIds),
    resultKind, decisionAidPolicyRef? ⟩

CAL.EvidenceProfile :=
  ⟨ evidenceProfileId(UTS), lanes(F/G/R), anchors(A.10)[],
    freshnessPolicyPins[]?, penaltyPolicyPins[]?, ΓFoldRef.edition? ⟩

#Interfaces (minimal I/O surface)

#Declaration-to-runtime evaluation boundary (normative)

A CAL pack is a reusable design-time declaration. A stored operator card, clause, flow, TaskMap, proof-ledger row, test, or evidence-profile reference establishes neither an actual participant nor performed evaluation. When a CAL declaration is applied, recover the runtime chain explicitly:

1. Name one exact EvaluationMethod (U.Method). Its U.MethodDescription may state generic participants, parameters, effects, and evaluation conditions, but it carries no actual-participant slots and no intrinsic claim that a test, proof, or acceptance event occurred.
2. Cite the exact CAL.Operator, CAL.Flow, and CAL.Acceptance declarations as A.6.1 operation semantics. If the runtime application needs argument and result bindings, use the exact A.6.1 declaration and application bindings; do not infer them from a compatible signature, TaskMap, or stored reference.
3. Ground one dated EvaluationWork as U.Work: give it an occurrence designator, temporal extent, performer through U.RoleAssignment, enactsMethod, the evaluated or affected referent, actual resources, and every concrete participant through its direct subject relation or an A.6.1 application binding.
4. State the local result under its direct governor. A CAL.Acceptance application yields its exact pass | fail | unknown acceptance verdict; A.19 owns comparison and selection results, C.16 owns measurement results, and C.11 owns a decision result. No generic evaluation-result or work-result field substitutes for these objects.
5. When a durable assertion is needed, constitute one C.2.1 result episteme whose ClaimGraph states that local result, evaluated subject, interpretation basis, polarity or domain status, and uncertainty when current. The episteme is not the domain result and does not create it.
6. Attach source recovery and provenance through A.10/G.6 and currentness through G.11. For an ordinary bounded use below B.3's material-reliance threshold, state the exact A.10 evidence-provenance path and local RelianceDisposition; enter B.3 only for an assurance claim or material reliance. A citation, ledger edge, evidence profile, disposition, or assurance record does not establish the work, participant, application, or local result it describes.
7. A later selector, acceptance action, or decision is another governed occurrence. It relies on the result episteme through an exact premise, reference, decision-use, or operation-argument relation; mere storage, citation, or graph membership does not establish actual use.

This chain keeps declaration, execution, local result, result episteme, provenance, bounded reliance, currentness, acceptance, and decision independently recoverable.

#Extensions (pattern‑scoped; non‑core)

G.4 supports method‑family and discipline‑specific calculus variations exclusively via pattern‑scoped extensions.

GPatternExtension block: G.4:Ext.EvidenceGraphWiring

• PatternScopeId: G.4:Ext.EvidenceGraphWiring
• GPatternExtensionId: EvidenceGraphWiring
• GPatternExtensionKind: InteropSpecific
• GoverningPatternId: G.6
• Entry: use only when this CAL pack must cite a shared, addressable G.6 path or slice across more than one downstream consumer.
• Stop: omit the block when a local A.10 source-to-use account is sufficient; remove it when no current clause, proof, or example cites the path.
• Uses: {G.6}
• ⊑/⊑⁺: ∅
• RequiredPins/EditionPins/PolicyPins (minimum):
  • EvidenceGraphId?
  • PathId[]/PathSliceId[]
  • UTSRowId[] (for cited artifacts)
• RSCRTriggerSetIds: ∅
• RSCRTriggerKindIds: {RSCRTriggerKindId.EvidenceSurfaceEdit, RSCRTriggerKindId.EditionPinChange, RSCRTriggerKindId.PolicyPinChange}
• Notes (wiring‑only): This block does not define EvidenceGraph semantics; it only fixes that CAL proofs/examples may cite evidence by Path ids.

GPatternExtension block: G.4:Ext.NQD

• PatternScopeId: G.4:Ext.NQD
• GPatternExtensionId: NQD
• GPatternExtensionKind: MethodSpecific
• GoverningPatternId: C.18
• Entry: use only when the current task applies a C.18 quality-diversity/archive method and its descriptor, distance, insertion, or archive policy must be pinned for CAL use.
• Stop: omit or retire the block when the task has no current archive/QD clause or when those refs no longer change a CAL action.
• Uses: {C.18}
• ⊑/⊑⁺: ∅
• RequiredPins/EditionPins/PolicyPins (minimum):
  • DescriptorMapRef.edition
  • DistanceDefRef.edition
  • InsertionPolicyRef
  • ArchiveRef?
  • TaskSignatureRef? (if activation is TaskSignature‑bound)
• RSCRTriggerSetIds: ∅
• RSCRTriggerKindIds: {RSCRTriggerKindId.EditionPinChange, RSCRTriggerKindId.PolicyPinChange, RSCRTriggerKindId.TelemetryDelta, RSCRTriggerKindId.FreshnessOrDecayEvent}
• Notes (wiring‑only): CAL does not redefine QD semantics; it only pins the descriptor, distance, and insertion records needed for reproducible archive behavior. Any archive/illumination summaries (e.g., coverage / QD‑score / occupancyEntropy / filledCells) are published as report‑only outputs unless an explicit CAL acceptance clause/policy authorizes promotion.

GPatternExtension block: G.4:Ext.EELog

• PatternScopeId: G.4:Ext.EELog
• GPatternExtensionId: EELog
• GPatternExtensionKind: MethodSpecific
• GoverningPatternId: C.19
• Entry: use only when the current task has a C.19-governed exploration/exploitation budget or probe-accounting rule that changes a CAL clause or failure branch.
• Stop: omit or retire the block when no current CAL action consumes those C.19 refs.
• Uses: {C.19}
• ⊑/⊑⁺: ∅
• RequiredPins/EditionPins/PolicyPins (minimum):
  • ExploreExploitBudgetPolicyRef
  • ProbeAccountingRef?
  • FailureBehaviorRef? (if probe/sandbox is policy‑bound)
• RSCRTriggerSetIds: ∅
• RSCRTriggerKindIds: {RSCRTriggerKindId.PolicyPinChange, RSCRTriggerKindId.TelemetryDelta, RSCRTriggerKindId.FreshnessOrDecayEvent}

GPatternExtension block: G.4:Ext.SoSLogBranches

• PatternScopeId: G.4:Ext.SoSLogBranches
• GPatternExtensionId: SoSLogBranches
• GPatternExtensionKind: MethodSpecific
• GoverningPatternId: C.23
• Entry: use only when C.23-governed SoS-LOG branches currently explain a CAL degrade/abstain path.
• Stop: omit or retire the block when those branch/rule ids no longer change a current CAL clause, flow, or explanation.
• Uses: {C.23}
• ⊑/⊑⁺: ∅
• RequiredPins/EditionPins/PolicyPins (minimum):
  • SoSLogRuleId[]
  • SoSLogBranchId[]
  • FailureBehaviorPolicyId
• RSCRTriggerSetIds: ∅
• RSCRTriggerKindIds: {RSCRTriggerKindId.PolicyPinChange, RSCRTriggerKindId.MaturityRungChange, RSCRTriggerKindId.TelemetryDelta}
• Notes (wiring‑only): This block only pins branch/rule ids for degrade/abstain explanation; it does not redefine rule semantics.

#Archetypal Grounding

Tell. A CG‑Frame must choose and justify a set of candidate methods (possibly a selected set or archive) under explicit legality, evidence, and scope constraints. CHR provides the typed measurement basis; CAL declares auditable predicates and flows that separately grounded runtime work may apply.

Show 1 (in‑context CAL pack skeleton). Context: R&D selected-set choice. CHR defines SafetyClass(ord↑), CostUSD_2026(ratio↓), Readiness(nominal).

• CAL.Operator: DominatesPareto Signature over CHR types, precondition references CHR guard macros.
• CAL.AcceptanceClause: AC_SafetyGate Typed predicate binding SafetyClass (and its levels) with Context‑local thresholds; unknown handling uses tri‑state pins.
• CAL.Flow: Flow_ParetoPortfolio Produces a selected-set result kind; gates by AC_SafetyGate and AC_Budget.
• CAL.EvidenceProfile: EP_SafetyEvidence Declares anchor ids and freshness policy pins required for SCR.

Downstream, G.5 consumes only the handoff manifest: clause ids, operator ids, and evidence profile ids (no embedded thresholds).

Show 2 (explicit cross‑context import). A SafetyClass value is imported from a different Context or plane. CAL may still author an acceptance clause using that value, but only after the reuse is made explicit as a published crossing bundle and the CAL artifacts cite the relevant ids/pins. The CAL pack remains Context‑local; portability is achieved through explicit crossings and citations, not by silently widening scope.

Show 3 (one performed acceptance evaluation).

A dated work occurrence EvalWork-2026-07-30-17 has a performer through U.RoleAssignment, enacts SafetyAcceptanceMethod, and binds candidate C-17 plus the current C.16 measurement-result episteme to AC_SafetyGate through the declared A.6.1 operation application. The C.16 episteme states the measured safety characteristic, scale, attributed value, uncertainty, model, calibration, and measurement work; it is neither the raw detector output nor the acceptance verdict. The clause application obtains unknown because the uncertainty interval crosses the threshold. A separate C.2.1 episteme asserts that exact verdict and cites its A.10/G.6 provenance; G.11 supplies currentness. Later C.11 decision work binds that episteme as a premise and records defer. The clause card, proof-ledger row, evidence edge, and decision record do not retroactively establish the measurement work or the evaluation occurrence.

#Bias-Annotation

CAL is where “what counts as acceptable” is encoded. Typical bias vectors include:

• threshold‑selection bias (arbitrary floors masquerading as natural laws),
• measurement bias amplified by illegitimate arithmetic or hidden scalarization,
• survivorship bias in Worked‑Examples and probe telemetry,
• Goodhart pressures when report‑only telemetry is accidentally treated as dominance.

The pattern mitigates these by requiring typed acceptance clauses, explicit policy pins, and an auditable proof/justification ledger, while keeping cross‑context reuse explicit and penalized only in the explicit assurance lane.

#Conformance Checklist (normative)

#Common Anti-Patterns and How to Avoid Them

• Hidden thresholds. Avoid: embedding cutoffs in CHR prose or in operator descriptions. Prefer: CAL.AcceptanceClause with explicit ids and pins.

• Untyped “score(x)”. Avoid: operators with implicit units and untracked legality assumptions. Prefer: explicit CHR‑typed operator signatures + cited legality checks.

• Silent cross‑context reuse. Avoid: importing constructs across Contexts/planes/editions without published crossings. Prefer: explicit crossing artifacts and citations; keep CAL pack Context‑local.

• Acceptance as implementation detail. Avoid: acceptance embedded in tool logic. Prefer: publish acceptance as citable CAL artifacts; downstream consumes ids.

• Exploratory telemetry treated as dominance. Avoid: letting probe/illumination telemetry quietly become a dispatch criterion. Prefer: keep it report‑only unless an explicit policy‑bound acceptance clause authorizes promotion.

• Declaration mistaken for execution. Avoid: treating a CAL card, TaskMap, proof-ledger row, worked example, or evidence edge as proof that an operator ran or a verdict obtained. Prefer: ground dated work, role assignment, method enactment, actual direct bindings, the domain-local result, and any result episteme separately.

#Consequences

• CAL becomes a stable, citable CAL Pack: operator/acceptance semantics are explicit artifacts, not tacit code behavior.
• Legality failures are surfaced as authoring defects (RSCR‑testable) rather than run‑time surprises.
• Downstream patterns (G.5, G.8, G.9, G.10, G.11) can reference stable ids/pins without redefining acceptance or operator semantics.
• Method pluralism is supported: multiple calculi can coexist as separate operator/flow/acceptance families, wired via Extensions rather than mixed into the core kit.

#Rationale

CAL sits at the boundary where typed measurement becomes actionable choice. Making CAL a published, typed, and testable artifact reduces semantic drift and prevents “shadow legality gates” from emerging in tools or in downstream prose.

The design separates concerns:

• CHR governs measurement typing and legality guard macros,
• CG‑Spec and CN‑Spec govern the legality gate and governance card, respectively,
• G.Core governs Part‑G invariants and trigger/default discipline,
• G.4 governs the CAL kit: authoring objects, publication surface, and handoff manifest.

This yields modularity (one governing definition per invariant or default), auditability (pins/ids and proof refs), and extensibility (method families attach through explicit extension modules).

#SoTA-Echoing

Source qualification was checked on 2026-07-30. The source identities below are immutable publications; the G.4 adoption decisions remain qualified through 2027-07-30 unless a governing neighbour adopts a successor earlier or a new result contradicts the named assumption boundary.

Distributionally robust and broad multi-objective families are discovery leads, not G.4 decision sources. Current comparison, partial-order, and selected-set law stays with A.18/A.19; a future external source enters this table only after it changes a present C1–C9 action, worked case, or conformance row. Source refresh is local to the row's named rule, example, and check.

#Owner-facing architecture and publication inventory

G.4 is a design-time authoring pattern. It publishes a notation-independent CAL Pack@CG-Frame with charter, stable operator/clause/flow ids, evidence/currentness refs, proof-or-gap records, worked examples/tests, continuity notes, and a minimal TaskMap. It uses G.Core/G.0/G.1–G.3 for Part-G, Context, SoTA, CHR, and legality disciplines; A.6.1/A.15.1/C.2.1 for the declaration/runtime/result-episteme split; and A.10/G.11/B.3/C.11 for provenance, currentness, assurance, and decisions. G.6 is used only when G.4:Ext.EvidenceGraphWiring is present. Method-specific semantics remain with the exact extension governor. The detailed manifests, schemas, and interfaces above are owner-facing citation surfaces for this one practitioner path, not a second workflow.

#Relations

Builds on: G.Core (and the pattern template discipline in E.8).

Uses: G.1 (CG‑FrameContext), G.2 (SoTA Synthesis Pack), G.3 (CHR Pack), G.0 (CG‑Spec legality gate), A.19 (CN‑Spec plus direct comparison/selection owners), A.18 (CSLC), A.6.1 (declarations and actual bindings), A.15.1 (dated work and roles), C.2.1 (result epistemes), C.11 (decision results), A.10 (provenance and bounded reliance), B.3 (assurance), G.11 (currentness), E.18 + A.21 + F.9/F.17/E.17 (GateCrossing harness).

Uses (via Extensions): G.6 (EvidenceGraph/Path citation; when G.4:Ext.EvidenceGraphWiring is present), C.18 (NQD), C.19 (E/E‑LOG), C.23 (SoS‑LOG).

Used by: G.5 (selector/dispatcher), G.8 (SoS‑LOG bundles), G.9 (parity), G.10 (shipping), G.11 (refresh orchestration). Publishes to: UTS (public ids and public-id continuity records), RSCR (tests and trigger emissions), G.5 (handoff manifest), and, as cited payload, shipped packs governed by G.10.

Constrains: any run‑time LOG implementation that executes CAL operators/flows must treat CAL artifacts as citable specifications and must not re‑invent acceptance semantics.

#G.4:End

Last Updated: 2026-08-05 — upstream FPF commit 3dbce514 (github.com/ailev/FPF)