#ProblemCard@Context

C.22.2 · Cluster C.IV - Composite & Macro-Scale · Stable · Calculus (C) · Normative · Part C - Kernel Extension Specifications

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

Type: Calculus (C) Status: Stable Normativity: Normative

Plain-name. Context-bound problem card.

Intent. Give a practitioner one compact problem-side record that turns a messy problem signal into a reviewable problem-side record before downstream Principles-to-Work (P2W) or selector use, while leaving claims outside the card to the governing FPF patterns that govern those claims.

Use this when. Use this pattern when a signal, anomaly, drift, risk, hypothesis, stakeholder pressure, set-derived candidate, underused capability, new constraint, new environment, opportunity-like cue, or solution-shaped request must become reviewable before task typing, method-family selection, work planning, evidence use, gate passage, autonomy control, or P2W. Also use it when P2W would otherwise use a slogan, wish, ticket-shaped task, preselected work item, or solution-shaped task as if it were reviewable problem-side output.

Do not use this when. Use another pattern directly when the question under repair is already work planning, method selection, evidence, provenance, assurance, gate decision, autonomy, archive, selected-set governance, mathematical-lens use, or ordinary discussion with no project-side move.

Builds on. E.2, E.9, E.10, C.2.P, A.6.P, C.16.Q, C.16, A.19, C.22, C.25, C.29, G.5, G.9, A.6.3.RT, and A.6.4.

Coordinates with. C.11, C.18, C.19, C.22.1, C.24, C.27, C.28, A.15, A.21, E.16, G.6, G.11, A.10, B.3, E.17, E.17.ID.CR, A.6.3, F.9, and E.18.

Boundary summary. C.22.2 use starts from messy problem-side signals and yields one reviewable ProblemCard@Context, a P2W-ready problem-side input for downstream C.22, or a stop with a governing-pattern cue for the claim being made, relation, or boundary outside the card.

A working team can reach the beginning of development with symptoms, anomalies, stakeholder signals, constraints, risks, old solution evidence, comparison ideas, solution temptations, underused capabilities, new environments, and opportunity-like cues. Opportunity-like signals still need context, scope cut, not-wish reason, improvement or acceptance probe, and honest next move; they do not turn this pattern into an ideation pattern. If FPF only says "type the task" or "choose a method", P2W can start from a slogan, a ticket-shaped wish, or a solution-shaped task before the problem itself is reviewable.

#Keywords

• problem card
• problem-side record
• P2W-ready
• Thin problem card
• setContextRef
• problem signal
• support posture
• validation boundary
• first-principles cue
• safe-probe-needed
• freshness and unknown disposition.

#Relations

#Content

#Problem Frame

A working team can reach the beginning of development with symptoms, anomalies, stakeholder signals, constraints, risks, old solution evidence, comparison ideas, solution temptations, underused capabilities, new environments, and opportunity-like cues. Opportunity-like signals still need context, scope cut, not-wish reason, improvement or acceptance probe, and honest next move; they do not turn this pattern into an ideation pattern. If FPF only says "type the task" or "choose a method", P2W can start from a slogan, a ticket-shaped wish, or a solution-shaped task before the problem itself is reviewable.

Problematization becomes useful for FPF use when it makes the problem side explicit. A problem needs symptom detection, improvement check, acceptance probe or candidate acceptance criterion, mandatory constraints, risk condition, problem-formulation next-move reason, validation boundary, freshness or expiry, and a relation to candidate solution search. Many problems also arrive from a retained set: candidates, anomalies, hypotheses, non-dominated fronts, shortlists, selected sets, live pools, and retained stepping stones.

Current FPF already has patterns for archive, pool, front, selected set, parity, refresh, method selection, evidence, autonomy, gate, representation transition, bridge, and mathematical-lens use. The missing piece is a compact problem-side output that lets a practitioner see what is present before P2W use starts from the problem-side output and which current FPF pattern carries each heavier question.

The first-minute working question is:

Can I write or review a problem-side record that is specific enough to guide P2W, selection, acceptance, evidence, and first-principles or mathematical-lens use, while keeping archives, fronts, pools, selected sets, parity, evidence, autonomy, and work planning in their existing FPF patterns?

#Thin First Use and Output Kind

#Thin First-Use Form

The first substantive use of this pattern is the Thin form. It is a practitioner-facing prompt for writing the smallest reviewable problem card, not a demand to complete a field list.

A ProblemCard@Context is complete for its current use when it states:

1. why this signal matters now;
2. what problem representation is being carried under which context and scope;
3. why this is not merely a wish, ticket, slogan, or preselected work item;
4. what would count as improvement or an acceptance probe;
5. what the honest next move is.

The Thin form asks for:

• the problem signal or selected-problem cue: what made the practitioner stop before downstream task typing or work selection;
• context grounding and scope cut, including what is outside the current problem;
• the reason this is not merely a wish, slogan, ticket, or preselected work item;
• a provisional improvement check or acceptance probe;
• one honest next move: P2W-ready, characterize, compare, search, refresh, retire, archive, abstain/no-change, or apply the FPF pattern governing the named claim kind, relation kind, or boundary that changes the problem-card move.

If the Thin form lacks an improvement check or acceptance probe, it may preserve the signal and choose characterization, comparison, search, refresh, retirement, archive, abstain/no-change, or governing-pattern application for the claim being made; it must not declare P2W-ready.

Only after the Thin pass is legible, recover the output-kind boundary:

C.22.2 - ProblemCard@Context is the compact problem-side output under current C.22.

C.22.2 - ProblemCard@Context is the pattern heading. ProblemCard@Context is the C.22.2 problem-side record shape; an instance is a reviewable problem-side record before P2W. ProblemCard@ContextRef may be used as a reference form when downstream text cites such an instance, but it is not a separate durable kind unless a separate naming or kind decision approves one under F.18 and A.6.P. The Tech heading remains C.22.2 - ProblemCard@Context. Plain-register glosses or section-local practitioner labels may appear in this pattern, but those labels do not replace the Tech heading.

Local labels in this pattern are local to the C.22.2 record shape unless a separate accepted FPF naming or kind decision assigns them a broader FPF kind. This includes problem-formulation next-move reason, validation boundary, risk condition, solvability band, P2W-ready, reviewable, stale, refreshed, retired, archived, abstain/no-change, and firstPrinciplesCue; they do not create FPF kinds, gate statuses, state-machine kinds, or local mathematical-lens objects. When a claim outside C.22.2 is live, do not mint a local reference field for it; name the governing FPF pattern, claim kind named by value, project-side reference when known, and stop condition in the next move or source cue. When a mathematical or first-principles cue is live, cite C.29; local problem-formulation next-move reason names only why the problem formulation or structure cue is worth reviewing or moving onward from C.22.2; C.29 carries mathematical-lens use and the problem-formulation next-move reason for that lens.

Reference labels ending in Ref are reference roles, not object names. This includes ProblemCard@ContextRef, setContextRef, rivalProblemFormulationRef, and representationOrWordingUseRelationRef; do not shorten or promote them into local object kinds such as ProblemCardRef, SetContext, RivalFrame, or RepresentationRelation.

@Context means that the card is bound to declared context grounding: a named U.BoundedContext, a project-side context reference, or an explicitly bounded practice situation with recoverable local meaning. Domain or practice wording may identify the informative locus of the problem, but it does not replace context grounding. A broad label such as healthcare, education, engineering, research, or operations is not context grounding by itself. When domain or practice wording is used for context grounding, recover the named bounded context, project-side context reference, or explicit bounded practice situation and state what local meaning or rule is being used. The card does not assert global problem identity outside that declared context grounding.

Plain gloss for P2W-ready: problem-side input ready. It means ready as input to downstream P2W or selector reasoning, not ready to execute work, pass a gate, or select a method.

#Required Solution Moves

The C.22.2 Solution is organized around practitioner moves from signal to reviewable problem to one admissible next move, not around schema completion.

1. Capture the symptom, anomaly, risk, stakeholder cue, drift, hypothesis, or other source signal before naming the problem.
2. Stabilize the cheap problem-side record: context grounding, scope cut, EntityOfConcern when it changes the problem-side move, primary viewpoint or role concern, and provisional problem framing.
3. Make action possible by separating the symptom detector, improvement check, candidate acceptance criterion, optimization target when live, monitored risk signal when live, and proxy-distortion risk when an indicator can be gamed or substitute for value; then state mandatory constraints, risk condition when live, and intended next move before downstream selection.
4. Pay only for live complexity: add conditional fields only when their kind is live for the problem-card move; otherwise stop at the lighter card or name the governing FPF pattern and claim kind named by value that must be used next.
5. Run the representation-continuity check: if the problem formulation changes the EntityOfConcern, representation scheme, diagram, functional description, or TGA path interpretation, name the representation-transition, retargeting, bridge, structural-reinterpretation, or wording-use relation before reusing an inherited local cue or readiness disposition.
6. Close by the honest next move rather than by a completed form. A filled card without a truthful next move is not a successful C.22.2 result.

Cheap-stop rule: the smallest card that gives a truthful next move is sufficient. A conforming C.22.2 use must not require heavier fields merely because the full field list exists.

First practitioner pass before governing-pattern cues:

1. Capture the problem signal or selected-problem cue, context grounding, and scope cut.
2. State why it is not merely a wish, slogan, ticket, or preselected work item.
3. State the provisional improvement check or acceptance probe.
4. Choose the honest next move. Use the relation boundary aid only when a conditional relation is live.

This is the Thin-form writing order, not a completion sequence for the whole pattern. It adds no fields; it keeps the practitioner on the smallest truthful card before Standard or High-relation material is paid for.

#Relation Boundary Aid

Use this aid only after the Thin ProblemCard@Context is legible: signal, context grounding, scope cut, not-wish reason, improvement check or acceptance probe, and honest next move. It is not a second writing order and not a catalogue of other patterns. It answers one question:

Which claim being made, relation, or boundary changes the problem-card move, and which FPF pattern governs that item?

If the item does not change the current problem-card move, leave it out of the card. If it does change the move, keep only the local cue or reference that makes the card reviewable, then apply the governing pattern for that claim, relation, or boundary.

Over-capture symptom: the practitioner spends the pattern use classifying FPF patterns while the problem signal, context, scope, improvement check, acceptance probe, and next move remain unstable.

Repair: return to the Thin problem-side action. State the signal, context, scope, why this is not merely a wish, ticket, slogan, or preselected work item, the improvement check or acceptance probe, and the honest next move. Reopen this aid only for the claim, relation, or boundary that changes that move.

#Use Boundaries and Profiles

Use C.22.2 when a signal must become a problem-side record before downstream task typing, P2W, method-family selection, work planning, evidence use, gate passage, autonomy control, or selected-set use. A known method does not close this pattern when the problem signal, scope, acceptance probe, or EntityOfConcern remains unstable.

Use another pattern directly when the question under repair is already that pattern's EntityOfConcern or governed relation: A.15 for work planning or performed work, A.10/G.6/B.3 for evidence, provenance, or assurance, A.21 for gate decision, E.16 for autonomy, C.11 for a local choice among explicit options, and C.18/C.19/G.5 for archive, pool, front, or selected-set governance. C.22.2 may still preserve the problem-side cue or reference that explains why that pattern is now live.

Use profiles as record budgets:

• Thin profile: signal, context grounding, scope cut, not-wish, not-slogan, not-ticket, or not-preselected-work reason, provisional improvement check or acceptance probe, and one honest next move.
• Standard profile: Thin fields plus the live comparison, acceptance, risk, validation, freshness, unknown-handling, or P2W-readiness fields needed for downstream use.
• High-relation profile: Standard fields plus only the relation references needed when public, disputed, high-risk, set-derived, cross-context, evidence-adjacent, autonomy-adjacent, gate-adjacent, agentic, temporal, causal, representation, or Part-G relations are live.

Stop at Thin when it gives a truthful next move. Stop at Standard when it is enough to emit or bind a minimal TaskSignature, TaskKind, or ProblemProfile. Apply the governing FPF pattern for the claim being made, relation, or boundary instead of enlarging the card when the issue under repair is no longer the problem-side record itself.

#Field Labels and Liveness

The first problem-side move is to make one problem usable before P2W by stating these field labels when they are live for the case:

• problem signal;
• source signal reference: prior solution-use evidence, environmental drift observation, new constraint, new environment, underused capability, opportunity-like cue, risk signal, anomaly, hypothesis, stakeholder signal, accepted local theory, or safe-probe or environment cue;
• domain or practice locus when helpful, plus the context grounding that carries local meaning;
• EntityOfConcern or project-side FPF kind or reference named by value when it changes the problem-side move;
• context grounding;
• primary viewpoint or role concern;
• scope cut;
• symptom detection;
• problem hypothesis or cause-theory cue;
• rival-frame reference when multiple plausible problem frames remain live;
• improvement check;
• comparison-and-acceptance cue or acceptance-criterion reference;
• characterization relation;
• characteristic or Q-bundle relation;
• indicator selection;
• comparability or parity relation, or explicit current reason it is not needed;
• mandatory constraints;
• risk condition;
• problem-formulation next-move reason;
• validation boundary;
• freshness or expiry condition;
• unknown handling;
• setContextRef when a set, pool, front, archive, shortlist, selected set, or portfolio context is live;
• firstPrinciplesCue for a first-principles or mathematical structure cue that changes problem formulation;
• governing-pattern cue when a claim outside C.22.2 changes the problem-card move: governing pattern for that claim, relation, or boundary; claim kind named by value; project-side reference when known; and stop condition;

Field liveness for C.22.2 is determined as follows:

Field absence rule: if a conditional field kind is not live, the field is absent, not unknown. Use unknown only for a live field whose value is currently unknown. If a live value is unavailable, state whether the next move is blocked, degraded, sandboxed, or requires the FPF pattern governing the named claim kind before that use. If a value is stale, use the freshness or expiry disposition in C.22.2:12 and G.11. If a field is intentionally omitted, state the record-budget reason and do not imply that the omitted kind has been checked. A minimal ProblemCard@Context contains the always-core fields; conditional fields are added only when live for the problem-card move.

When the card compares options, selected-set members, retained candidates, or rival problem formulations, it must state the live comparison or parity relation, or state why comparison is not live for the current move. Absence of a parity relation is not automatically a defect; it is a disposition. The admissible result is either parity not live for the current card, or a G.9-governed parity relation before P2W-ready is claimed. A local fair-comparison result or selected-set result is not admissible inside C.22.2.

A conforming C.22.2 use includes minimal source and context witness material when source, set, selection, characterization, parity, freshness, representation relation, or wording-use relation is live. Otherwise a Thin card may cite the observed signal in plain form. The field-group label problemCardSource may be used inside the pattern, but it is not a new FPF object and not an evidence graph. It is a recoverability field group for source cues and project-side references that make the problem-side record reviewable:

problemCardSource:
  sourceSignalRef?
  setContextRef?
  selectionOrRetentionCriterion?
  characterizationRelationRef?
  parityRelationRef?
  freshnessRef?
  representationOrWordingUseRelationRef?

Generated problem variants, evaluator feedback, and open-ended problem mutation may be recorded only as sourceSignalRef, selectionOrRetentionCriterion, or setContextRef when they make the problem-side record reviewable. They do not provide problem-side validity, evidence sufficiency, or permission to probe or act.

#Anti-Pattern Checks and Worked Slices

Anti-pattern checks start from the local card move:

• card-as-work-item: the card is treated as executable work while method, plan, and work occurrence remain undecided;
• form-completion: every field is filled because the template exists, even though the Thin next move would be truthful;
• readiness shortcut: P2W-ready is declared from signal and scope alone, without improvement check or acceptance probe;
• source-claim shortcut: a preselected solution, work item, proof-looking reference, gate-looking cue, or permission-looking cue replaces the problem-side signal, context, scope, acceptance probe, and next move;
• scalar shortcut: archive, set-return, Goldilocks, NQD, OEE, partial-order, stepping-stone, or indicator material collapses into one readiness score;
• prestige shortcut: first-principles or mathematical wording is kept without practical payoff, preserved/lost structure when live, problem-formulation next-move reason, and stop condition.

Local stop rule: if the encountered material tries to carry a claim outside C.22.2, the card keeps only the cue or reference that changes problem formulation or the next move, then names the governing FPF pattern and claim kind named by value to use before that claim is relied on.

A conforming C.22.2 use is testable against at least one Thin worked slice, such as repeated task rework or another compact source signal, showing signal, context, not-preselected-work reason, improvement check, and next move. It is also testable against at least one High-relation worked slice from a set, archive, pool, front, shortlist, selected set, or portfolio context, showing setContextRef, candidate acceptance criterion, risk condition, and the claim being made, relation, or boundary without creating a local portfolio or archive kind.

#Conformance Checklist Requirements

The checklist protects a completed or reviewed card from overread. It is not the writing order and not a gate. The writing order remains Thin form, honest next move, and relation references only when they change the move.

#Problem-Kind Recovery

For this decision, problem remains an ordinary word in non-FPF-governed prose. Recovery is required only when the wording changes an admissible move, FPF kind, FPF relation kind, downstream selector reference, evidence claim, causal-use claim, bridge claim, assurance claim, decision claim, admissibility claim, or another exact governed claim. The preferred center is the framed problem representation: a problem-side representation of a selected EntityOfConcern under context, scope, viewpoint or role concern, constraints, and improvement or acceptance probe. When problem carries FPF work, selection, evidence, causal, bridge, assurance, decision, or admissibility claim, it must be recoverable through this table:

Local interpretation rule: ProblemCard@Context is the problem-side record shape before downstream typing or work. It may name candidate ProblemProfile, candidate TaskSignature, setContextRef, source cue, governing-pattern cue, or first-principles cue material only when those references change the problem-card move. It does not promote those references into local objects or claims outside C.22.2.

#Problem, Task, Method, Work, and Result Split

ProblemCard@Context is admissible while the method is unknown, contested, not yet selected, or not yet specific enough for downstream work. A known method does not by itself make the problem ready: if the proposed method is known but the problem signal, scope, acceptance probe, or EntityOfConcern remains unstable, C.22.2 remains live. If both the problem representation and the method are already accepted and the remaining question is planned execution, apply A.15. The card may carry method-family cues and reasons for method search, but it must not present downstream work as already known task execution.

Use this split:

Transition condition: ProblemCard@Context may prepare a candidate ProblemProfile, bind an existing ProblemProfile, emit a candidate TaskSignature, or bind a TaskSignature only when P2W or selector readiness is declared. If several downstream signatures remain plausible, keep them as candidate signatures instead of binding one chosen TaskSignature. When the issue under repair becomes method-family selection, selected method, planned work, performed work, result record, or result measurement, apply the governing FPF pattern for that claim; do not expand the card.

#Relation to C.22

C.22 remains the foundation for ProblemProfile, TaskKind, TaskFamilyRef, and TaskSignature. ProblemCard@Context is earlier and more explicit: it explains why this problem, under this context, is admissible for P2W, search, comparison, characterization, refresh, retirement, or governing-pattern application.

A ProblemCard@Context may prepare a candidate ProblemProfile, bind an existing ProblemProfile, emit a candidate TaskSignature, or bind a TaskSignature only when P2W or selector readiness is declared. If several downstream signatures remain plausible, keep them as candidate signatures instead of binding one chosen TaskSignature.

This relation does not move problem-card field detail into TaskSignature. TaskSignature stays minimal for eligibility, acceptance, and selection. Downstream method, work, result, evidence, gate, autonomy, archive, portfolio, and selected-set claims remain with their governing patterns.

#Characterization, Indicators, and Comparability

ProblemCard@Context must state either a recoverable characterization relation and comparability or parity relation, or an explicit current reason why the problem can proceed without one.

The heavy content stays with existing FPF patterns:

• C.16 carries measurement characterization, backing, and comparability discipline;
• A.19 carries characteristic, scale, unit, polarity, and indicator admissibility discipline;
• C.25 carries Q-bundles and quality-like multi-characteristic bundles;
• G.9 carries parity, comparison-window, comparator, budget, unit, repeatability, and reproducibility pins;
• G.0 carries comparison-frame and CG-Spec governance;
• G.4 carries acceptance clauses and threshold predicates;
• G.5 governs selected-set publication when the problem enters a selected set.

Missing characterization or parity relation is a current disposition. The record applies the characterization, parity, search, or pool pattern when that relation is live instead of pretending the problem is ready for P2W.

The C.22.2 candidate acceptance criterion must distinguish functional check, constraint compliance, risk or safety boundary, parity or comparison relation, and freshness window when those relations are live. Comparison frame, CG-Spec, or comparability governance is governed by G.0. Acceptance clauses and acceptance threshold predicates apply G.4; C.22.2 may name only the need, cue, or reference. Passing a test, improving one observed indicator value, or naming an acceptance phrase is not by itself admissible acceptance for P2W.

#Source Record-Form Recovery

Source record names are recovered by use, not by label shape. This section prevents source prose from becoming local C.22.2 subobjects.

| Source form family | C.22.2 preservation | Governing pattern named by value for outside use | |---|---|---| | Problem card, problematization passport, problem-side note, or ordinary source signal | Carry the problem signal, context grounding, scope cut, improvement check or acceptance probe, and next move. | C.22.2 governs only the problem-side record shape; downstream selector-facing use remains with C.22. | | Archive, portfolio, palette, front, shortlist, selected set, live pool, set-return, or retained candidate | Preserve setContextRef, source-set kind, selection or retention criterion, budget/window when live, and non-scalar next move. | C.18, C.19, G.5, G.9, G.11, A.6.P:7a, and C.16.Q according to the relation named by value. | | Characterization passport, characteristic card, parity plan, comparison note, rule-of-choice card, or acceptance-looking row | Preserve the cue, candidate criterion, comparator/window cue, and current reason the relation changes formulation. | C.16, A.19, C.25, G.0, G.4, G.9, or C.11 according to the relation named by value. | | Evidence pack, provenance note, assurance row, gate log, autonomy budget, runbook, rollback plan, method selection, work plan, performed-work note, result record, or result measurement | Preserve only the problem-side cue, risk or validation boundary, source reference, and stop condition before that use. | A.10, G.6, B.3, A.21, E.16, G.5, A.15, C.16, or G.11 according to the claim named by value. | | Candidate solution, described system, ordinary log, budget, ledger, protocol, plan, pack, or factory wording | Recover the use under repair: problem-side source, selected-set material, work/evidence/gate/autonomy material, or ordinary example. | Apply the governing pattern for the recovered relation; do not mint a local C.22.2 kind from the label. |

The repair rule is short: if the source form supplies problem-side material, copy the material into the card's live fields. If it supplies another FPF-governed claim, keep only the local cue and apply the pattern that governs that claim.

#Portfolio, Archive, and Set-Return Treatment

Archive, portfolio, pool, front, shortlist, selected-set, and set-return material remain source and set cues for the current problem-side record. ProblemCard@Context preserves setContextRef, source-set kind, selection or retention criterion, and the non-scalar next move when live; portfolio and archive governance stays with the named governing patterns and does not become a local problem-card kind.

Archive, portfolio, palette, front, shortlist, ranked shortlist, selected set, live pool, and set-return material remain live source distinctions, but their current FPF governing patterns are already available:

A singleton problem card is the degenerate case. If it came from a portfolio, front, archive, or pool, the selected problem remains traceable through setContextRef: the lightweight reference to the source set kind, source reference, selection or retention criterion, budget or window, review cadence, and pattern reference named by value when live. setContextRef is a reference field, not a new SetContext kind and not a downstream claim carrier.

setContextRef must preserve the recoverable source-set form when live: Palette, Front, Archive, ExplorationArchive, Shortlist, RankedShortlist, SelectedSet, LivePool, or another accepted source-set form. If the source-set form is not recoverable, the card may keep a source cue, but it must not claim selected-set readiness or archive-derived readiness.

When multiple plausible problem formulations remain live, C.22.2 must not bind one TaskSignature prematurely. Each optional rivalProblemFormulationRef must state the rival formulation, EntityOfConcern, context, preserved concern, lost concern, reason not selected yet, and next discrimination move. It is not a CG-Frame, not the E.8 Problem Frame, and not a representation-frame object. The next discrimination move may be to characterize, compare, retarget, reopen the source, choose a local problem formulation, or apply the relation-bearing pattern. Reframing is triggered when context grounding, EntityOfConcern, viewpoint, scope cut, or cause-theory cue changes the problem representation enough that readiness or admissibility cannot be inherited by wording continuity.

#Goldilocks and Set-Return Docking

Goldilocks problem selection is the problem-side adaptation of the current NQD, OEE, and set-return family. It is not direct QD or OEE vocabulary import, not a new scalar readiness doctrine, not a local QD or OEE vocabulary, and not a single score. C.22.2 must not mint GoldilocksProblem, GoldilocksScore, GoldilocksReadiness, or any equivalent local kind; Goldilocks remains a readiness and selection interpretation carried by current governing patterns.

A Goldilocks, stepping-stone, or archive-derived problem must be represented as source context or set context, selection or retention criterion, and current next move, not as problem difficulty, priority, or readiness score.

ProblemCard@Context carries only the problem-side readiness fields and relation references:

• source set kind when archive, pool, front, shortlist, selected set, or portfolio language is live;
• solvability band;
• characteristic-space, declared problem-side characteristic descriptor, or Q-bundle relation;
• declared difference criterion when novelty or diversity is claimed, or apply the governing characterization or comparison pattern;
• non-scalar trade-off, dominance, partial-order, or set-return relation when that relation is being made;
• measurability or explicit unknown handling;
• reversibility or containment for safe probing when live;
• stepping-stone option value when retention matters;
• expiry or refresh condition;
• selected-set, archive, pool, front, or parity relation when that relation is being made.

The local solvability band label means a context-bound, non-scalar interpretation of feasible-but-not-trivial fit under current capability, constraints, validation boundary, and optional set-return relation. It is not a universal difficulty claim, not a hidden readiness scale, and not a single-score ranking.

If the band cannot be tied to a characteristic, Q-bundle, comparison, retention, or capability-context cue, treat Goldilocks wording as informal recognition only and bind any selection, set-return, or parity claim to the governing FPF pattern for that claim.

The current governing family is C.18, C.19, G.5, G.9, G.11, A.6.P:7a, and C.16.Q. The relation to C.22:14 is a role and timing relation inside the same family: C.22.2 uses the family before P2W, while C.22:14 uses it downstream when candidate solutions for a TaskKind make TaskSignature informative.

#Structure Cue That Improves Formulation

C.29 carries mathematical-lens use for first-principles or mathematical structure cues used by ProblemCard@Context.

firstPrinciplesCue is a local cue label for a formulation-changing structure and a cue to apply C.29; it is not a local mathematical-lens kind or a substitute for a C.29 lens-use result.

The problem card may ask whether a first-principles or mathematical structure helps find or improve the problem formulation, not only whether an already-mentioned mathematical object is admissible. Useful cues include state space, graph, boundary, topology, symmetry, invariant, variational or constrained-optimization structure, probability or information structure, resource bound, obstruction, scale window, composition, or coarse-graining choice.

The admissible practitioner move is:

State the structure that improves the problem formulation, the preserved structure, the lost structure, the practical payoff, the problem-formulation next-move reason, and the stop condition.

Distribution by principles:

When no useful mathematical structure survives, record that absence and proceed without forcing mathematical prose into the problem card.

#Validation, Reliance, AI-Agent Pressure, and Safe Probing

ProblemCard@Context exposes three local fields for downstream use:

• problem-formulation next-move reason: why this formulation is worth keeping, reviewing, discriminating, or moving onward now;
• validation boundary: what has been checked for the current next move, what may be used now, and which use needs another pattern;
• risk condition: the monitored risk, cost-of-error concern, or containment concern that may change the safe next move.

Use these fields to state a local reliance disposition, not to authorize downstream action.

Cause-theory cues may focus problem formulation inside ProblemCard@Context. Association, intervention, counterfactual, responsibility, expected-effect, or causal-evidence claims are governed by C.28 plus evidence, provenance, or assurance patterns when those claims are being made.

Environment design and safe probing may appear as source signal reference, validation boundary, risk condition, or governing-pattern cue. If the next move can affect a controlled object, the card names the probe need plus the claim kind named by value that blocks local action; it does not authorize the probe locally.

#Freshness, Expiry, and Unknown Handling

C.22.2 includes a section-local state and disposition vocabulary for ProblemCard@Context; this vocabulary is not a new FPF kind. These labels describe the card's current admissible use; they are not required states in a transition sequence, event kinds, or gate records. The local labels are:

Freshness must name the affected locus: problem signal, context, characterization or parity relation, problem-formulation reason or source, set-source reference, representation relation, or wording-use relation. For the problem-signal locus, ask whether the original signal is still present, recurring, solved, absorbed, duplicate, unnecessary, or no longer worth downstream work. For context, ask whether the local context or scope cut has changed enough to alter the formulation. For characterization or parity, ask whether measurement, comparison, and parity relations are current enough for the intended next move. For problem-formulation reason or source, ask whether cited sources, provenance, and stated reason/source references are fresh enough for the problem-formulation next-move reason. For set-source reference, ask whether archive, front, pool, shortlist, or selected-set membership and the selection or retention criterion are still current. For representation relation or wording-use relation, ask whether wording, diagram, functional description, TGA path, bridge, retargeting, or representation change alters the EntityOfConcern, admissibility inheritance, context grounding, viewpoint or role concern, scope cut, comparison relation, admissible next move, or relation needed for inheritance.

A stale source or evidence reference does not always retire the problem; it may require refresh while the problem remains reviewable. A stale problem signal may lead to refresh, retire, archive, abstain or no-change, or a governing-pattern cue for the claim, relation, or boundary that must be checked.

Freshness or expiry failure is a current disposition. A stale or unknown-bearing problem card may remain reviewable as a problem-side record, but it does not become P2W-ready unless freshness and unknown handling permit the intended downstream move. A stale problem card does not silently remain admissible for P2W.

When freshness, expiry, or unknown handling fails, choose one of these current dispositions:

• refresh the problem card or its characterization or comparison relation under G.11, C.16, A.19, C.25, or G.9;
• retire or deprecate the problem-side record under the relevant archive, pool, selected-set, or refresh pattern;
• continue only as explicitly governed bounded-risk use under the governing pattern for the claim being made, relation, or boundary.

Unknown-handling fields must state whether they permit use, require degraded use, abstention, or sandbox treatment, or make the current problem formulation inadmissible. No P2W, no change, or abstain-for-now may be a successful next move when the signal is stale, duplicate, already solved, already absorbed, unnecessary, or not currently worth downstream work. Before ProblemCard@Context emits or binds TaskSignature, it must check whether the problem signal is still present and whether prior work has already solved or removed the problem.

#Representation and Wording-Use Relation Continuity

C.22.2 names A.6.3.RT, A.6.4, E.17, F.9, E.18, and E.10 only when changed problem formulations, diagrams, functional descriptions, TGA paths, wording, or PathSlice examples carry a live representation, bridge, retargeting, structural-reinterpretation, or wording-use claim. The card may preserve the local cue, reference, or problem-formulation next-move reason, but it does not prove continuity or admissibility inheritance by wording similarity.

Framing is not wording repair. A framing change applies when EntityOfConcern, context grounding, scope cut, viewpoint, comparison relation, admissibility inheritance, or honest next move changes. Wording-use repair is live only when wording, diagram, functional description, TGA path, bridge, retargeting, or representation change alters the carried problem-side representation, EntityOfConcern, admissibility inheritance, context grounding, viewpoint or role concern, scope cut, comparison relation, admissible next move, or governing-pattern cue. Ordinary wording cleanup does not trigger a representation-continuity relation and does not block a Thin ProblemCard@Context.

C.22.2 may not treat changed-problem examples as admissible relations unless the appropriate accepted FPF relation is named.

#Source and P2W Carry-Forward

The source presentation is not compressed into a generic problem-card summary. The following source details become carry-forward constraints for C.22.2 use and for the P2W-facing relation from C.22.2.

This carry-forward preserves detail, not broader scope. C.22.2 remains the problem-side output; P2W uses it with enough source cues and project-side references to select method families, plans, performed work, and result measurement without making the problem card a P2W pattern.

#SoTA Decision-Use Source Material

The following external anchors are adopted or adapted only where they change this pattern's local answer by value.

If a C.22.2 use carries a wider external claim than these dispositions, the claim is outside this pattern and requires a separate content decision or demotion to a non-FPF-governed example.

Each FPF-governed SoTA use is recovered as a local test: source idea, FPF invariant, practitioner check, and popular shortcut rejected. A source citation without that local test is not enough to carry pattern use.

Local SoTA-to-action tests:

#Rationale

ProblemCard@Context gives the practitioner one compact problem-side record between vague problem talk and downstream P2W. The card is useful because it is light enough for ordinary use and exact enough to show when comparison, characterization, evidence, selection, mathematical-lens use, method, work, gate, autonomy, bridge, representation transition, or refresh must apply another FPF pattern.

The card gives the practitioner one thing to write, inspect, and challenge. A practitioner can see whether a problem is ready without first assembling the problem-side record from TaskSignature, Q-bundle, parity report, evidence note, selected-set output, and refresh record. Claims beyond the problem-side record stay with their governing patterns.

The archive and portfolio distinctions remain live when they matter because the card preserves setContextRef and names the governing pattern for any live set, archive, or portfolio claim. Changed problem formulations, diagrams, functional descriptions, or TGA path interpretations require the accepted representation or retargeting relations before a local cue or readiness disposition is reused. Current SoTA and first-principles cues matter only when they change fields, relation references, boundaries, or the problem formulation itself.

#Problem-Card Use Invariants

#Misuse Modes and Repairs

#Use-Quality Checks

These checks protect the card's practical use; they do not add fields.

#Worked Slices and Anti-Cases

#Five-Case Worked Slices

#Compact P2W-ready Disposition Slice

A support team sees repeated failed hand-offs after a new interface policy. The incoming request says "rewrite the escalation workflow." A conforming ProblemCard@Context first repairs the problem-side record instead of accepting the work-shaped request.

The P2W export is narrow: accepted problem-side material, context grounding, improvement check, validation boundary, freshness condition, and governing-pattern cues. If the improvement check or acceptance probe is missing, the card stays reviewable-only or source-finding and cannot claim P2W-ready. If the next user wants evidence sufficiency, a gate decision, work authorization, or selected method, the card preserves the cue and the corresponding governing pattern carries that later claim.

#Anti-Cases

#Machine-Assisted Drafting Boundary

Machine-assisted ProblemCard@Context drafting is admissible only as drafting aid. Before the draft is used for P2W or selector-facing work, a practitioner checks the card's local fields and any governing-pattern cues for claims outside C.22.2.

Required practitioner checks for a machine-assisted draft:

• source signal;
• improvement check or acceptance probe;
• problem-formulation next-move reason;
• unknown handling;
• freshness or expiry disposition;
• governing-pattern cues for claims being made, relations, or boundaries outside C.22.2.

#First Practical Entry Aid

This section is a discoverability aid only. It helps a practitioner or assistant find a candidate pattern; it does not prescribe a transition sequence and does not require opening C.22.2 for every problem-sounding text.

These likely practitioner entry phrases point to C.22.2:

• "We have a problem, but it is not yet clear what work should be done."
• "This looks like a ticket, but I am not sure the problem is stated."
• "A signal or anomaly keeps recurring before method selection."
• "We selected this candidate from a front, archive, pool, or selected set, but need to state why it is a problem now."
• "P2W would otherwise use 'implement X' as if it were reviewable problem-side output."
• "There is a symptom, but we do not yet know what to solve."
• "We need to know whether this problem is ready for P2W or should apply another pattern."

Direct-entry cues that are not C.22.2:

• accepted method or work planning: use A.15;
• proof, provenance, reliability, or assurance claim: use A.10, G.6, or B.3;
• local choice among explicit options: use C.11, or G.5 when set publication or selected-set semantics are live;
• agent tool-call, gate, or autonomy claim: use C.24, E.16, or A.21; ProblemCard@Context may only name the problem-side cue or relation named by value;
• ordinary discussion with no downstream project-side move: no C.22.2 use.

First-use Thin-card test:

Given a messy signal, a practitioner must be able to produce a Thin ProblemCard@Context in under one page and correctly choose one admissible next move: P2W-ready, characterize, compare or parity, search or pool, refresh, retire, abstain/no-change, or apply the FPF pattern that governs the claim being made, relation, or boundary outside the card.

Entry relation:

The entry relation is local: C.22.2 is introduced under C.22, and C.22 names the ProblemCard@Context relation. The C.22.2 body carries the Problem frame, first-entry phrases, tempting-wrong-pattern boundaries, and first-use Thin-card test needed for ordinary discovery.

#Downstream Cue Export

ProblemCard@Context exports problem-side material, not a claim over downstream use.

The compact export fields are:

• problem signal and context grounding;
• EntityOfConcern and scope cut when they change the move;
• improvement check or acceptance probe;
• readiness disposition: reviewable-only, P2W-ready, no-work or abstain/no-change, refresh, retire, archive, or governing-pattern application cue;
• source-set or representation relation reference when live;
• problem-formulation next-move reason and validation boundary when P2W relies on the card.

For P2W carry-through, use E.18.1 with the accepted problem-side material and the live relation named by the card. For selector-facing readiness and candidate TaskSignature relation, use C.22. For selected-set or search cues, use G.5 only when that relation is live. For work need, use the A.15 family only after work planning, performed work, or work-relevant source restoration is live. For any other claim being made, apply the pattern that governs it; do not treat the whole card as carrying that claim.

#Consequences

#Benefits

• FPF gains a clear problem-side output for problematization as the input P2W can use.
• P2W uses a typed problem-side record rather than a slogan, ticket-shaped wish, or preselected method.
• C.22.2 has practical value for FPF when it reduces at least one expensive failure: a wish enters P2W as TaskSignature; a preselected work item is treated as the problem; method selection happens before the problem is reviewable; a problem from a set loses setContextRef; an indicator is used without admission; problem-formulation next-move reason is cited as proof; a stale problem remains active; scalar readiness replaces set-return; or the problem-formulation next-move reason is inherited across a changed representation without the governing representation-continuity or wording-use relation.
• Current archive, pool, front, shortlist, set-return, parity, refresh, evidence, and C.29 patterns are reused instead of duplicated.
• The positive role of mathematical and first-principles thinking is preserved: it can find missing structure, not only check already-written mathematics.
• Characterization and parity are no longer optional background when they are prerequisites for problem reviewability.
• Representation-change relations are handled through named relation references rather than local proof inside the problem card.

#Costs of Use

• A ProblemCard@Context adds a small writing step before P2W. The cost is justified only when the signal must become reviewable before downstream use.
• The practitioner must keep the card small: preserve the split between problem, task, method, work, and result; keep TaskSignature minimal; and add conditional fields only when their relation is live.
• For problems emitted from archives, pools, fronts, selected sets, or portfolios, the practitioner must preserve setContextRef or the set-source relation without turning the card into a portfolio, archive, selected-set, or work-planning object.
• External or source-local terms may guide recognition only when they change a concrete boundary, field, relation, or validation obligation. Otherwise they remain examples or source cues.

#Relations

• Builds on: E.2, E.9, E.10, C.2.P, A.6.P, C.16.Q, C.16, A.19, C.22, C.25, C.29, G.5, G.9, A.6.3.RT, and A.6.4.
• Coordinates with: C.11, C.18, C.19, C.22.1, A.15, A.21, E.16, G.6, G.11, A.10, B.3, E.17, E.17.ID.CR, A.6.3, F.9, E.18, and E.18.1.

#C.22.2:End

Last Updated: 2026-06-08 — this section last modified in upstream FPF commit 21e2101c (github.com/ailev/FPF)