C.26.1:4 - Solution
Before accepting a passive read or unjustified lossless-transfer reading, ask whether the probe or interaction changed what the output may admissibly mean.
C.26.1 is active only when the interaction both participates in the represented state and its output is being used as evidence, export, comparison input, or decision input as if it were passive. Mere behavior change, ordinary feedback, or ordinary influence is not enough.
A probe-coupled interaction may be useful and intentionally state-shaping. The repair is not to avoid it; the repair is to stop using its output as if it were a neutral pre-probe read.
Start with this recognition note:
| Mini-entry | Question |
|---|---|
| Ordinary governing pattern | Which ordinary FPF pattern already carries the baseline boundary, bridge, measurement, work, or viability question? |
| False passive read | Which reading would be false: “the dashboard, workshop, API read, survey, message, or bridge just reports state”? |
| Probe effect | What changed because of the probe, intervention, export, order, frame, or boundary crossing? |
| Practical change | What does the team do differently now: mark probe-coupled, redesign the probe, order, or frame, rewrite bridge or export, add evidence, or apply a neighboring FPF pattern? |
| Stop or neighboring-pattern handoff | Which use is unsupported by this note, and which FPF pattern carries that use? |
Use the fuller decision-bearing record below when the boundary result will be reused, contested, used as evidence, or used to change an architecture decision.
Full decision-bearing record:
| Field | Question |
|---|---|
| Boundary | Which boundary, role relation, authority relation, context bridge, service interface, team boundary, or system edge is crossed or queried? |
| Probe or interaction | Which workshop, dashboard, API read, metric, meeting, survey, message, event stream, or other typed probe lane is active? |
| QL cue or formal cue | Which instrument-like update, order sensitivity or frame sensitivity, incompatible-probe structure, no faithful-enough export under the declared probe, frame, or use, or mutual interaction whose local reads and exports are no longer admissibly comparable or reusable without declaring the probe, frame, or update relation makes ordinary passive-read wording false? |
| False passive reading | What discovery, neutral observation, one-way transfer, or unjustified lossless-message reading would be false? |
| Pre-probe hypothesis | What did the team think the boundary state, alignment, readiness, context cut, or export validity was before the probe? |
| Observed or inferred post-probe state | What changed, stabilized, became visible, became non-exportable, or lost admissible use because of the probe or interaction? |
| Update class, if load-bearing | Is the update a system change, work change, epistemic reading update, carrier update, emitted-output update, formal model update, or update-law change? |
| State-change evidence | Which traces, changed decisions, changed labels, changed priorities, behavior shifts, timing changes, or export failures support the state-change reading? |
| Uncertainty / confidence posture | What remains inferred, approximate, disputed, probe-dependent, or not yet distinguishable? |
| State history / memory, if load-bearing | State this only when path dependence, order effect, hysteresis, or retained trace changes the current lawful reading. |
| Decision | What changes now: mark probe-coupled, redesign probe, order, or frame, add evidence, rewrite bridge or export, split, merge, orchestrate differently, or apply a neighboring FPF pattern? |
| Decoupling / redesign option | Can the probe, order, frame, bridge, metric, dashboard, API read, or boundary interaction be redesigned so the needed output is less state-changing or more faithfully exportable? |
C.26.1:4.1 - Activation boundary
This pattern is active only when the interaction both participates in the represented state and its output is being used as evidence, export, comparison input, or decision input as if it were passive. A passive-read, unjustified lossless-transfer, one-way-message, or ordinary-bridge treatment must be materially false for the current decision.
Ordinary influence is not enough. A meeting that changes attention is ordinary work unless the meeting output is later used as a passive reading of alignment. An API call that is a mutating operation by its interface semantics is ordinary service/API semantics unless the call result is used as a neutral state export. A feature flag that changes behavior is ordinary intervention unless the flag readout is being used as evidence of the state it changes.
Performative prediction is also an important ordinary rival. If a prediction, score, or metric changes behavior because people act on it, but no incompatible probe frame, order-sensitive reading, contextual-probability cue, or instrument-like state/export support load remains, try performative-prediction analysis first; use C.16 for measurement, A.10 for source recovery and bounded reliance, and B.3 only for an actual named assurance claim. Keep C.26.1 only for the residual probe admissibility question.
C.26.1:4.2 - Finish conditions
The pattern emits one of these results:
| Result | Meaning |
|---|---|
| Keep boundary, mark probe-coupled | The boundary remains, but the read/export is no longer treated as passive. |
| Redesign probe/order/frame | The workshop, dashboard, API read, survey, metric, or question order changes to reduce distortion. |
| Redesign bridge/export | The bridge/export gains loss notes, use scope, confidence, and return-to-source path. |
| Split/merge/orchestrate differently | Boundary structure changes because the interaction changes the phenomenon. |
Apply F.9 | Only bridge and loss remain live. |
Apply C.16 | The probe is really a standard measurement with declared scale, method, evidence, and result. |
Apply A.15 | The hard part is work enactment rather than probe-coupled reading. |
Apply C.26.3 | Viability-envelope regulation is primary. |
C.26.1:4.3 - Probe-coupled context-cut worked use slice
This worked use slice is not a standalone pattern. It tests DDD and bounded-context work when the context cut is not only discovered but also changes meaning, coordination, export validity, or viability.
Ask: was the bounded-context cut merely discovered, or did the workshop, dashboard, API extraction, bridge, split, merge, or orchestration change alignment, ownership, vocabulary, export validity, or viability?
| Slice field | Example content |
|---|---|
| Case | A product organization considers splitting payment handling out of a checkout bounded context after repeated payment-failure incidents. |
| Ordinary DDD finding | Checkout and Payment use different local meanings for Order.status, PaymentFailure, and Retryable; an ordinary F.9 bridge is needed. |
| Probe / intervention | The event-storming workshop starts from payment-failure dashboards and asks teams to place incidents by owner, customer impact, and recovery path. |
| Post-probe reading | Product, Support, and Payment start treating payment failure as a customer-risk gate, not only a technical retry condition. |
| Evidence | Incident labels are reclassified, escalation changes, backlog priority changes, and the dashboard query is rewritten. |
| Export loss | Copying PaymentFailure = customer risk into both contexts loses the difference between retryable technical failure, promise breach, and support escalation trigger. |
| Decision output | Keep the split, mark the workshop result as probe-coupled, add F.9 loss notes, and add a payment-risk escalation promise to the boundary design. |
C.26.1:4.4 - Boundary interaction under concern and operational sequence
The boundary interaction under concern is a boundary interaction used as evidence, export, comparison input, or architecture decision input. The interaction may be a meeting, question sequence, dashboard, metric, API read, survey, workshop, event stream, canary, test harness, service split, bridge, message, or management review. The pattern is active only when that interaction participates in the represented state enough that passive-read wording or unjustified lossless boundary-to-decision inference would change the decision.
The pattern governs one move: convert an apparently passive boundary read into a typed probe-coupled boundary decision. That decision says what the interaction read, what it changed, what the output can support, what it cannot support, and which neighboring FPF pattern takes over if the question is really bridge, measurement, evidence, work, decision, or viability.
Operational sequence:
- Name the boundary or relation being crossed.
- Name the probe lane, including the concrete artifact or work act that produced the output.
- State the false passive reading: what the team would have assumed if the probe were only a window.
- State the pre-probe hypothesis and the observed or inferred post-probe state.
- State the evidence carriers and uncertainty posture.
- State the export loss, memory, order effect, or frame effect that makes the output not faithful enough for the declared use.
- Choose the finish result: keep boundary with probe note, redesign probe, order, or frame, redesign bridge or export, change the split, merge, or orchestration, or apply a neighboring FPF pattern.
Required output: produce a probe-coupled interaction reading, a corrected use of the output, and, when it would reduce the problem, a redesign or decoupling move for the probe, order, frame, bridge, metric, dashboard, API read, or boundary interaction.
This sequence is deliberately small. It is the boundary analogue of the C.11 local choice pass: the pattern should end with a usable result, not with a richer vocabulary label.
C.26.1:4.5 - Well-formed probe-coupled boundary state
A probe-coupled boundary decision is usable only when the record states all of the following:
- the boundary, context bridge, service interface, team boundary, role relation, authority relation, or system edge involved;
- the probe lane and output carrier;
- the state reading before the interaction and the state reading after the interaction;
- the state-change evidence, including traces, changed labels, changed priorities, changed timings, changed routines, changed bridge fields, or changed downstream decisions;
- the local stop condition: which use the output does not support without another pattern;
- the neighboring FPF pattern that would carry the other claim.
The record is unfinished when any of these remains true:
- the output is named, but the operation that produced it is hidden;
- the operation is named, but the state that changed is not named;
- the state changed, but the decision that changes because of that fact is not named;
- the bridge/export loss is stated only as a vague warning rather than as a concrete non-admissible use;
- the same interaction is alternately treated as evidence, command, measurement, and bridge without role split.
The minimal admissible output is often enough: “this dashboard value is probe-coupled evidence for readiness behavior under window W”; “this workshop work changed alignment and therefore the workshop note cannot be treated as passive discovery”; “this API read is a non-neutral observation under these interface semantics”; “this context cut needs both F.9 bridge loss and C.26.1 probe-coupling treatment.”
C.26.1:4.6 - Probe, observable, output, and carrier split
Do not identify what is being read with the method used to read it, the resulting output, or the output carrier.
| Role | Boundary-facing question |
|---|---|
| Observable or output dimension | What readiness, status, alignment, failure, response, risk, split, promise, or boundary condition is being read? |
| Probe method | How is the dashboard, API read, workshop order, survey, canary, incident review, event stream, or meeting format used to probe the situation? |
| Measurement / interaction scheme | What timing, threshold, sampling rule, question order, aggregation, publication path, or access path shapes the output? |
| Output or result record | What score, label, context map, API response, survey answer, incident class, readiness status, or bridge field was emitted? |
| State update | What behavior, alignment, meaning, trust, priority, escalation, or timing changed because of the probe? |
| Evidence carrier | Which log, dashboard export, meeting note, trace, decision record, ticket history, context map, or API result carries the output? |
This split prevents a common mistake: “the dashboard says ready” hides at least four objects. The dashboard definition, the displayed result, the behavior it changes, and the readiness decision are distinct.
C.26.1:4.7 - Reroute and disambiguation guide
Use this guide when a draft says that a boundary, system, team, or service is “coupled”, “aligned”, “interacting”, “measured”, “exported”, “synchronized”, or “read”.
| Trigger surface | First question | If yes | If no |
|---|---|---|---|
| “The dashboard shows readiness.” | Did publishing or using the dashboard change readiness behavior, escalation, staffing, or release posture? | Use C.26.1; state probe, update, evidence, and admissible use. | Use ordinary reporting, C.16 for measurement, A.10 for source recovery and bounded reliance, or B.3 for an actual named assurance claim. |
| “The workshop discovered the boundary.” | Did question order, framing, participants, or artifacts change local meaning, ownership, trust, or viability? | Use C.26.1 with this context-cut worked use slice; add F.9 if bridge/export loss is live. | Use ordinary DDD / F.9 bounded-context work. |
| “The API read returns state.” | Is the read path state-changing under interface semantics, timing, cache, consistency, or downstream behavior? | Use C.26.1 if the result is later treated as a passive read. | Use ordinary API semantics, measurement, or data freshness. |
| “The message transferred the decision.” | Did the message change authority, trust, escalation, timing, or local meaning enough that copy or transfer is false? | Use C.26.1 and apply the relevant work or authority pattern to commitments or authority. | Use publication, bridge, or work enactment patterns. |
| “The split improved viability.” | Did the split/probe alter the viability envelope being evaluated? | Coordinate with C.26.3. | Use ordinary boundary, quality-bundle, or architecture patterns. |
When relation wording is load-bearing, do not mint a relation token here. Use A.6.P if the relation or participants remain unclear; use the direct relation pattern when they are already known. Keep local explanatory prose unless the settled relation needs a reusable name under F.18.
C.26.1:4.8 - Positive examples and near misses
| Case | Supported C.26.1 use | Near miss and neighboring-pattern handoff |
|---|---|---|
| Readiness dashboard | The readiness score changes team behavior: teams stop surfacing borderline failures because the dashboard is watched by release management. The score is probe-coupled evidence, not a passive readiness copy. | If the dashboard only reports a well-defined measure with no behavior-changing or frame-changing effect, use C.16 and the direct pattern for any evidence claim that is current. |
| API consistency check | A “read” through a cache warms entries and changes later latency, so the readout changes the performance state later used in the decision. | If the call is simply a mutating operation by interface semantics, use ordinary API/work semantics and say so plainly. |
| Survey order | Asking “who owns incidents?” before “which context owns payment failure?” changes the resulting context map and escalation plan. | If different answers merely reveal unresolved meanings, use F.9 / A.6.P first. |
| Event-storming workshop | The workshop produces a map and also changes team alignment, local vocabulary, and backlog priority. | If it only documents known differences, use ordinary DDD and bridge fields. |
| Service split | Splitting Checkout and Payment changes recovery paths and support load, so the split is part of the phenomenon being evaluated. | If the split only reduces deployment coupling with no probe/export effect, use ordinary boundary and quality patterns. |
| Incident metric | Publishing “cache failover is the primary risk” shifts attention, staffing, and reproduction work. | If the metric is only a report of already-carried evidence, use A.10 for any source-recovery or bounded-reliance question, and B.3 only for an actual named assurance claim. |
The positive examples establish probe-coupled interaction readings. Use those results without QL wording when the ordinary subject patterns carry the case, as CC-C26.1.4 permits. Retain QL only when the additional C.26 activation test establishes one named contextual-model obstruction that survives those patterns and changes the admissible inference or action.
C.26.1:4.9 - Evidence posture for probe-coupled claims
Use the least-committing evidence posture that still supports the intended use.
| Evidence posture | Admissible use | Typical support |
|---|---|---|
QLP-0 recognition | Flag a likely probe-coupled situation for local discussion. | Meeting note, dashboard screenshot, issue comment, context-map draft. |
QLP-1 local working use | Change a local probe/order/frame, bridge note, or boundary decision in a team setting. | Before/after labels, changed tickets, changed dashboard query, changed escalation path, changed architecture note. |
QLP-2 decision-bearing use | Use a probe-coupled reading for a named boundary, probe, export, or other decision whose answer needs more than the current local account. | The action-changing rival explanations, declared loss and receiving-use limits, and observations or comparisons that this decision consumes; reuse adequate existing contributions. |
QLP-3 assurance use | Answer a named assurance question about the probe-coupled claim, its empirical adequacy, or comparative advantage. | The applicable A.10 and B.3 support for that conclusion, with C.16 measurement or a Bridge/loss account only where the conclusion relies on it; retain adequate existing support and its limits. |
Do not make QLP-3 the ordinary entry cost. Recognition or local working use may remain at QLP-0 or QLP-1 when its account is sufficient. Select additional support from the receiving conclusion under C.26:12b; publication, reuse, or formal wording alone does not require escalation or recollection of adequate evidence.