Library / First Principles Framework (FPF) - Core Conceptual Specification
Jump to passage
In this reading

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 05:29:54 UTC · snapshot created 2026-10-03 05:30:57 UTC · last check 2026-10-03 06:45:03 UTC

A.6:4.2 - Boundary Discipline Matrix: classify by A.6.B (the Boundary Norm Square)

Normative source. The canonical 2×2 square (the two A.6.B distinctions, quadrant semantics, form constraints, and cross‑quadrant reference rules) is defined in A.6.B. This section provides a short operational summary and worked rewrites only.

The 2×2 matrix crosses two independent distinctions:

  • Modality family: truth-conditional versus governance content. For permission-looking wording, the selected A6-AW-* row states which side applies; A.2.8.PER membership alone does not.
  • Adjudication substrate: in‑description vs in‑work (whether satisfaction is decided from the description alone or requires observing executed work and carriers).

Operational summary (quadrant → canonical claim layer in the stack):

  • L (Laws & Definitions) → Signature.Laws (truth‑conditional semantics, in‑description)
  • A (Admissibility & Gates) → Mechanism.AdmissibilityConditions (runtime entry predicates; a predicate may consume an exact grant or finding selected by A.6.B:8.4.1, but it neither creates nor resolves that object)
  • D (Deontics) → generic-prescription or individual-duty A.2.8 claims and A6-AW-NORM-GRANT
  • E (Work-Effects & Evidence) → actual-occurrence, evaluated-finding, and evidence claims, including the applicable E-side A6-AW-* row

Atomicity rule:

If a sentence mixes logical jobs, for example “MUST” plus a gate predicate plus an effect claim, it is not classifiable as a single statement. Per A.6.B, split it into atomic claims so each one has exactly one quadrant and, ideally, an identifier you can reference.

Micro‑template: Atomize → Classify → Place → Identify EntityOfConcern → Register when useful

  1. Split the sentence into atomic claims, one logical job each.
  2. Assign each claim to exactly one quadrant (L/A/D/E) using the matrix.
  3. Place each claim into its correct section or publication form (stack layer + section).
  4. Anchor A.7: name what each claim is about, separately from the episteme carrying it. Add publication and carrier relations when they change interpretation. For permission-looking wording, bind the direct object and participants required by the selected A6-AW-* row; the selected subject pattern or kind of direct object never supplies the quadrant.
  5. Register when useful: add the atomic claim to the Claim Register if used. Downstream faces cite the claim by ID or canonical location and preserve its meaning in any explanation.

Action outputs after classification:

  • implement or repair an admissibility predicate when the claim being made is A-*;
  • repair the exact normative source for a generic D claim, the actual duty bearer and A.2.8 result for an individual D claim, or the direct object named by the selected permission row;
  • recover the exact actual occurrence, evaluated finding, or evidence path named by an E claim; use the selected E-side A6-AW-* row when permission wording is current;
  • publish or update an MVPK face that cites L/A/D/E claims by ID or canonical location and explains them faithfully where its readers need prose;
  • reopen the exact subject pattern when the classified statement is used beyond boundary wording; the selected A6-AW-* row names the permission-side subject pattern;
  • downgrade the visible wording to cue use or source-finding only when the exact source is missing;
  • narrow the unsupported Work or reliance claim; allow a local or reversible use only on its own adequate basis and stated stop condition, or block the unsupported use while its source is repaired.

Informative example. Example rewrite (mixed → atomic):

Before (mixed, not classifiable yet): “Clients MUST include header X; otherwise the request is invalid and the system logs NotAdmissible.”

Recovered source clauses:

  • “Clients MUST include header X.”
  • “If a request lacks header X, the request is invalid.”
  • “If a request lacks header X, the system logs NotAdmissible.”

Recover the intended invalidity/admissibility meaning before fully classifying the second clause. The third clause states a generic logging rule; it reports no particular observed request.

Additional hypothetical illustration. Suppose a separate boundary policy defines invalidity here as failure of the entry condition below and adds an implementer duty to the quoted Clients duty. Also suppose the observation stated in E-OBS-1 actually occurred in this hypothetical case:

  • A-AC-1 (Quadrant A, Mechanism.AdmissibilityConditions): hasHeader(req, "X") is a necessary entry condition.
  • D-CL-1 (Quadrant D, Norms-and-commitments): “Client implementers MUST include header X in each request to this boundary (A-AC-1).”
  • E-OBS-1 (Quadrant E, Evidence-and-carriers): “For the selected request req lacking header X (A-AC-1), the system logged NotAdmissible; the observer recovered its AuditLogEntry{code="NotAdmissible"} in the audit stream.” The carrier schema is an additional illustrative choice. Logging depends on the absence of X, including when the request was not actually rejected.

Informative example. Example rewrite (guarantee + SLA + measurement + enforcement):

Before (mixed contract prose): “The service guarantees 99.9% availability per calendar month and MUST keep p95 latency under 200ms; breaches are penalized; operators SHALL alert on violations.”

Recovered source clauses:

  • “The service guarantees 99.9% availability per calendar month.”
  • “The service MUST keep p95 latency under 200ms.”
  • “Breaches are penalized.”
  • “Operators SHALL alert on violations.”

Recover the guarantee’s meaning and bearer, the measurement and acceptance basis, and the breach trigger, penalty and applicable parties. Use A.6.C for the unresolved contract meanings and A.6.B to classify the resulting atoms. The split alone does not settle them.

Additional hypothetical illustration. Suppose a separate policy identifies Provider and the service being measured, states the exclusions and workload W, defines the availability and latency metrics, and sets the two criteria evaluated below. In addition to the quoted alert duty, it requires paging within 5 minutes. The following E-claims assume that the stated evaluations and observation actually occurred in this hypothetical case; the alert observation concerns a separate violation case.

  • D-SLA-1 (Quadrant D, Commitments and SLA): “Provider SHALL meet the availability and latency criteria evaluated by E-SLA-AVAIL-1 and E-SLA-LAT-1 under the stated exclusions.”
  • E-SLA-AVAIL-1 (Quadrant E, Evidence-and-carriers): “The evaluation of the observed calendar month T reported availability ≥ 0.999, with measurements recorded in carrier UptimeProbeSeries from viewpoint VP.ExternalMonitor.”
  • E-SLA-LAT-1 (Quadrant E, Evidence-and-carriers): “The evaluation under workload W reported latency_p95 < 200ms, with measurements recorded in carrier LatencyMetricSeries from viewpoint VP.Client.”
  • D-OPS-ALERT-1 (Quadrant D, Ops duty): “Operators MUST page on breach of the criteria evaluated by E-SLA-AVAIL-1 or E-SLA-LAT-1 within 5 minutes (additional policy).”
  • E-ALERT-1 (Quadrant E, Evidence-and-carriers): “In the separate violation case, the operator’s page was observed in carrier AlertEvent{ruleId,firedAt,target} and can be joined via incidentId.”

These added policy and observation premises do not resolve the original guarantee, duty bearer or penalty clause.

See A.6.B:4–A.6.B:6 for the normative square, quadrant form constraints, and explicit cross‑quadrant link patterns (notably: D→A, E→A, D→E, and A/E→L).

A.6:4.2.1 - Authority-wording split examples

These examples are informative. They separate authority wording from the evidence, assurance, commitment, gate-passage, or Work claim being made.

Before (mixed): “This API is approved for production use and guarantees safe rollback.”

Recovered source clauses:

  • “This API is approved for production use.”
  • “This API guarantees safe rollback.”

Recover the approval’s direct object and ground under the applicable A6-AW-* row, and the rollback subject and safety predicate. Both source claims remain unresolved until that meaning is supplied.

Additional hypothetical illustration. Assume supplied signature vocabulary defines the API operation and rollback terms; a separate boundary policy gives the request-admission predicate, policy window and exclusions. For E-API-1, additionally assume that a named evaluation of an independently identified rollback occurrence actually reported success under a stated success criterion and observation basis:

  • L-API-1 (Quadrant L): the API operation and rollback terms are defined in the supplied signature vocabulary.
  • A-API-1 (Quadrant A): a request is admissible only under the named subject, action, object, context, and policy-version predicate.
  • D-API-1 (Quadrant D): the exact provider policy prescribes maintaining or enforcing A-API-1 under the named window and exclusions. If the claim is instead that one actual provider or operator bears this duty, cite its separately instituted A.2.8 commitment.
  • E-API-1 (Quadrant E): the named evaluation reported rollback success under its stated success criterion. Possible evidence inputs include the named work traces, audit records, or metrics. A gate decision carrier may support the exact gate-passage claim; rollback execution needs its own occurrence and evidence basis.

In this additional case, A-API-1 applies A6-AW-GATE, while an approval badge remains A6-AW-SOURCE unless another row’s closing facts are present. The original production approval and safe-rollback guarantee remain unresolved. A success result alone does not establish the unspecified safety claim.

For a filled grant/exercise/evidence case and its near-misses, use A.6.B:8.4.5.4. It applies A6-AW-NORM-GRANT, A6-AW-EXERCISE, and the separate A.10 evidence claim by value.

Then:

  • if appearance hides the prerequisite for action or reliance, enter A.15.4; use A.15 for enactment alignment;
  • if evidence, currentness, or provenance is live, attach the A.10 evidence relation;
  • if an actual named assurance claim is current, use B.3 for its exact target claim, argument, bounded assurance use and AssuranceResult; otherwise keep trust, readiness, compliance or release questions with their direct patterns;
  • if an actual gate decision or passage is asserted, classify it as a separate E claim and cite the exact A.21 GateDecisionResult, bounded action, applicable GateProfile application, complete required GateCheckApplicationResult set, decisionValue, action consequence, scope/window, and recheck condition; use a short GateCheckRef only for a selected publication structure and a DecisionLog only when audit or reuse is current;
  • if a flow witness or constraint witness is asserted, cite A.20 ConstraintValidity status or witness;
  • if a permission-looking claim is asserted, use the selected A6-AW-* row and its subject pattern; an entry predicate or GateDecisionResult does not substitute for another row;
  • if release, deployment, rollback, or execution Work is asserted, cite the exact A.15.1 dated occurrence; then use only the applicable A.15.1:4.6 row for an application result, A.15.PROD production branch, delivery/transfer relation, evaluation/acceptance relation, or A.10 evidence path. None is an intrinsic Work field;
  • if the phrase is only an action invitation or cue, keep it in A.6.A, A.16, or A.16.1 according to the current kind.

Policy engines, credentials, registers, provenance, and attestations can supply policy decisions, source claims, currentness, or evidence. Start a visible permit, badge, or registry value at A6-AW-SOURCE; move to another branch only when its named direct object and participants are independently established.