#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-memory 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 can turn a messy problem signal into a reviewable problem-side record before downstream Principles-to-Work (P2W), without moving archive, portfolio, selected-set, evidence, autonomy, gate, method, or work authority into the card.

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 receive a slogan, wish, ticket-shaped task, preselected work item, or solution-shaped task.

Do not use this when. Do not use this pattern as a work plan, method selection, evidence pack, gate decision, autonomy permission, archive, portfolio, selected set, parity report, mathematical adequacy record, or general discussion note. Use the neighboring pattern that carries the live relation.

Builds on. E.2, E.9, E.10, E.10.SEMIO, A.6.P, A.6.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 named neighboring exit. C.22 keeps the selector-facing TaskSignature; neighboring patterns keep authority for characterization, comparison, acceptance, archive and set relations, evidence, gate, autonomy, work, representation, temporal, causal, and mathematical relations. C.22.2 does not govern those receiving relations.

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 ideation authority. If FPF only says "type the task" or "choose a method", P2W can receive 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 ideation authority. If FPF only says "type the task" or "choose a method", P2W can receive 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 basis, mandatory constraints, risk posture, support posture, 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 adequacy. The missing piece is a compact problem-side output that lets a practitioner see what is present before P2W receives the problem 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 support, 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 a named neighboring-pattern exit.

If the Thin form lacks an improvement check or acceptance probe, it may preserve the signal or exit to characterization, comparison, search, refresh, retirement, archive, abstain/no-change, or a neighboring pattern, but 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-governed 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 or authority. This includes support posture, validation boundary, risk posture, solvability band, P2W-ready, reviewable, sentToNeighbor, 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 mathematical or first-principles cue is live, cite C.29; local support posture names only why the problem formulation or structure cue is worth reviewing or moving onward from C.22.2; C.29 carries mathematical-lens adequacy and the support posture for that lens.

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

@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 carries semantic load, 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, described entity when load-bearing, primary viewpoint or role concern, and provisional problem framing.
3. Make action possible by separating the symptom detector, improvement check, candidate acceptance basis, 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 posture when live, and intended next move before downstream selection.
4. Pay only for live complexity: add conditional fields only when their relation is live, and otherwise name the neighboring-pattern exit or stop at the lighter card.
5. Run the representation-continuity check: if the problem formulation changes the described entity, representation scheme, diagram, functional description, or TGA path reading, name the SEMIO exit before using inherited support.
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 neighboring exits:

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 neighboring-exit 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-load relations are paid for.

#Neighboring-Exit Aid

Use this exit aid when a live relation appears while writing or reviewing a ProblemCard@Context.

Neighboring exits are authority boundaries, not orchestration steps. The aid names the receiving pattern where authority already lives; it does not give C.22.2 authority over that pattern or make the neighboring relation local to the card.

Cue and abductive-entry boundary: use C.22.2 only when the cue can be scoped as a problem-side representation with an improvement check, acceptance probe, or honest next move. If the material is still only a partly stated cue, several candidate meanings, or an explanation-ready prompt without problem-side scope, preserve it under A.16.1, B.4.1, or B.5.2.0 before forcing ProblemCard@Context.

When A.16.1, B.4.1, or B.5.2.0 has preserved or typed the cue, C.22.2 may receive that cue only to stabilize one problem-side record with context, scope, improvement check or acceptance probe, and honest next move. It does not replace cue preservation, entry-load typing, or abductive prompt handling. Failure mode: receiving-table over-capture. The practitioner spends the pattern use classifying neighboring patterns, or trying to fill every receiving-pattern column, while the problem signal, context grounding, scope cut, not-wish reason, improvement or acceptance probe, and honest next move remain unstable.

Repair: return to the Thin problem-side action. State the signal, context and 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. Use the exit aid only after that Thin record exposes a live relation that needs a receiving pattern.

#Use Boundaries and Profiles

Use this pattern when a signal, anomaly, drift, risk, hypothesis, or stakeholder pressure has appeared and the team must decide whether a problem-side record is needed before downstream task typing. Also use it when P2W would otherwise receive a slogan, wish, ticket-shaped task, preselected work item, or solution-shaped task; when the method is unknown, contested, or not specific enough for task typing, method-family selection, or work planning; or when the problem must become reviewable before method selection or P2W can honestly receive it.

Do not use this pattern as a work-planning record. If the method is already accepted and only work planning is live, use A.15. If evidence, proof, provenance, or assurance is central, use A.10, G.6, or B.3; C.22.2 may name only a support cue or support posture. If gate passage or a gate decision is central, use A.21; C.22.2 may name only a gate cue or neighboring exit. If the live issue is a local choice among explicit options, use C.11 rather than treating the choice as problem-card completion. If archive, front, pool, selected-set, or portfolio governance is central, use C.18, C.19, or G.5; C.22.2 may only preserve the setContextRef or set-source cue needed for the singleton problem-side record. If the conversation is only ordinary discussion with no downstream project-side move, do not use C.22.2.

Use profiles:

• Thin profile: signal, context grounding and 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: the Thin profile plus live fields needed when P2W or selector-facing use is likely: comparison-and-acceptance cue or acceptance-basis reference, mandatory constraints, risk posture, support posture, validation boundary, freshness or expiry, unknown handling, and named neighboring exits.
• High-load profile: conditional for public, disputed, high-risk, set-derived, cross-context, semio-transformed, evidence-adjacent, autonomy-adjacent, gate-adjacent, agentic, or Part-G-facing cases. It adds references and exits such as setContextRef, characterization, parity, support, evidence, gate, autonomy, work, temporal, causal, agentic call-planning, semio relation, and refresh references; it does not locally certify those relations.

Thin is not an immature profile. When it gives the honest next move, Thin is a final conforming result for the current use. High-load is not a higher maturity claim; it is a conditional profile required when public, disputed, high-risk, set-derived, cross-context, semio-transformed, evidence-adjacent, autonomy-adjacent, gate-adjacent, agentic, or Part-G-facing relations are live in the case.

The profile order is a reading aid, not a required transition sequence. Thin is the default entry; Standard and High-load add only liveness-triggered fields; neighboring exits are consulted after the Thin next move exposes a live relation.

Stop at Thin when the honest next move is local stabilization, local characterization, source reread, or another early problem-side clarification before P2W readiness is claimed. Stop at Standard when it is sufficient to emit or bind a minimal TaskSignature, TaskKind, or ProblemProfile for downstream selector-facing use without carrying high-load relations locally. Exit immediately instead of continuing the card when the live issue is work, evidence, provenance, assurance, gate, autonomy, bridge, representation transition, retargeting, structural reinterpretation, causal-use claim, temporal claim, agentic call planning, or refresh.

#Field Labels and Liveness

The governed 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 basis: 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;
• described entity or exact project-side FPF kind or reference when load-bearing;
• 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-basis reference;
• characterization basis;
• characteristic or Q-bundle basis;
• indicator selection;
• comparability or parity basis, or explicit current reason it is not needed;
• mandatory constraints;
• risk posture;
• support posture;
• 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;
• neighboring-pattern exit.

Field liveness for C.22.2 is determined as follows:

Field absence rule: if a conditional relation is not live, the field is absent, not unknown. Use unknown only for a live relation whose value is currently unknown. If a live value is unavailable, state whether the next move is blocked, degraded, sandboxed, or sent to the receiving pattern. 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 relation has been checked. Exit-only material is never completed locally; it is named as cue, reference, or exit. This split is part of the local answer. A minimal ProblemCard@Context contains the always-core fields; conditional fields are added when live; exit-only material is named as a neighboring-pattern exit instead of being absorbed into the card.

When the card compares options, selected-set members, retained candidates, or rival problem formulations, it must state the live comparison or parity basis, or state why comparison is not live for the current move. Absence of a parity basis is not automatically a defect; it is a disposition. The admissible result is either parity not live for the current card, or exit to G.9 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, or semio 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 the source and neighboring references that make the problem-side record reviewable:

problemCardSource:
  sourceSignalRef?
  setContextRef?
  selectionOrRetentionBasis?
  characterizationBasisRef?
  parityBasisRef?
  freshnessRef?
  semioRelationRef?

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

#Anti-Pattern Checks and Worked Slices

Anti-pattern checks begin with card-as-work-item: treating the card as work to execute while the method remains unselected is non-conformant. Filling every field merely to satisfy the form is also non-conformant; fields are required only by liveness, profile, and next-move need. Declaring P2W-ready from signal and scope alone is non-conformant when no improvement check or acceptance probe is present.

A preselected solution or work item such as "implement X" is non-conformant as a problem card unless a problem-side signal, context, scope, and candidate acceptance basis are recovered. Evidence, provenance, assurance, gate, and autonomy references inside the card are non-conformant if they are read as proof, gate passage, safety acceptance, or permission instead of a cue, reference, or exit to the receiving pattern.

Treating a problem portfolio, archive, pool, front, shortlist, or selected set as a task queue inside C.22.2 is non-conformant; the card may only preserve setContextRef or a set-source cue and exit. Replacing Goldilocks, NQD, OEE, set-return, partial-order, or stepping-stone reasoning with one readiness score is non-conformant. A first-principles or mathematical cue without practical payoff, preserved and lost structure when live, support posture, and stop condition is non-conformant.

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-load worked slice from a set, archive, pool, front, shortlist, selected set, or portfolio context, showing setContextRef, candidate acceptance basis, risk posture, and neighboring exits without creating a local portfolio or archive kind.

#Conformance Checklist Requirements

Checklist role boundary: this checklist protects against overread after the practitioner has written or reviewed the card. It is not the writing order, not a mandatory field-completion sequence, and not a gate. The writing order remains Thin form, honest next move, and live exits only when their relation is live.

Do not treat a compact card template or worked example as a separate FPF object or pattern.

#Problem Reading and Kind Recovery

For this decision, problem remains an ordinary word in non-load-bearing prose. Recovery is required only when the wording changes an admissible move, FPF relation, downstream anchor, support, evidence, causal, bridge, assurance, decision, admissibility load, or neighboring-pattern exit. The preferred center is the framed problem representation: a problem-side representation of a described entity 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 load, it must be recoverable through this table:

Blocked readings: ProblemCard@Context is not U.Problem, not ProblemProfile, not TaskSignature, not TaskKind, not U.WorkPlan, not U.Work, not the problem-side representation itself, not a general ticket format, not an archive, not a portfolio, not an evidence object or proof, not a gate decision or gate passage, and not an autonomy object or work-plan item.

#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 described entity 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, exit to A.15. The card may carry method-search exits and method-family cues, 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 method-family selection, selected method, planned work, performed work, result record, or result measurement becomes live, use the receiving pattern; C.22.2 does not absorb that pattern's authority.

#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 a neighboring exit.

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. Method-family selection, selected method, planned work, performed work, result record, result measurement, evidence, gate, autonomy, archive, portfolio, and selected-set authority remain with their receiving patterns.

#Characterization, Indicators, and Comparability

ProblemCard@Context must state either a recoverable characterization basis and comparability or parity basis, 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 basis is a current disposition. The record exits to characterization, parity, or search or pool work under the receiving pattern instead of pretending the problem is ready for P2W.

The C.22.2 candidate acceptance basis must distinguish functional check, constraint compliance, risk or safety boundary, parity or comparison basis, and freshness window when those relations are live. Comparison frame, CG-Spec, or comparability governance exits to G.0. Acceptance clauses and acceptance threshold predicates exit to 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 Receiving Map

These are source-form recovery rows, not a taxonomy of FPF forms or C.22.2 subkinds. This map keeps source wording from becoming local C.22.2 subobjects. A form may enrich the problem card only when it supplies problem-side source, set, characterization, or comparison material. Authority, evidence, gate, autonomy, work, method, and result forms remain neighboring exits.

Problem-side and set-source forms:

Comparison and characterization forms:

Neighboring authority, evidence, work, method, and result forms:

Source-local exposition terms:

#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 basis, and the non-scalar next move when live; portfolio and archive governance stays with the named receiving 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 receiving 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 basis, budget or window, review cadence, and receiving pattern when live. setContextRef is a reference field, not a new SetContext kind, and is not evidence, gate passage, approval, portfolio object, or work authority.

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, described entity, 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 exit to the relation-bearing pattern. Reframing is triggered when context grounding, described entity, viewpoint, scope cut, or cause-theory cue changes the problem representation enough that support or readiness 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 reading carried by current receiving patterns.

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

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

• 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 basis;
• declared difference-reading basis when novelty or diversity is claimed, or an exit to the receiving characterization or comparison pattern;
• non-scalar trade-off, dominance, partial-order, or set-return basis when live;
• 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 exit when live.

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

If the band is not supported by a characteristic, Q-bundle, comparison, retention, or capability-context cue, treat Goldilocks wording as informal recognition only and send any selection, set-return, or parity claim to the receiving pattern.

The current receiving family is C.18, C.19, G.5, G.9, G.11, A.6.P:7a, and A.6.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 the neighboring adequacy check for first-principles or mathematical structure cues used by ProblemCard@Context.

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

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 support posture, 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.

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

ProblemCard@Context exposes support posture and validation boundary; it does not certify evidence, assurance, gate passage, safety, or autonomy control.

Plain definition: support posture names the current reason this problem formulation is worth keeping, reviewing, discriminating, or moving onward now. Typical bases include an observed signal, stakeholder cost or risk, repeated rework, violated constraint, stale or changed environment, selected-set retention basis, cheap probe value, first-principles structure that changes formulation, or stale but still useful archive or refresh cue. It is not evidence sufficiency, proof, confidence, provenance, assurance, gate passage, safety-case acceptance, release permission, autonomy permission, or work authority.

Plain definition: validation boundary states what has and has not been checked for the current next move, what the current problem formulation may be used for now, what it cannot yet support, and where any validation, evidence, assurance, gate, autonomy, or work claim beyond this local boundary is assigned. It is not an assurance claim, safety-case acceptance, release permission, or work authorization.

Plain definition: risk posture names the monitored risk, risk condition, cost-of-error concern, or containment concern that may change the safe next move. It is not the validation boundary, not the support reason, not evidence of danger by itself, and not permission to probe, delegate, or act.

Local-label boundary: support posture, validation boundary, and risk posture are local problem-card field labels unless a separate accepted FPF decision assigns a different governing kind. When mathematical-lens support is live, cite C.29 and do not read local support posture as LensSupportPosture. When assurance, evidence, or provenance support is live, exit to B.3, A.10, or G.6 as applicable.

Detector, check, and optimization-target discriminator:

• symptom detector: what revealed the possible problem; not an acceptance criterion.
• improvement check: what would show that the problem formulation became better.
• acceptance probe: what downstream acceptance may need to inspect; not local acceptance authority.
• optimization target: what a later selector may improve under comparison-governance or selection-governance patterns; not a local method choice.
• monitored risk signal: what may worsen, distort value, or change the safe next move; not proof by itself.
• acceptance authority: carried by G.4 or another receiving acceptance pattern, not by C.22.2.

Reliance-disposition rule for P2W receiving use:

Use this rule when support posture or validation boundary may enter P2W as evidence-like, confidence-like, conformance-like, proxy-like, safety-looking, redress-bearing, or currentness-bearing support. The first C.22.2 move is to keep the result problem-side: name the P2W receiving use, unsupported use, and any live receiving-pattern exit. This rule does not add a default field family to ProblemCard@Context. If the Thin card already gives an honest next move and live exits, no additional reliance record is required.

Support role: the disposition table below is a local P2W-reliance recognition and minimum local record aid, and the worked P2W reliance slices are regression/review slices. They are not card field lists, project checklists, or hidden SEMIO state machines. Use them only to state the supported P2W receiving use, unsupported use, and receiving-pattern exit when support posture or validation boundary is actually being relied on. This local section returns the attempted P2W use to the C.22.2 problem-side relation and named receiving-pattern exits; it does not create an extra SEMIO authority or shared relation family.

Affordability card: orientation, discussion, or source-finding can remain an ordinary problem-side cue; bounded P2W reliance states the supported receiving use, unsupported use, window, and exit; threshold reliance names the receiving evidence, assurance, gate, autonomy, control, work, temporal, or representation relation instead of making the card larger. Plain wording remains ordinary unless it changes admissible use, support, evidence, gate, assurance, work, decision, or neighboring-pattern exit.

Common wrong first reading: P2W-ready means proof, safety acceptance, gate passage, method selection, work authorization, or release permission. First honest entry: keep the result problem-side; name the P2W receiving use and any exact evidence, assurance, gate, autonomy, control, work, temporal, or representation exit when live.

Minimum P2W support statement when this rule is live: support posture, validation boundary, RelianceDisposition, supported P2W receiving use, unsupported use, currentness or window when relevant, contest or redress path when relevant, and live receiving-pattern exits. Do not copy evidence, gate, assurance, work, autonomy, or control fields into the card unless the card is explicitly naming a live exit to the receiving pattern.

Misuse guard: RelianceDisposition=abstain and RelianceDisposition=degrade must state the condition for reopening, narrowing, or closing the P2W use; do not use uncertainty to block valid P2W receiving use indefinitely or to hide a full pass behind a narrower label.

False-negative reliance guard: a blocked, abstained, or evidence-needed P2W use is not final if admissible challenge evidence, missing affected-party evidence, changed source, changed representation, or redress can materially change the disposition.

Support-inheritance guard: support does not inherit across representation scheme, episteme-lane view, publication face, described entity, retargeting relation, or source-basis change merely because the same card text, dashboard label, source phrase, support cue, generated explanation, coarsened or redacted rendering, screenshot, or copied approval survived. Use A.6.3.RT, A.6.3.CSC, A.6.4, E.17, F.9, or E.18 only when that relation is live; otherwise keep the local card use bounded.

Positive repaired path: a messy support cue becomes useful when the card states what P2W may receive now, what P2W must not infer, and which exact neighboring pattern carries any evidence, assurance, gate, temporal, representation, autonomy, control, or work relation. A successful result can be P2W-ready, degraded P2W use, evidence-needed, refresh, reopen, abstain/no-change, or a named neighboring exit; it need not become a bigger card.

Worked P2W reliance slices:

A cause-theory cue may focus problem formulation inside ProblemCard@Context. If that cue is used to claim association, intervention, counterfactual, responsibility, expected effect, or causal evidence, the relation exits to C.28 plus A.10, G.6, or B.3 when support, provenance, or assurance is live.

The AI-agent and autonomy material from the source material is received as neighboring pressure:

• autonomy budget and delegated-agent control exit to E.16;
• gate decisions and gate logs exit to A.21;
• method selection and work execution exit to G.5 and A.15;
• evidence, provenance, and assurance exit to A.10, G.6, and B.3;
• freshness, monitoring, decay, and update triggers exit to G.11.

Environment design and safe probing may appear as source signal basis, validation boundary, risk posture, or neighboring-pattern exit. When the next move requires probe planning, autonomy control, gate authority, evidence, assurance, or work authority, an honest card may record safe-probe-needed and name C.24, E.16, A.21, or another live receiving pattern; this records a probe need and receiving-pattern relation, not local probe authorization. C.22.2 does not create a separate problem-environment pattern. If the next move may affect the world, spend resources, call tools, delegate to agents, change an operational state, or require agentic tool-call scouting, tool-call plan selection, checkpoint return, or bounded call plan, ProblemCard@Context may only name the probe need. The authority to probe or act exits to C.24, E.16, A.21, A.15, A.10, G.6, or B.3 when those relations are live.

#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 basis, support or source, set-source reference, or semio 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 bases are current enough for the intended next move. For support or source, ask whether cited sources, provenance, and support references are fresh enough for the stated support posture. For set-source reference, ask whether archive, front, pool, shortlist, or selected-set membership and the selection or retention basis are still current. For semio relation, ask whether wording, diagram, functional description, TGA path, bridge, retargeting, or representation change alters the described entity, support inheritance, context grounding, viewpoint or role concern, scope cut, comparison basis, admissible next move, or relation needed for inheritance.

A stale support reference does not always retire the problem; it may send the card to refresh while the problem remains reviewable. A stale problem signal may support refresh, retire, archive, abstain or no-change, or another named neighboring disposition.

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, the record exits to one of these current dispositions:

• refresh the problem card or its characterization or comparison basis 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 relevant authority, evidence, gate, autonomy, or work pattern.

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.

#SEMIO Relation and Representation Continuity

The accepted SEMIO-03 result is part of the current FPF basis. C.22.2 uses A.6.3.RT, A.6.4, E.17, F.9, and E.18 as exits when changed problem formulations, diagrams, functional descriptions, TGA paths, or PathSlice examples carry relation load.

Framing is not wording repair. A framing change is live when described entity, context grounding, scope cut, viewpoint, comparison basis, support inheritance, or honest next move changes. SEMIO material is triggered only when wording, diagram, functional description, TGA path, bridge, retargeting, or representation change alters the carried problem-side representation, described entity, support inheritance, context grounding, viewpoint or role concern, scope cut, comparison basis, admissible next move, or live receiving pattern. Ordinary wording cleanup does not trigger a SEMIO exit and does not block a Thin ProblemCard@Context.

C.22.2 may not treat changed-problem examples as support 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 exit from C.22.2.

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

#SoTA Decision Support

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-load-bearing example.

Each load-bearing 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 authority.

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 support, method, work, gate, autonomy, bridge, representation transition, or refresh must exit to 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. At the same time, the card stays outside archive, portfolio, decision, autonomy, work, gate, evidence, bridge, and assurance authority.

The archive and portfolio distinctions remain live when they matter because the card preserves setContextRef and exits to the current receiving patterns. Changed problem formulations, diagrams, functional descriptions, or TGA path readings require the accepted representation or retargeting exits before support is inherited. Current SoTA and first-principles cues matter only when they change fields, exits, boundaries, or the problem formulation itself.

#Problem-Card Use Invariants

These invariants govern use of one ProblemCard@Context; they do not add card fields.

#Misuse Modes and Repairs

#Use-Quality Checks

A practitioner checking one ProblemCard@Context use should be able to find these results in the card, its stated next move, and its named exits. These checks protect use quality; they do not add fields to the card.

#Worked Slices and Anti-Cases

These worked slices and anti-cases support local use-quality validation. They are not a benchmark suite, scorecard, or completeness test; they test entry support, wrong-pattern boundary, and admissible stop for a C.22.2 result.

#Five-Case Worked Slices

Five messy source signals serve as worked slices for use-quality validation, not as a benchmark suite: AI and human task rework, musical mastery tempo drift, problem set or Goldilocks selection, customer-support escalation after a policy or interface change, and literature-synthesis anomaly before method selection.

Thin card slices:

Next move and tempting wrong-pattern check:

P2W-ready disposition check:

Additional validation cases:

#Machine-Assisted Drafting Boundary

Machine-assisted ProblemCard@Context drafting is admissible only as draft support. The practitioner remains responsible for verifying the governing fields and neighboring exits before the card is used for P2W, selection, evidence, gate, autonomy, or work.

For AI-assisted entry or retrieval, a C.22.2 hit is only a candidate-pattern hit. The practitioner or assistant must still check the first honest entry load: problem-side record before P2W, work plan, evidence claim, local choice, safe probe, mathematical-lens adequacy, or ordinary discussion.

Required practitioner checks for a machine-assisted draft:

• source signal;
• improvement check or acceptance probe;
• support posture;
• unknown handling;
• freshness or expiry disposition;
• neighboring exits;
• no evidence, gate, work, or autonomy overread.

#First Practical Entry Support

This section is discoverability support 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 receive 'implement X'."
• "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 exit elsewhere."

Tempting wrong first patterns:

• Do not start at C.11 if the live issue is not yet a local choice among available options.
• Do not start at C.16 or A.19 if the live issue is not only measurement, characterization, or indicator admissibility.
• Do not start at C.18, C.19, or G.5 if the live object is one selected singleton problem card rather than the archive, pool, front, or selected-set object.
• Do not start at A.15 if no method or work plan is ready.
• Do not start at A.10, G.6, or B.3 if evidence, provenance, or assurance is not the center.
• Do not start at A.21 or E.16 if no gate or autonomy authority is being decided.

Not C.22.2 anti-cases:

• "The method is accepted; now schedule the work." Use A.15.
• "We need proof this result is reliable." Use A.10, G.6, or B.3.
• "Which option should we choose among explicit options?" Use C.11, or G.5 when set publication or selected-set semantics are live.
• "Can the agent call the tool?" Use C.24, E.16, or A.21; ProblemCard@Context may only name the problem-side cue or exit and does not grant tool-call, autonomy, or gate authority.
• "This is ordinary discussion with no downstream project-side move." Do not use C.22.2.

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 named neighboring-pattern exit.

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 Boundary Exports

A downstream citation of ProblemCard@ContextRef is admissible only for the local cue or reference named by the downstream relation. For C.22 use, cite problem-side readiness and candidate TaskSignature basis only. For G.5 use, cite selected-set or search cues only as source cues. For A.15 use, cite work need only after work planning is live. For A.10, G.6, and B.3 use, cite support or evidence cues only as cues, not proof. For C.29 use, cite firstPrinciplesCue only for mathematical-lens adequacy, not method or acceptance authority. No downstream citation inherits full-card authority by reference.

P2W export from ProblemCard@Context includes:

• problem-side representation.
• context grounding and scope cut.
• not-wish, not-ticket, not-slogan, or not-preselected-work reason.
• improvement check or acceptance probe.
• readiness disposition: reviewable-only, P2W-ready, no-work or abstain, or sent to a named neighbor.
• candidate TaskSignature basis only when downstream selector or P2W readiness is declared.
• named neighboring exits and references, without importing neighboring authority into the card.

P2W export from ProblemCard@Context does not include:

• method-family selection or selected method.
• WorkPlan, work authorization, performed work, result record, or result measurement.
• evidence proof, evidence sufficiency, provenance certification, or assurance claim.
• gate passage, gate decision, release permission, or safety-case acceptance.
• autonomy permission, delegated-agent authority, tool-call permission, or permission to spend resources.
• selected solution, portfolio authority, selected-set authority, or mathematical adequacy proof.

#Consequences

#Benefits

• FPF gains a clear problem-side output for problematization as the input P2W can use.
• P2W receives 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; support posture is cited as proof; a stale problem remains active; scalar readiness replaces set-return; or support is inherited across a changed representation without a SEMIO witness.
• 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 support is handled through named relation exits 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 task typing, method-family selection, evidence use, gate passage, autonomy control, set-return handling, or first-principles support.
• 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, exit, or validation obligation. Otherwise they remain examples or source cues, not local authority.

#Relations

• Builds on: E.2, E.9, E.10, E.10.SEMIO, A.6.P, A.6.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, and E.18.

#C.22.2:End

Last Updated: 2026-05-22 — this section last modified in upstream FPF commit 725f0b7b (github.com/ailev/FPF)