FPF Reference

A.6.B:8.4 — Worked Rewrite Kit (informative, recommended)

Preface node heading:a-6-b-8-4-worked-rewrite-kit-informative-recommended:7317

Content

Informative. This kit is a worked, copy‑pasteable restatement of A.6.B’s rules (atomicity, L/A/D/E routing, explicit references, triangle decomposition, and no‑upward dependencies). If anything here conflicts with A.6.B, A.6.B is authoritative.

Goal

Convert a boundary-ish sentence that mixes “laws / gates / duties / evidence” into:

  1. atomic routed claims (L/A/D/E),
  2. explicit references by claim ID (no paraphrase duplication),
  3. a readable recomposition (Tech + Plain),
  4. a minimal anti-pattern lint (things we forbid / flag).

Micro-procedure (Atomize → Route → Triangle → Link → Anchor → Recompose)

Step 1 — Atomize. Split mixed prose into atomic claims; each must route to exactly one quadrant.

Step 2 — Route (L/A/D/E).

  • L if the claim is truth‑conditional and adjudicable in‑description (inspection, proof/type validation, or model reasoning over declared assumptions): definitions, invariants, typing/well‑formedness constraints.
    Guardrails: L-* MUST NOT (i) use RFC deontic keywords as operators, (ii) encode runtime entry predicates (those are A-*), or (iii) assert evidence existence/measurement outcomes (those are E-*).
  • A if it is an in‑work gate predicate: what the mechanism admits/permits at application time (“admissible iff …”). It is not a duty and MUST NOT be phrased as one.
    Guardrails: A-* SHOULD be written in predicate form and MUST NOT (i) use RFC deontic keywords as if it were an agent obligation, (ii) claim that evidence/carriers exist (that is E-*), or (iii) assign responsibility/enforcement (that is D-*).
    (Do not confuse this with Signature.Applicability: applicability scopes intended meaning/use; it is not a runtime entry gate.)
  • D if it assigns duties/commitments to an accountable role/agent (RFC keywords belong here; “the interface/system promises” does not).
    Guardrails: D-* MUST name an accountable subject and SHOULD reference L-*/A-*/E-* by ID rather than restating them in new words (to prevent paraphrase drift).
  • E if it is an in‑work truth‑conditional claim about adjudicable effects/evidence: what carriers exist, under what observation conditions, and/or what was observed.
    Minimum fields (recommended): (1) observation/measurement conditions, (2) carrier class/schema reference, and (3) viewpoint/consumer.
    Guardrails: E-* SHOULD NOT use RFC deontic keywords, MUST NOT hide a gate predicate (that is A-*), and MUST NOT cite D-*.
    (If the sentence is “Role SHALL measure/retain/expose …”, route that obligation to D, even if it is about evidence.)

Step 3 — Triangle decomposition. If the original sentence mixes (i) an entry condition, (ii) an obligation/commitment, and (iii) an observability expectation (a common failure mode with “guarantee/ensure/approved/aligned”), decompose it into:

  • A: the admissibility predicate (what must be true to treat the claim as applicable),
  • D → A: who is responsible for keeping/ensuring the predicate,
  • E → A: what evidence/traces are used to adjudicate the predicate.

Note (routing sanity). D-* claims are authored in the description even when their compliance is audited via E-* claims. Auditing via evidence does not move D-* into quadrant E.

Guideline. Keep gate semantics independent of specific evidence carriers: write the gate predicate in A-*, then bind observability in E-* that references the gate (E → A). A-* claims MUST NOT reference E-* (no upward dependencies), even though E-* is used to adjudicate gate satisfaction.

Step 4 — Link by ID, not by paraphrase. Allowed directions (no upward deps):

  • A-* may cite L-*
  • E-* may cite L-* and A-*
  • D-* may cite L-*, A-*, E-*
  • Forbidden: L-* citing anything; A-* or E-* citing D-*.

Common link motifs (informative). The most reusable boundary rewrites use the canonical motifs: D→A, E→A, D→E, A/E→L, and D→L.

Step 5 — Anchor (minimal A.7 discipline).

  • Anchor L claims in Signature.Laws (and mechanism‑local semantic laws if present), and A claims in Mechanism.AdmissibilityConditions.
  • Anchor D claims to accountable roles/agents and prefer ID references (no restatement of L-* / A-* content in new words).
  • Anchor E claims to carriers + observation conditions and SHOULD include viewpoint/consumer (minimum: conditions + carrier class/schema + consumer/viewpoint).

Optional drift-control. Add each routed claim verbatim to a Claim Register row (A.6.B:7) with canonical location + references so faces can cite by ID without paraphrase.

Step 6 — Recompose into readable text. Produce two surfaces:

  • Tech surface: a short routed claim bundle (sometimes called a “contract skeleton”) listing routed claims + ID references.
  • Plain surface: a one-paragraph narrative that summarizes the bundle and points to IDs (no new semantics). If you need a new constraint, add a new atomic routed claim; do not smuggle it into Plain.

Anti-pattern (quick)

  • AP-1 Evidence-free guarantees. “X guarantees Y” with no E-claims.
  • AP-2 Interface-as-promiser. Non-agent objects “promise/commit”.
  • AP-3 Gate-as-evidence. Treating the gate predicate (A) as if it were an observation (E).
  • AP-4 Gate-as-law. Entry predicates as signature “laws/definitions” (L) instead of A-*.
  • AP-5 Adjective smuggling. “fast/secure/approved/aligned” used instead of qualifiers/slots.
  • AP-6 Paraphrase drift. Restating L/A content in D or E with changed meaning (instead of citing by ID).
  • AP-7 Deontics in predicates. RFC keywords (“MUST/SHALL/…”) used as operators inside L-* or A-* predicates (should be D-* that references L-*/A-*).
  • AP-8 View-fork semantics. Recomposition/face text introduces new L/A/D/E meaning not present in the routed claim set (violates “no new semantics” discipline).
  • AP-9 Applicability-as-gate. Using Signature.Applicability (intended use) as a substitute for A-* runtime admission predicates.

Example 1 — Software engineering (SLO-ish API latency)

Draft sentence (non-conformant)

“This API guarantees p95 latency < 200ms.”

Atomize + Route (L/A/D/E)

L-API-01 (Definition). p95_latency(window W, population P, unit U, method M) is defined as … (formal measurement definition). (Lives in Signature.Laws or a referenced measurement definition pack.)

L-API-02 (Interface signature). The API endpoints and parameters are as declared (including parameter passing discipline / units). (Signature-level structure.)

A-API-01 (Gate predicate: admissibility). The claim “p95 < 200ms” is admissible only under declared load/profile + deployment region + sampling method + window: AdmissibleLatencyClaim := (region=US) ∧ (concurrency≤X) ∧ (payload≤Y) ∧ (W=5m) ∧ (M=HDRHistogram@v…) ∧ (P=requests that match filter F) (References L-API-01 for definition.)

D-API-01 (Commitment). ServiceOwner SHALL meet the latency target p95_latency < 200ms when A-API-01 holds, adjudicated per L-API-01 using the carriers/observation conditions in E-API-01. (References L-API-01 and A-API-01 by ID; does not restate them.)

D-API-02 (Operational duty). SRE_oncall SHALL publish incident notes when the commitment D-API-01 is violated, and SHALL avoid claiming compliance outside A-API-01. (References D-API-01 and A-API-01 by ID.)

E-API-01 (Evidence / carriers). For decisions under A-API-01, the following carrier classes are produced/observable under the declared observation conditions: trace/span IDs, raw histogram artefacts (schema reference), percentile dashboard snapshots, and pinned sampling configuration for window W.
Observation conditions (minimum): workload/profile selector, sampling method/config pins, and computation method reference (L-API-01).
Viewpoint/consumer (minimum): the role/view that uses the carriers to adjudicate the gate and/or audit commitments (e.g., SRE/PerfReview).
(References A-API-01 and L-API-01; avoids RFC deontics; does not smuggle gates. Note: E-* MUST NOT cite D-*.)

D-API-03 (Duty-to-evidence linkage). Operators SHALL retain/expose the carrier classes referenced in E-API-01 for the audit window required by policy. (References E-API-01 by ID.)

E-API-02 (Observed value claim). For interval Γ_time = [t1..t2] under conditions pinned to A-API-01 and using carriers in E-API-01, observed p95_latency = 173ms (computed per L-API-01). (References A-API-01, L-API-01 and E-API-01.)

Triangle decomposition (explicit)

  • A-API-01 is “the predicate”.
  • D-API-01 → A-API-01 states the commitment under the gate/envelope.
  • E-API-01 → A-API-01 anchors adjudication (carriers used to decide the gate/commitment).
  • D-API-03 → E-API-01 expresses retention/exposure obligations for those carriers.

Readable recomposition

Tech recomposition (contract bundle, short):

  • L-API-01 defines p95 latency computation.
  • A-API-01 specifies when the latency claim is admissible.
  • D-API-01 states the commitment under that envelope.
  • E-API-01 lists adjudicable carriers/conditions used to adjudicate A-API-01 (and therefore any commitments that reference it).
  • D-API-02 assigns operational incident-note duties.
  • D-API-03 assigns retention/exposure duties for carriers in E-API-01.
  • E-API-02 reports observed performance under A-API-01 for Γ_time=[t1..t2].

Plain recomposition (one paragraph, readable): “The API’s latency target uses the p95 definition in L-API-01 and is only applicable under the declared operating envelope A-API-01. The service owner commits to meeting the <200ms target under that envelope (D-API-01). Adjudication uses the telemetry carriers listed in E-API-01, which operators must retain/expose (D-API-03), and the on-call SRE must publish incident notes when the commitment is violated (D-API-02). Under that envelope, the observed p95 over Γ_time=[t1..t2] was 173ms (E-API-02).”

Example 2 — Mechanical engineering (fit / coaxiality)

Draft sentence (non-conformant)

“This fit ensures coaxiality.”

Atomize + Route

L-FIT-01 (Definition). coaxiality is defined relative to a declared base axis and measurement method (datum scheme, instrument, tolerance zone). (Truth-conditional: “what it means”.)

L-FIT-02 (Interface/boundary structure). The boundary relation involves shaft, bushing, datum axis, tolerance class, temperature window, assembly procedure class. (Signature-level arity recovery / slots.)

A-FIT-01 (Gate predicate). The coaxiality claim is admissible only if manufacturing and assembly satisfy the declared process envelope: material batch, temperature window, tool calibration validity, surface finish class, alignment procedure version. (Gate predicate; can be checked using evidence, but is not itself evidence.)

D-FIT-01 (Duty). ProcessEngineer SHALL ensure A-FIT-01 holds for the production lot and SHALL not release the lot for use when A-FIT-01 is false. (References A-FIT-01.)

E-FIT-01 (Evidence carriers). Evidence carriers used to adjudicate A-FIT-01 include CMM reports, tool calibration certificates, assembly logs, temperature traces, and datum scheme pins. (References A-FIT-01 and L-FIT-01; avoids RFC deontics.)

D-FIT-02 (Duty-to-evidence linkage). QualityEngineer SHALL retain/expose the carriers referenced in E-FIT-01 for the production lot. (References E-FIT-01 by ID.)

E-FIT-02 (Observed). For lot L123 and window Γ_time=[t1..t2], under conditions pinned to A-FIT-01 and using carriers in E-FIT-01, measured coaxiality was within tolerance zone T (interpreted per L-FIT-01). (References A-FIT-01, L-FIT-01, and E-FIT-01.)

Readable recomposition

Tech bundle:

  • Meaning of coaxiality: L-FIT-01.
  • Boundary arity/participants: L-FIT-02.
  • When the claim is admissible: A-FIT-01.
  • Who is responsible: D-FIT-01.
  • What we observe and keep as carriers: E-FIT-01 and measured outcome E-FIT-02 (with retention duty D-FIT-02).

Plain paragraph: “‘Ensures coaxiality’ is made precise by fixing the definition and datum scheme (L-FIT-01) and by making the boundary participants explicit (L-FIT-02). The coaxiality claim is only applicable under the declared manufacturing/assembly envelope (A-FIT-01), which the process engineer is accountable for maintaining (D-FIT-01). Compliance is adjudicated using the measurement and process carriers listed in E-FIT-01; for lot L123 over Γ_time=[t1..t2], the observed coaxiality was within tolerance E-FIT-02.”

Example 3 — Management (project “approved/aligned”)

Draft sentence (non-conformant)

“The project is approved.”

Atomize + Route

L-PRJ-01 (Definition). approved(project, approvalKind) is defined as a relation kind; approval kinds include: “sponsor-signoff”, “stage-gate-pass”, “budget-authorized”, “staffing-assigned”, etc. (Truth-conditional: disambiguates kind and polarity.)

A-PRJ-01 (Gate predicate: stage entry). For starting execution work, ExecutionAdmissible(project) holds iff required approvals are present and required prerequisites are satisfied (e.g., risk review completed, budget line exists, key roles staffed). (This is the real “may start work” gate; references L-PRJ-01 for what counts as approvals.)

D-PRJ-01 (Duty). ProjectOwner SHALL not initiate execution unless A-PRJ-01 holds, SHALL keep the approval registry current, and SHALL retain/expose the evidence carriers referenced in E-PRJ-01. (References A-PRJ-01 and E-PRJ-01 by ID.)

E-PRJ-01 (Evidence carriers). Evidence carriers used to adjudicate A-PRJ-01 include: signed decision record IDs, meeting minutes pins, budget system references, staffing assignment records, and gate checklist snapshots. (References A-PRJ-01; avoids RFC deontics.)

E-PRJ-02 (Observed state). As of Γ_time=snapshot(t), a resolvable gate-status carrier (e.g., GateChecklistSnapshot#…) indicates A-PRJ-01 holds, with the referenced evidence set pinned as {DecisionRecord#…, BudgetLine#…, StaffingAssignments#…} (carrier classes as per E-PRJ-01).
(Observed / pinned state; references A-PRJ-01 and E-PRJ-01; includes carrier instance(s), not just carrier classes.)

Readable recomposition

Tech bundle:

  • “Approved” is not one relation: L-PRJ-01 defines approval kinds.
  • “May start execution” is a gate predicate: A-PRJ-01.
  • Owner accountability: D-PRJ-01.
  • Carriers and adjudication: E-PRJ-01 and observed snapshot E-PRJ-02.

Plain paragraph: “Instead of a generic ‘approved’, we select an explicit approval kind as defined in L-PRJ-01 and treat ‘may start execution’ as an admissibility gate (A-PRJ-01). The project owner is accountable for not starting execution unless that gate holds and for keeping the approval registry current (D-PRJ-01). Gate status is adjudicated using the pinned carriers listed in E-PRJ-01; as of snapshot t, the evidence indicates the gate holds (E-PRJ-02).”

A compact “recomposition pattern” you can reuse verbatim

Tech register (2–5 lines)

“This boundary claim is defined by L-…, is applicable only under A-…, is accountable under D-…, and is adjudicated using evidence carriers E-…. Observed status/value is E-… for Γ_time=….”

Plain register (1 paragraph)

“We mean [short label] in the sense of L-…. It’s only meant to be used when A-… holds. [Role] is responsible for maintaining that condition (D-…). Whether it holds is checked using E-…, and the latest recorded status/value is E-….”