OQ-002 D3: Decimal Failure Outcomes and Special Values¶

Status: ACCEPTED Accepted: 2026-11-08 Decision: Decimal overflow, underflow, division by zero, and invalid Decimal operations produce explicit arithmetic failures (Runtime faults); no Infinity or NaN can exist in a Kyllo program Category: Numeric Types and Semantics

1. Decision¶

D3 — Decimal failure outcomes and special values. Decimal overflow, Decimal underflow, division by zero, and invalid Decimal operations produce explicit arithmetic failures; they do not produce special values. No Infinity or NaN value can be produced, stored, compared, or serialized in a Kyllo program. Underflow means the GDA Underflow signal: the result is tiny and inexact. A tiny-but-exact subnormal result is a value, not a failure. Finite division by zero and zero divided by zero are both the "Division by zero" arithmetic failure. Arithmetic failures from Decimal operators are Runtime faults under TECHSPEC-10 §6 — failures detected by the runtime environment, reported distinctly from declared errors. At the end of each operation the runtime examines the operation's complete signal record: if it contains Division by zero, Overflow, Underflow, or Invalid operation, the operation has no result value and the corresponding arithmetic failure propagates explicitly, with the complete signal record preserved as its cause, and must not be mistaken for SUCCESS, and no default value is substituted; if it contains only Inexact, Rounded, Subnormal, or Clamped, the operation's finite result stands. In const-eval the same failure is a compile-time diagnostic with a source location. The trap configuration is not set by this decision (OQ-004), but whatever configuration OQ-004 sets must deliver these observations: a disabled trap must never silently yield a special value or a success. This decision does not decide literal format or literal typing (D4/D5), the conversion mechanism (D6), the canonical external form (D7), integer division/remainder (OQ-003), or the rounding context, trap configuration, and inexact-result reporting (OQ-004). The minimum commitments in §6 of this record are part of this decision.

This decision is one part of OQ-002 ("Exact numeric representation and Decimal conformance target"). It resolves D3, the third foundational question of OQ-002. OQ-002 itself remains Open until D4–D7 are resolved. D1 (the GDA conformance foundation) and D2 (Decimal equality for finite operands) were accepted 2026-11-08; D3 builds on both and changes nothing about either. In particular, D2's finite-operand scoping is discharged by D3: because no NaN or Infinity value can exist in a Kyllo program, no comparison can ever receive one as an operand.

2. The failure conditions¶

The four failure conditions are the General Decimal Arithmetic (GDA) conditions, as adopted by D1 (D3 report §2.1; GDA 1.70, "Exceptional conditions", pp. 51–54):

Division by zero: division of a finite number by zero was attempted (during a divide or divide-integer operation; GDA also includes a power operation with a negative right-hand operand, which is not a Kyllo operator), and the dividend was not zero. GDA's default result is [sign,inf]; Kyllo produces a failure instead.
Division undefined (0 ÷ 0): division by zero was attempted and the dividend is also zero. In GDA this signals Invalid operation with result [0,qNaN]. At the Kyllo level it is the same failure as finite division by zero (§6, commitment 5): the distinction exists in GDA only because the default results differ, and D3 discards the default results.
Overflow: the adjusted exponent of a result, after rounding, would be greater than Emax (6144 in the fixed Kyllo context). GDA's default result for round-half-even is [sign,inf]; Kyllo produces a failure instead. Overflow always coincides with Inexact and Rounded (D1).
Underflow: the result is both inexact and subnormal (adjusted exponent below Emin, −6143). See §3 for the precision point: a tiny-but-exact result is not an underflow. GDA's default result is a subnormal rounded to Etiny (−6176), which may be 0; Kyllo produces a failure instead. Underflow always coincides with Inexact, Rounded, and Subnormal (D1); the complete signal set may also include Clamped when the result rounds to zero (D3 report §3.4).
Invalid operation: the GDA list (D3 report §2.1), as it applies to Kyllo's operators. The reachable cases in the initial language are: remainder with a zero divisor, divide-integer with too many digits (Division impossible), and 0/0 (see above — counted as Division by zero at the Kyllo level). The remaining GDA cases (Infinity arithmetic, quantize with an infinite operand, ln/log10/square-root/power errors) are unreachable while special values do not exist and those operations are not Kyllo operators; if a later decision adds such an operation, its invalid cases are failures under this decision.

GDA defines these conditions, their signals, and their default results (Infinity, NaN). GDA does not define how exceptions are reported or handled: "This specification does not define the manner in which exceptions are reported or handled." (p. 51.) That observation — what the program sees — is what D3 decides. The default results exist only when the trap is disabled; a language that examines every operation's signal record and fails on the failure conditions never observes them.

3. No special values — and the subnormal distinction¶

No Infinity or NaN value can be produced, stored, compared, or serialized in a Kyllo program (§6, commitment 2). The values exist in GDA's model (D1 report §2.2) but not in the language. This is the GDA-sanctioned shape: GDA's own Appendix A (the X3.274 subset) defines an arithmetic in which "exceptional conditions other than the informational conditions (Lost digits, Inexact, Rounded, and Subnormal) must be treated as errors, and results after these errors are undefined. Special values and subnormal numbers, therefore, are not part of the arithmetic." (p. 57.) D3 adopts the subset's error treatment while keeping subnormal values, which the subset excludes and D1 adopted. The distinction is deliberate and is stated here, not left implicit:

Underflow (failure): the GDA Underflow signal — the result is tiny and inexact. Example: 1E-6176 / 10 (verified in the D3 report, §3.2).
Tiny but exact (value): the Subnormal signal only, no Underflow. Example: 1E-6143 / 1E10 = 1E-6153, exact (verified in D1). This is a legitimate, representable value — not a failure.
Normal-range inexact (value): Inexact + Rounded only. 1 / 3 is inexact and fine. Whether inexactness is a failure "where exactness is required" is OQ-004's, not D3's.

This precision matters because the alternative — "any subnormal result is a failure" — would make exact tiny results fail, would contradict D1's adoption of the subnormal range (Etiny −6176), and would conflate two conditions GDA deliberately separates.

The consequences of "no special values" are recorded, not left to inference:

Comparison involving NaN or Infinity cannot occur: D2's finite-operand scope is complete, and the D2 report §7.1 questions (what == does with a NaN operand, what Infinity == Infinity is) are answered by exclusion — there is no such operand.
Map/Set keys and elements cannot be special values: the D2 report §7.1 question about NaN keys is answered by exclusion — a NaN key cannot exist, so it cannot be unfindable.
Serialization has no special values to emit: what deserialization does with a document claiming a special value is D7's decision (§7).
Literal syntax cannot denote a special value: the strings "Infinity", "NaN", and "sNaN" (which GDA's string syntax accepts, p. 17) must not be accepted as Decimal literals. D5 decides the literal syntax; D3 constrains it (§7).

4. The category assignment: Runtime faults¶

Arithmetic failures from Decimal operators are Runtime faults under TECHSPEC-10 §6: "Failures detected by the runtime environment." They are not declared errors (the operator's type does not declare them — the operators return Decimal, not Result), not external failures (they originate in the program's own arithmetic), and not internal faults (they do not indicate a violated runtime or language guarantee — they are defined outcomes of defined operations on defined inputs). TECHSPEC-10 §7 requires them to be "reported distinctly from declared errors": a runtime fault and a declared error must not be confused, including by the compiler's handling checks.

The declared-error pattern remains available and unchanged. A function that anticipates a failure can check its inputs and return ERROR(...) in a Result (the TECHSPEC-10 §2 divide example: the function checks denominator == 0 itself and returns ERROR(DivisionError.DivideByZero)) — that is a choice the function makes, and the operator inside it is never reached with the failing inputs. D3 does not change the divide example; it makes the manual check a choice rather than the only thing standing between the program and an Infinity.

By the same reasoning, arithmetic failures from Integer operators are Runtime faults too — but Integer's failure outcomes were already decided (TECHSPEC-21 §2: explicit failures, checked arithmetic, no silent wrap), so D3 does not re-decide them. The category assignment for Integer operator failures is stated here as a consequence of the same argument, not as a new decision about Integer.

5. The D3-defined point and the observation rule¶

At the end of each Decimal operation, the runtime examines the operation's complete signal record (D1 commitment 5: the runtime must preserve the complete signal set of each operation). If the record contains Division by zero, Overflow, Underflow, or Invalid operation, the operation has no result value: the corresponding arithmetic failure propagates explicitly, with the complete signal record preserved as its cause, and must not be mistaken for SUCCESS, and no default value is substituted (TECHSPEC-21 §8; TECHSPEC-39 §11). If the record contains only Inexact, Rounded, Subnormal, or Clamped, the operation's finite result stands. In const-eval (TECHSPEC-43 §7), the same failure is a compile-time diagnostic with a source location, not a runtime fault.

Trap precedence (GDA p. 54, D1 report §2.7) matters in one case: an operation that signals both a failure condition and an informational condition (Overflow always coincides with Inexact + Rounded; Underflow always with Inexact + Rounded + Subnormal) must be reported as the failure, with the complete signal set preserved in the failure's cause — not as the informational condition, and not as only the highest-precedence signal.

The boundary with OQ-004 (trap configuration). D3 decides what is observed (a failure, of a given category, propagating with its cause). OQ-004 decides the trap configuration — which signals trap (raise immediately) and which merely set flags. The configuration is constrained by D3: it must deliver D3's observations. Concretely, a trap configuration in which the Underflow trap is disabled (as in Python's defaults) is permissible only if the runtime still checks the operation's signal record at the D3-defined point and produces the underflow failure — a disabled trap must never silently yield a special value or a success. If OQ-004's configuration ever conflicted with D3's outcomes, D3's outcomes win: the outcomes are language semantics; the trap configuration is a mechanism choice. This is the same boundary D1 drew (commitment 5: no unilateral backend trap choices), now with D3's outcomes as the constraint it must satisfy.

6. Minimum commitments¶

The four failure conditions are failures. Decimal overflow, Decimal underflow, division by zero, and invalid Decimal operations produce explicit arithmetic failures. The conditions are the GDA conditions (§2): Overflow (adjusted exponent above Emax after rounding), Underflow (tiny and inexact — §3), Division by zero (finite ÷ 0, including ÷ −0), Invalid operation (the GDA list in §2, as it applies to Kyllo's operators — including remainder with a zero divisor and division-impossible). The GDA default results (Infinity, NaN) are not produced.
No Infinity or NaN value can be produced, stored, compared, or serialized in a Kyllo program. No operation returns one; no literal denotes one (a constraint on D5, §7); no variable can hold one; no comparison can receive one as an operand; no serialization can emit one. The values exist in GDA's model (D1 report §2.2) but not in the language. The TECHSPEC-39 §8 sentence about special values is therefore read as vacuous for Kyllo programs: there are no special values to follow.
Category: Runtime fault. Arithmetic failures from Decimal operators (and, by the same reasoning, from Integer operators, whose outcomes were already decided) are Runtime faults under TECHSPEC-10 §6 — failures detected by the runtime environment. They are reported distinctly from declared errors (TECHSPEC-10 §7). The declared-error pattern (a function checking its inputs and returning ERROR(...) in a Result) remains available and unchanged; it is a choice the function makes, not the operator's behavior.
Underflow means the GDA Underflow signal. A failure for underflow occurs exactly when the result is tiny and inexact (adjusted exponent below Emin, with inexactness). A tiny-but-exact subnormal result is a value, not a failure. A normal-range inexact result (e.g. 1 / 3) is not a failure under D3.
Division by zero is one failure. Finite ÷ 0 and 0 ÷ 0 are both the "Division by zero" arithmetic failure of TECHSPEC-21 §8. The GDA-level distinction (Division by zero vs Division undefined) is preserved in the failure's cause (the complete signal record) but does not produce two different Kyllo failures. Division by −0 is the same failure.
The D3-defined point and the observation rule. At the end of each Decimal operation, the runtime examines the operation's complete signal record. If the record contains Division by zero, Overflow, Underflow, or Invalid operation, the operation has no result value: the corresponding arithmetic failure propagates explicitly, with the complete signal record preserved as its cause, and must not be mistaken for SUCCESS, and no default value is substituted (TECHSPEC-21 §8; TECHSPEC-39 §11). If the record contains only Inexact, Rounded, Subnormal, or Clamped, the operation's (finite) result stands. In const-eval (TECHSPEC-43 §7), the same failure is a compile-time diagnostic with a source location, not a runtime fault.
Trap configuration stays OQ-004's, constrained to deliver D3's outcomes. The trap configuration (which signals trap vs merely flag) is not set by D3. Whatever configuration OQ-004 sets must deliver the observations in commitment 6: a disabled trap must never silently yield a special value or a success. No backend may choose a trap configuration unilaterally (D1 commitment 5), and no backend may produce an Infinity or NaN value, construct a Decimal from the strings "Infinity", "NaN", or "sNaN", or translate a Python exception type (rather than the signal record) into a Kyllo failure. The backend requirements in §11 (a)–© are part of this commitment.

7. What D3 does not decide¶

D4/D5 (literal typing/format): D3 constrains D5 in one way — the strings "Infinity", "NaN", and "sNaN" must not be accepted as Decimal literals, because the values they denote cannot exist. D5 decides the literal syntax and says how a rejected literal is diagnosed; D3 does not write it. A literal with more than 34 significant digits, and a bare integer-looking literal's type, remain D4/D5's.
D6 (conversion mechanism): what a failed conversion produces. "Invalid numeric conversion" is already an entry in the TECHSPEC-21 §8 taxonomy; D6 decides the mechanism (including what cohort a conversion produces, and whether a conversion that cannot be performed is a declared error in a Result or a runtime fault). D6's mechanism must be consistent with D3's category reasoning (§4).
D7 (canonical external form): the canonical form for finite values. D3 simplifies D7 — there are no special values to serialize — but D7 still decides the form, including whether equal values serialize identically (D2's constraint) and whether cohorts round-trip. D7 must also decide what happens when deserializing a document that claims a special value (e.g. an external JSON "Infinity"): under D3 it cannot be a Decimal value, so D7 must say whether it is a parse failure, a conversion failure, or something else.
OQ-003 (integer division/remainder): Decimal % with a zero divisor is an Invalid operation in GDA and therefore a failure under D3 (§2); the remainder operation itself — its semantics for negative operands, its existence for Decimal — is OQ-003's. Integer division by zero is already decided (explicit failure, TECHSPEC-21 §2). divide-integer with too many digits (Division impossible) is an Invalid operation in GDA and therefore a failure under D3, if OQ-003 defines divide-integer for Decimal at all.
OQ-004 (rounding context, trap configuration, inexact reporting): the boundary is §5. OQ-004 sets the trap configuration and the inexact-reporting rules, constrained to deliver D3's outcomes. OQ-004 also decides "inexact arithmetic where exactness is required" (TECHSPEC-21 §8) — when an inexact result is a failure rather than a detectable condition — and the explicit rounding operations (quantize, round-to-integral-exact, round-to-integral-value), whose failure behavior follows D3 (a quantize that would require more precision than is available is an Invalid operation in GDA).
OQ-011 (Python execution strategy): D3 adds backend requirements to the OQ-011 list (§11), in the same class as D1's commitment 6 and D2's §7.6 requirements. Note for D2's §7.6 requirement (b): under D3, NaN can never reach a comparison, so the comparison path needs no NaN handling — D2's requirement is discharged by exclusion.
OQ-017 (determinism): D3's failures are deterministic across targets (same conditions, same outcomes, same causes). No further determinism decision is needed for failure outcomes.
The fault-handling construct: how a program responds to a runtime fault — catch it, declare it, terminate, recover — is not specified anywhere in the sources (TECHSPEC-10 §5 states recovery rules but no syntax), and D3 does not invent it. It is a language-design decision in TECHSPEC-10's territory, not OQ-002's. Until it is decided, a runtime fault is an unhandled failure: it propagates and the program does not continue past it. That is the honest statement of the current state, not a decision that unhandled faults are the desired final behavior.
The fault's diagnostic shape: TECHSPEC-10 §6 requires runtime faults to "produce diagnostic information where possible", and TECHSPEC-21 §8 requires the cause to be preserved. The exact type/shape of that diagnostic (what fields, what the compiler checks) is a later design decision. The complete signal record is the content the diagnostic must carry; its form is the follow-up.
Integer equality: still open from D2 (§7.5): no equality rule for Integer is specified anywhere. It should be stated explicitly alongside a future integration, as a documentation completion, not as a new design decision — or, if Blake disagrees that it is exact, as its own small decision.

8. Rationale¶

It is what the specification already says, read as a whole. Integer's failures are explicit failures (TECHSPEC-21 §2); the taxonomy lists Decimal overflow/underflow and division by zero alongside them (TECHSPEC-21 §8); "Division by zero must never produce an unreported result" (TECHSPEC-21 §5); "Arithmetic failures must not silently produce SUCCESS" (TECHSPEC-21 §8); "An expression must not silently substitute a default value after failure" (TECHSPEC-39 §11); "AI agents must never be able to mistake an attempted operation for a successful one" (TECHSPEC-10 §8). D3 follows the spec's own words; the special-values alternative would require reading "explicit handling" (TECHSPEC-21 §3) as "return a special value", which nothing in the text supports — and which the surrounding rules contradict.
It is the GDA-sanctioned shape. GDA's own Appendix A defines an arithmetic in which the non-informational conditions are errors and special values are not part of the arithmetic (X3.274 subset). D3 adopts that error treatment while keeping subnormal values (which the subset excludes and D1 adopted) — a deliberate, stated combination (§3).
It is what the core example requires. The Bank Account's invariants (balance >= 0, "increase the balance by exactly the deposited amount") are statable only over finite values. Under the special-values alternative, balance >= 0 is unstatable for a NaN balance (NaN is neither >= 0 nor < 0), and an Infinity balance would satisfy >= 0 while being the result of a failed computation.
It is the cheapest to specify, implement, and maintain. One rule per condition plus the category assignment; the backend checks the signal record it already has to capture; no special-value machinery to build, test, or preserve anywhere (comparison, serialization, const-eval, Map/Set).
It keeps the hard questions separate. D3 decides failure outcomes and the special-values question. It does not decide the trap configuration (OQ-004), the literal syntax (D5), the conversion mechanism (D6), the canonical form (D7), or a fault-handling construct (§7).

The alternatives considered (D3 report §4): D3b special values (Infinity/NaN propagate silently; requires inventing the whole special-values story — what NaN means, NaN == NaN, Infinity comparison, serialization, NaN Map keys — and an Infinity is a silent acceptance of overflow unless every use site checks); D3c saturation (constrained out by TECHSPEC-21 §§1–2 and TECHSPEC-39 §11 — recorded only to show it was considered); D3d mixed per condition (possible, but no rule in the spec distinguishes the conditions, and it doubles the specification surface); deferring D3 (not recommended — leaves == undefined for special-value operands, the TECHSPEC-39 §8 sentence dangling, and the D1 commitment-6 "D3-defined point" without a definition).

9. Consequences¶

TECHSPEC-21 §§3, 5, 8, 9 are amended: "explicit handling" is now defined as explicit failure; division by zero produces a Runtime fault; the four conditions are assigned to the Runtime fault category; the D3-defined point is specified.
TECHSPEC-10 §§2, 6 are amended: arithmetic failures from operators are Runtime faults, reported distinctly from declared errors; the divide example's manual check is recorded as a choice, not the only guard.
TECHSPEC-39 §§8, 11 are amended: the special-values sentence now has a referent (there are no special values in Kyllo programs); the expression-failure observation rule is recorded.
TECHSPEC-43 §7 is amended: const-eval arithmetic errors are compile-time diagnostics under D3 (the D1 amendment said failure reporting "follows D3, not D1" — D3 has now spoken).
TECHSPEC-26 (file TECHSPEC-27) §7 is amended: there are no special values to serialize; what deserialization does with a claimed special value is D7's decision.
TECHSPEC-24 §§4–5, 8 are amended: no special-value keys or elements can exist (the D2 §7.1 question answered by exclusion).
TECHSPEC-57 is amended with a D3 register note; OQ-002 remains Open pending D4–D7.
The Language Guide Types page is amended to teach the failure outcomes.
The glossary and cross-reference index gain D3 entries.
The Unresolved Questions register records D3 as decided (alongside D1 and D2); OQ-002 remains Open; the open count stays 28.
The Decision Records index gains a D3 row (ACCEPTED); the accepted count becomes 4.
The D3 report (reports/oq-002-d3-failure-outcomes-special-values.md) is committed with the acceptance.
The CHANGELOG (0.2.11) records the acceptance as documentation-level, not compiler implementation.

Consequences of rejecting (recorded for the record; Blake accepted as written)¶

If D3 were rejected, the failure outcomes would remain undefined: == and the ordering operators would stay undefined for NaN/Infinity operands, the TECHSPEC-39 §8 special-values sentence would stay dangling, Map/Set behavior for special-value keys would stay undefined, D6 and D7 would each carry the special-values question as an open variable, and the D1 commitment-6 "D3-defined point" would have no definition — the backend could not implement exception translation.

10. Acceptance Criteria¶

The D3 report states its decision in §9 and its minimum commitments in §6; it has no separate acceptance-criteria section. The criteria below are derived from the report's §6 commitments and §5 rationale, and from the change-management process, and are the criteria §12 maps to evidence.

The decision record exists and states the decision (§1), the failure conditions (§2), the no-special-values rule and the subnormal distinction (§3), the category assignment (§4), the D3-defined point and the observation rule (§5), the minimum commitments (§6), and what D3 does not decide (§7).
TECHSPEC-21 §§3, 5, 8, 9 are amended with the failure outcomes, the Runtime fault category, the underflow precision point, and the D3-defined point; TECHSPEC-10 §§2, 6 are amended with the category assignment; TECHSPEC-39 §§8, 11 are amended with the special-values referent and the observation rule; TECHSPEC-43 §7 is amended with the const-eval diagnostic rule; TECHSPEC-26 §7 is amended with the serialization consequence; TECHSPEC-24 §§4–5, 8 are amended with the no-special-value-keys rule.
The Unresolved Questions register records D3 as decided (alongside D1 and D2) while OQ-002 remains Open; the open count stays 28.
The Language Guide Types page teaches the accepted failure outcomes without resolving D4–D7, OQ-003, or OQ-004.
The glossary and cross-reference index gain D3 entries (Runtime fault; special value (GDA); Decimal underflow).
No D4–D7, OQ-003, or OQ-004 semantics are introduced by the integration; no fault-handling construct or fault diagnostic type is invented.
No normative source file (source-original/) is modified.
No IEEE 754 conformance claim of any version appears in the integration.
The X3.274 subset is cited as a precedent for the error treatment only, with the subnormal-values exclusion explicitly not adopted.
The CHANGELOG (0.2.11) records the acceptance as documentation-level, not compiler implementation.

11. Implementation Notes¶

Acceptance is documentation-level: it makes D3 an authoritative language-design decision in the specification. It does not imply that the compiler or runtime already implements or validates these rules. Compiler implementation, the Kyllo decimal runtime module, and conformance testing remain separate requirements.

Implementation complexity for the first Python backend is moderate for D3 itself: the backend must examine each operation's complete signal record at the D3-defined point (§5) and produce the failure from the signal record, never from the Python exception type (Overflow subclasses Inexact and Rounded in Python — translating by type would misclassify it). Backend requirements in the same class as D1's commitment 6 and D2's §7.6 requirements are added to the OQ-011 list: (a) the runtime must examine each operation's complete signal record at the D3-defined point and produce the failure from the signal record, never from the Python exception type; (b) the runtime must never produce an Infinity or NaN value, never construct a Decimal from the strings "Infinity", "NaN", or "sNaN", and never construct a Decimal from a float (D1's rule, reaffirmed); © the Underflow trap must be enabled or the flags checked — Python's defaults do not trap Underflow, so a backend relying on traps alone would miss underflows. These are requirements on OQ-011, not a decided runtime architecture.

Evidence: OQ-002 investigation report (reports/oq-002-numeric-representation-investigation.md, §4.3 C7–C9, §7.3 D3a/D3b/D3c); OQ-002 D1 report (reports/oq-002-d1-gda-conformance-foundation.md, §2.7/§3.7, §6 commitments 5–6, §7.1 D3 statement); OQ-002 D2 report (reports/oq-002-d2-decimal-equality.md, §7.1 D3 statement, §7.6 OQ-011 requirement (b)); OQ-002 D3 report (reports/oq-002-d3-failure-outcomes-special-values.md, §9 decision statement, §6 minimum commitments, §2 GDA condition definitions, §3 Python probes, Appendix A/B/C); General Decimal Arithmetic Specification Version 1.70 (25 March 2009, Cowlishaw), pp. 17, 27, 31–33, 51–54, Appendix A pp. 55–57; GDA dectest suite (divide.decTest, add.decTest, subtract.decTest, multiply.decTest, power.decTest, quantize.decTest, compare.decTest); Python 3.12 decimal documentation and empirical checks (D3 report Appendix B).

Design principle: Explicit boundaries. Predictable behavior. No silent arithmetic.

12. Acceptance¶

Accepted on 2026-11-08, as written — Blake said "Accept D3 as written" on the decision brief in the docs side chat. No refinement rounds: the §9 decision statement of the D3 report and the §6 minimum commitments were accepted verbatim. The §1 statement above is the report §9 statement with one mechanical adaptation: "The minimum commitments in §6 of this record are part of this decision" (the report says "of the D3 report"). The acceptance criteria in §10 were verified during documentation integration:

The decision record exists and states the decision (§1), the failure conditions (§2), the no-special-values rule and the subnormal distinction (§3), the category assignment (§4), the D3-defined point and the observation rule (§5), the minimum commitments (§6), and what D3 does not decide (§7).
TECHSPEC-21 §§3, 5, 8, 9; TECHSPEC-10 §§2, 6; TECHSPEC-39 §§8, 11; TECHSPEC-43 §7; TECHSPEC-26 §7; TECHSPEC-24 §§4–5, 8 are amended as specified.
The Unresolved Questions register records D3 as decided (alongside D1 and D2) while OQ-002 remains Open; the open count stays 28.
The Language Guide Types page teaches the accepted failure outcomes without resolving D4–D7, OQ-003, or OQ-004.
The glossary and cross-reference index gain D3 entries (Runtime fault; special value (GDA); Decimal underflow).
No D4–D7, OQ-003, or OQ-004 semantics are introduced by the integration; no fault-handling construct or fault diagnostic type is invented — cross-document consistency audit completed 2026-11-08 (read-only audit of the record and all eight amendments against the D3 report: no factual errors, no scope leaks, no IEEE conformance claim, no implementation claims; 0 blockers, 7 nits, 4 fixed in the record/amendments, 3 noted).
No normative source file (source-original/) is modified — verified by git status: only the D3 decision record (new), amendments (new), builder, CHANGELOG, and generated docs/ pages changed.
No IEEE 754 conformance claim of any version appears in the integration — the only IEEE mention in the record is §8 rationale 2's reference to GDA's Appendix A and the D3 report, not a claim that Kyllo conforms to IEEE 754.
The X3.274 subset is cited as a precedent for the error treatment only, with the subnormal-values exclusion explicitly not adopted.
The CHANGELOG (0.2.11) records the acceptance as documentation-level, not compiler implementation.

Interpretations recorded at acceptance¶

The X3.274 subset is a precedent for the error treatment only. D3 adopts the subset's rule that non-informational conditions are errors and special values are not part of the arithmetic. It does not adopt the subset's exclusion of subnormal values: D1 adopted the full GDA model including the subnormal range, and a tiny-but-exact subnormal result is a value under D3.
No program's meaning changes. No program's Decimal failure behavior was defined before D3; D3 defines it for the first time. Integer is untouched (its failure outcomes were already decided).
The fault-handling construct is not decided by D3. How a program responds to a runtime fault is not specified anywhere in the sources and is not decided by D3 (§7). Until it is decided, a runtime fault is an unhandled failure that propagates. That is the current state, not a decision that unhandled faults are the desired final behavior.
The trap configuration is OQ-004's, constrained by D3. If OQ-004's configuration ever conflicted with D3's outcomes, D3's outcomes win (§5).

Remaining open (not resolved by D3)¶

D4 (literal typing), D5 (literal format), D6 (conversions), D7 (canonical external form), OQ-003, OQ-004, and the trap configuration. OQ-002 remains Open until D4–D7 are resolved.
The fault-handling construct; the fault's diagnostic shape; Integer equality.

Scope of acceptance¶

Acceptance is documentation-level: it makes D3 an authoritative language-design decision in the specification. It does not imply that the compiler or runtime already implements or validates these rules. Compiler implementation, the Kyllo decimal runtime module, and conformance testing remain separate requirements.

Affected sections: TECHSPEC-21 §§3, 5, 8, 9, TECHSPEC-10 §§2, 6, TECHSPEC-39 §§8, 11, TECHSPEC-43 §7, TECHSPEC-26 §7, TECHSPEC-24 §§4–5, 8, TECHSPEC-57 (register note), Language Guide (Types), Glossary, Cross-Reference Index, Unresolved Questions register, Decision Records index, CHANGELOG.md (0.2.11).