OQ-002 D1: Decimal Conformance Foundation¶

Status: ACCEPTED Accepted: 2026-11-08 Decision: Adopt General Decimal Arithmetic (GDA) Specification Version 1.70 with a fixed Kyllo context as the arithmetic foundation for the Decimal type Category: Numeric Types and Semantics

1. Decision¶

D1 — Decimal conformance foundation. Kyllo adopts General Decimal Arithmetic (GDA), Specification Version 1.70 (25 March 2009, Cowlishaw), as the arithmetic foundation for the Decimal type, with a single fixed Kyllo context configuration: precision 34 significant decimal digits, rounding round-half-even, exponent limits Emin −6143 and Emax 6144 (limits on the adjusted exponent), and no clamping (fold-down) of result exponents. The GDA operation definitions adopted as Kyllo's semantic reference, the restrictions, and the exclusions are those listed in §4 of this record; the eight GDA signals exist as conditions with flags and trap-enablers, observable by the runtime, and the runtime must preserve the complete signal set of each operation (§5). This decision adopts GDA as the arithmetic foundation and as the semantic reference for the listed operation definitions only. It does not decide which GDA operations are exposed as Kyllo language operations beyond those already backing Kyllo's existing operators. It does not decide Decimal equality (D2), failure outcomes or failure representation or special-value behavior (D3), 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). It does not decide the Python runtime architecture (OQ-011) — it states requirements on OQ-011 (§6, commitment 6) — or the scope of deterministic execution guarantees (OQ-017). It does not claim IEEE 754 conformance of any version. The minimum commitments in §6 of this record are part of this decision: the frozen specification version, the fixed context configuration as language constants (realized in Python as fresh private execution contexts per operation, with clamp=0), the operation set, the representation model, the signal mechanism with complete signal preservation and no unilateral backend trap choices, the Python-backend rules, and conformance evidence against the GDA test cases for the adopted scope only.

This decision is one part of OQ-002 ("Exact numeric representation and Decimal conformance target"). It resolves D1, the first foundational question of OQ-002. OQ-002 itself remains Open until D2–D7 are resolved.

2. The Fixed Kyllo Context¶

A single fixed configuration applies to all Decimal operations:

• Precision: 34 significant decimal digits. This confirms the existing text (TECHSPEC-21 §3) as a Kyllo choice, not a GDA entailment.
• Rounding: round-half-even. This confirms the existing text (TECHSPEC-21 §3) as the context's rounding mode.
• Exponent limits: Emin −6143 and Emax 6144. The limits apply to the adjusted exponent (stored exponent + number of coefficient digits − 1), not to the stored exponent. These are the IEEE 754 decimal128 exponent limits, adopted as Kyllo's choice; they satisfy Emin = 1 − Emax.
• No clamping (fold-down) of result exponents. Only the adjusted-exponent limits apply. GDA 1.70 has no clamp parameter; clamping is a Python/IEEE-interchange concept. The semantic rule is: no clamping of result exponents. Its Python realization pins clamp=0 explicitly.
• Derived quantity: Etiny = Emin − precision + 1 = −6176, the minimum exponent for subnormal results. (Etop = Emax − precision + 1 = 6111 is a Python term, not a GDA 1.70 term.)

The configuration is a language constant. It is not a default, not mutable, not user-selectable, and not per-operation — unless OQ-004 later defines an explicit per-operation context, which would itself be a decision, not a drift.

Normal numbers span from 1×10^−6143 (adjusted exponent Emin) to just under 10^6145 (adjusted exponent Emax with a 34-digit coefficient); subnormal results extend down to 1×10^−6176 (Etiny).

3. The Arithmetic and Representation Model¶

• Numbers. A Decimal value is an abstract triple: sign, coefficient (an unsigned integer of up to 34 significant digits), and exponent. The value is sign × coefficient × 10^exponent.
• Variable per-value scale. A number carries its own exponent. 1.50 (coefficient 150, exponent −2) and 1.5 (coefficient 15, exponent −1) are different representations of the same numeric value. GDA calls such representations cohorts.
• Exact-then-round-once. Each operation computes the exact mathematical result, then rounds it once to the context precision using the context rounding mode. This rules out double rounding and makes every operation's rounding behavior statable.
• No storage format. GDA defines no concrete storage format. The in-memory encoding is an implementation choice constrained by the abstract model: implementations must preserve coefficient and exponent exactly and must not normalize silently.
• Special values in the model. GDA's model contains Infinity (positive and negative), NaN (quiet and signaling, with optional diagnostic payloads), and signed zero. Whether Kyllo programs can produce, store, compare, or serialize them is D3's decision, not D1's.

4. Adopted, Restricted, and Excluded Operations¶

GDA 1.70 defines the following operations (verified against the specification's table of contents): conversions — to-scientific-string, to-engineering-string, to-number; arithmetic — abs, add, subtract, compare, compare-signal, divide, divide-integer, exp, fused-multiply-add, ln, log10, max, max-magnitude, min, min-magnitude, minus, plus, multiply, next-minus, next-plus, next-toward, power, quantize, reduce, remainder, remainder-near, round-to-integral-exact, round-to-integral-value, square-root; miscellaneous — and, canonical, class, compare-total, compare-total-magnitude, copy, copy-abs, copy-negate, copy-sign, invert, is-canonical, is-finite, is-infinite, is-NaN, is-normal, is-qNaN, is-signed, is-sNaN, is-subnormal, is-zero, logb, or, radix, rotate, same-quantum, scaleb, shift, xor.

Adopted as semantic reference¶

The GDA definitions adopted as Kyllo's semantic reference for Decimal arithmetic: add, subtract, multiply, divide, divide-integer, remainder, remainder-near, minus, plus, compare, compare-signal, compare-total, compare-total-magnitude, quantize, round-to-integral-exact, round-to-integral-value. Adopting a definition as reference is not the same as exposing it as a language operation; it means the definition is available to later decisions and to the implementation, with its GDA semantics.

Exposed as language operations¶

Only the operations backing Kyllo's operators as already specified: add, subtract, multiply, divide (backing +, -, *, /), minus (backing unary -), and the comparison operations backing ==, !=, <, >, <=, >=. Even within this category, the mapping is not all D1's: which comparison (compare vs. compare-total) backs == is D2; whether remainder backs a Decimal % and what Integer / returns is the OQ-003 boundary question; whether quantize, round-to-integral-exact, or round-to-integral-value back explicit rounding operations is OQ-004's. D1 exposes the arithmetic; it does not finish the mapping.

Used internally¶

The runtime may use GDA operations for its own bookkeeping without exposing them to Kyllo programs (for example, compare-total for internal ordering, or to-scientific-string for diagnostics). Any such internal use must be documented in the runtime, not smuggled in as language semantics; and no internal use may leak a representation detail (such as a cohort distinction) into a program-observable result unless a later decision authorizes it.

Not adopted as language operations¶

The remaining GDA operations are not adopted as language operations in the initial language: exp, ln, log10, power, square-root, fused-multiply-add, max, max-magnitude, min, min-magnitude, next-minus, next-plus, next-toward, reduce, same-quantum, abs, canonical, class, the copy family, compare-total-magnitude, the is-* predicates, logb, radix, rotate, scaleb, shift, and the logical operations (and, or, xor, invert). Some may later exist as standard-library functions; that is a stdlib decision, not a D1 decision. Two GDA restrictions qualify operations in this group: remainder-near is restricted to values where the intermediate integer can be represented in the current precision, and the mathematical functions do not in general correspond to IEEE 754's recommended functions (the power function has some different special cases, and most may be up to one unit wrong in the last place).

The exposure or behavior of the following belongs to later decisions, not D1: compare vs. compare-total as the meaning of == (D2); remainder/remainder-near as a Decimal % (D3/OQ-003 boundary); quantize, round-to-integral-exact, round-to-integral-value as explicit rounding operations, including which rounding mode they may select (OQ-004); to-number as the basis for literal parsing and deserialization (D5/D6); to-scientific-string and to-engineering-string as the canonical string form (D7).

The two integral-rounding operations differ in signal behavior: round-to-integral-exact rounds to an integral value using the context rounding mode and sets the Inexact and Rounded flags when rounding occurs; round-to-integral-value is identical except that the Inexact and Rounded flags are never set even if the operand is rounded. D1 adopts both definitions as reference; which one, if either, backs a Kyllo explicit rounding operation is OQ-004's decision.

Explicitly excluded¶

• The GDA Basic Default Context and Extended Default Context as defaults. Kyllo defines its own context; neither GDA default is adopted.
• Any claim of IEEE 754 decimal128 conformance, of any version. GDA adoption does not confer it, and Kyllo must not claim it unless and until a separate conformance decision (with format/encoding and NaN-payload work) is made.
• Storage-format claims. GDA defines no storage format, so adopting GDA decides nothing about in-memory encoding.

Restrictions¶

• The semantic reference is restricted to the adopted list above.
• The context is restricted to the single fixed Kyllo configuration. There are no user-selectable contexts, no ambient mutable context, and no per-operation context configuration — execution contexts are fresh instances of the one fixed configuration (§6, commitment 2), unless OQ-004 later defines an explicit per-operation context, which would itself be a decision, not a drift.
• The rounding mode is restricted to round-half-even in the fixed configuration. Other GDA rounding modes exist only as parameters that OQ-004 may allow an explicit rounding operation to select.

5. Signals, Flags, and Traps¶

GDA defines eight signals (exceptional conditions), each with a flag (a boolean set when the signal occurs, sticky until cleared) and a trap-enabler (a boolean controlling whether the signal raises an exception instead of merely setting the flag):

Two facts govern how signals combine:

• Coincidence. Overflow always coincides with Inexact and Rounded. Underflow always coincides with Inexact, Rounded, and Subnormal. Clamped, Inexact, Rounded, and Subnormal can coincide with each other or with other conditions. A single operation therefore routinely produces several signals at once; the signal set is the observation, not any one signal.
• Precedence of traps. When several traps are enabled, only one exception is raised, in this order: any trap enabled for another condition takes precedence over Clamped, Inexact, Rounded, and Subnormal; any Subnormal trap takes precedence over Inexact; any Inexact trap takes precedence over Rounded; and any Rounded trap takes precedence over Clamped. The flags record all signals that occurred, even when only one exception is raised.

Underflow requires inexactness. A tiny-but-exact result signals Subnormal only, not Underflow. Whether "underflow is a failure" means the GDA Underflow signal (tiny and inexact) or any subnormal result is D3's precision work; D1 hands D3 the exact vocabulary.

Complete signal preservation. The runtime must capture the complete flag set for each operation into an immutable signal record at the operation's end or at the trap. Translating only the caught exception type loses co-occurring signals that D3 and OQ-004 need.

Trap configuration is NOT set by D1. Which signals raise, which merely set flags, and what the Kyllo-level response is are D3/OQ-004 decisions. Until they are set, no backend may choose a trap configuration on Kyllo's behalf — in particular, Python's default traps (InvalidOperation, DivisionByZero, Overflow raise; the rest flag-only) are not Kyllo's trap configuration (and are not even GDA's Basic Default Context, which also traps Clamped and Underflow), and generated code must set traps explicitly from the Kyllo runtime constant once D3/OQ-004 decide them.

6. Minimum Commitments¶

Without these, "adopt GDA" would be as vague as the current "decimal128-compatible". Each commitment is a condition of the decision: if a commitment is rejected, the acceptance must say what replaces it.

1. Name the exact specification and freeze the version. "Kyllo's Decimal arithmetic is defined by the General Decimal Arithmetic Specification, Version 1.70 (25 March 2009, Mike Cowlishaw, IBM), as the arithmetic foundation." Later versions of the GDA specification do not apply automatically; adopting a later version is a separate decision.
2. Fix the Kyllo Decimal context configuration as language constants. A single fixed configuration for all Decimal operations: precision 34; rounding round-half-even; Emin −6143; Emax 6144; no clamping (fold-down) of result exponents — only the adjusted-exponent limits apply (§2). The configuration is not a default, not mutable, not user-selectable, and not per-operation — unless OQ-004 later defines an explicit per-operation context, which would itself be a decision, not a drift. The configuration parameters are recorded as language constants in the specification (TECHSPEC-21 §3, by amendment) and as frozen data in the compiler/runtime. In Python, the configuration is realized as fresh private Context instances created per operation, with clamp=0 and capitals pinned explicitly (recommended: capitals=1, Python's default; the canonical string rendering is D7's to confirm). The immutable object is the Kyllo configuration; no Python Context object is immutable.
3. State the adopted, restricted, and excluded operation set (§4). Adopted as semantic reference: add, subtract, multiply, divide, divide-integer, remainder, remainder-near, minus, plus, compare, compare-signal, compare-total, compare-total-magnitude, quantize, round-to-integral-exact, round-to-integral-value. Exposed as language operations in the initial language: only the operations backing Kyllo's existing operators (§4). The remaining GDA operations are not adopted as language operations; some may later exist as standard-library functions (a stdlib decision, not D1). Also excluded: the GDA Basic and Extended Default Contexts as defaults, any IEEE 754 conformance claim of any version, and any storage-format claim. The exposure of compare/compare-total (D2), remainder as Decimal % (D3/OQ-003), quantize/round-to-integral-exact/round-to-integral-value as explicit rounding operations (OQ-004), to-number (D5/D6), and to-scientific-string/to-engineering-string (D7) is not decided by D1.
4. State the representation model (§3). Decimal values are (sign, coefficient, exponent) triples with variable per-value scale; cohorts are distinct representations of one value. GDA defines no storage format, so the in-memory encoding is an implementation choice constrained by the abstract model: implementations must preserve coefficient and exponent exactly and must not normalize silently. (Which comparison == uses — value or cohort — is D2 and is not decided here.)
5. State the signal mechanism, require complete signal preservation, and forbid unilateral trap choices (§5). The eight GDA signals exist as conditions with flags and trap-enablers, observable by the runtime. The runtime must capture the complete flag set for each operation into an immutable signal record at the operation's end or at the trap — translating only the caught exception type loses co-occurring signals (Overflow always with Inexact and Rounded; Underflow always with Inexact, Rounded, and Subnormal). The trap configuration (which signals raise, which merely set flags) and the Kyllo-level response to a signal are NOT set by D1; they are D3/OQ-004 decisions. Until they are set, no backend may choose a trap configuration on Kyllo's behalf.
6. State the Python-backend rules. Generated Python must perform all Decimal arithmetic through fresh private Context instances created per operation from the frozen Kyllo configuration, never through the ambient thread-local default context and never through a shared Context object; instances must not be exposed to generated programs or external Python code; each operation's complete signal set must be captured into an immutable record (§5); generated code must never construct a Decimal from a float; and Python decimal exceptions must be translated into Kyllo failures only at the translation point defined by D3, with the full signal record available to the translation. The checked-Integer emulation (TECHSPEC-21 §2, §9) is a backend requirement recorded alongside, not part of GDA adoption. These rules are requirements on OQ-011 (Python execution strategy), to be recorded when OQ-011 is taken up. D1 does not decide OQ-011.
7. State the conformance evidence. Conformance is checked against the GDA specification and its published test cases (the dectest suite). The Kyllo test suite must include GDA conformance cases for the adopted operations in the fixed context; a backend that passes them is conformant for the adopted operation set in the fixed context, for the tested cases only. Passing a selected subset of GDA test cases does not establish full GDA conformance and does not establish IEEE conformance of any version. (Availability of the dectest suite in a usable form was confirmed on 2026-11-08 during D2 preparation: the suite downloaded from speleotrove.com (791,733 bytes, 144 .decTest files, including compare.decTest and comparetotal.decTest).)

7. What D1 Does Not Decide¶

• D2 — Decimal equality. Which GDA comparison == maps to — compare (numeric value: 1.50 == 1.5) or compare-total (cohort-sensitive). Also decides Map<Decimal, …> keys and Set<Decimal> membership.
• D3 — Decimal failure outcomes, failure representation, special values. What happens on overflow, underflow, division by zero, and invalid operations — explicit failure, special value, or a per-condition mix; how a failure is represented (Result error vs. runtime fault) and which TECHSPEC-10 §6 category each arithmetic failure belongs to; whether Infinity/NaN can be produced, stored, compared, or serialized.
• D4 — Literal typing. Contextual, strict, or default-with-explicit-conversion; includes the minimum-Integer-value expressibility question and unary minus on the Integer minimum.
• D5 — Literal format. Decimal-point notation only, plus exponent notation, plus separators; fate of a Decimal literal with more than 34 significant digits. GDA's to-number is the reference definition for how a numeric string converts to the abstract representation, but the literal format is Kyllo syntax and is not decided by adopting GDA.
• D6 — Conversion mechanism. CONVERT<T> or named functions; which pairs/directions exist, which are exact vs. lossy, how lossy conversions are distinguished. Decimal→Integer rounding sits on the D6/OQ-004 boundary and must be assigned explicitly.
• D7 — Canonical external representation. Whether Decimal has a canonical string form (GDA's to-scientific-string is the natural candidate, not a decision made here), and how it encodes in JSON, binary, CSV, and database columns.
• OQ-003 — Integer division and remainder. Not resolved by D1. One boundary item must be assigned when OQ-003 starts: whether % is defined for Decimal, and the result type of Integer /. GDA defines divide-integer, remainder, and remainder-near, which OQ-003 may use as its operation definitions — but OQ-003 still has to choose the rounding behavior for integer division and the remainder sign rule for negative operands.
• OQ-004 — Decimal rounding context and inexact-result reporting. Dependent on D1, not resolved by it. OQ-004 must decide the trap configuration, when rounding applies and how inexactness is reported, the explicit rounding operations and how they select a mode, what "exactness required" means (TECHSPEC-21 §8), and Decimal→Integer conversion rounding (shared with D6). Under GDA adoption, OQ-004's job is to fill in the context's use, not to invent a context mechanism.
• OQ-011 — Runtime architecture and Python execution strategy. D1 imposes requirements on OQ-011 (§6, commitment 6) rather than deciding it. OQ-011 also owns which Python type backs Kyllo Decimal and how the Kyllo runtime module is packaged.
• OQ-017 — Deterministic execution guarantees across targets. D1 supplies the mechanism by which numeric determinism becomes achievable (a fixed GDA context); OQ-017 must still record the scope of the determinism claim and the sources of nondeterminism that numeric determinism does not cover.
• No IEEE 754 conformance claim of any version. GDA with the decimal128 parameter set is, by the GDA specification's own statement, conformant to IEEE 754-2008 decimal arithmetic (except for the three documented restrictions: remainder-near restricted; mathematical functions not in general the IEEE recommended functions; square-root specified for one rounding algorithm only). That is arithmetic compatibility, not a format conformance claim. A future interchange-format decision would need its own conformance evidence.

8. Rationale¶

1. It gives Kyllo a complete, externally specified operation semantics. GDA defines every operation Kyllo needs on the exact-then-round-once model, with an eight-signal condition vocabulary. Kyllo stops having rules that reference definitions that do not exist.
2. It is the only option directly implementable on the initial Python backend without an arithmetic emulation layer. Python's decimal module is a GDA implementation. The backend work is the runtime module (§6, commitment 6) — substantial work, but work that uses the target semantics rather than reproducing a different standard's semantics on top of it. IEEE decimal128 would require emulating a different standard's edge behavior on the very first backend Kyllo builds.
3. The context model gives OQ-004 its vocabulary. Under GDA, the rounding context is the GDA context (precision, rounding mode, exponent range, flags, traps). OQ-004 would then decide the context's contents and the reporting policy, not invent a new mechanism.
4. It keeps the IEEE door open, in a precise sense. GDA with the decimal128 parameter set is, by the GDA specification's own statement, conformant to IEEE 754-2008 decimal arithmetic (except for the three documented restrictions). If Kyllo later needs interchange-format conformance (encodings, NaN payloads), that is a separate decision with its own conformance evidence — not a change of foundation, and not implied by D1.
5. It avoids the two failure modes of the alternatives. Against the Kyllo-defined model: no need to write and maintain a complete arithmetic specification in-house, and an external oracle exists for conformance testing. Against deferral: the conformance target stops being open, so D2–D7, OQ-003, and OQ-004 can proceed against a shared reference instead of re-litigating the same questions.
6. It fits the verification-first philosophy, honestly stated. An external specification plus published test cases gives conformance claims something to be tested against. That is evidence, not proof — and this record does not claim more. What GDA adoption does not do is prove Kyllo's arithmetic correct; it makes the arithmetic checkable, which is what verification-first requires at this stage.

9. Consequences¶

The following documentation MUST be updated to reflect this decision:

• TECHSPEC-21: Numeric Types, Precision, and Arithmetic Semantics (§3, the Decimal definition; §9, the compiler/runtime responsibilities)
• TECHSPEC-57: Open Questions register (D1 recorded as decided; OQ-002 remains Open)
• TECHSPEC-49: Determinism and Reproducible Execution (§2, numeric behavior now defined by the fixed GDA context; determinism scope remains OQ-017's)
• TECHSPEC-43: Compile-Time Evaluation (§3 and §7, arithmetic semantics now defined for the adopted operations)
• Language Guide: Types
• Glossary and Cross-Reference Index
• Unresolved Questions register (D1 recorded as decided; OQ-002 remains Open)
• Decision Records index
• CHANGELOG.md

What becomes true on acceptance:

• Decimal arithmetic gets a complete, externally specified definition. "Defined decimal exponent range" stops being an assertion without a definition — the range is the adjusted-exponent range −6143 to 6144, with subnormals to Etiny −6176. "Inexact results must be detectable" gains a mechanism (the Inexact/Rounded flags, with complete signal preservation). OQ-004 gains its vocabulary (the context). The Python backend gets a direct implementation vehicle (Python's decimal module) plus a defined runtime module to build.
• No program's meaning changes, because no program's Decimal edge behavior was defined before — D1 defines it for the first time. Integer is untouched (signed 64-bit, checked).
• D2–D7, OQ-003, and OQ-004 can now proceed against a shared reference instead of an open question.

What becomes work on acceptance:

• The Kyllo decimal runtime module for the Python backend (fresh-context-per-operation isolation, complete signal capture, exception translation point, checked-Integer emulation) — moderate implementation complexity, not low.
• GDA conformance tests for the adopted operations and the tested scope only.
• D2–D7, OQ-003, and OQ-004, in their own decision processes.

What could go wrong:

• If the minimum commitments (§6) are dropped, "adopt GDA" degrades into a slogan and the backend's defaults (Python's default context and traps) silently become Kyllo's semantics — the exact failure PYTHON.md §2 forbids.
• If a later decision (especially D3 on special values, or OQ-004 on the rounding context) contradicts the GDA model, D1 will need revisiting; the version freeze and the explicit exclusions in §4 exist to make such a conflict visible rather than silent.

Consequences of rejecting (recorded for the record; Blake accepted as written): the conformance target stays open, and every subsequent numeric decision (D2–D7, OQ-003, OQ-004) continues without a shared reference. The realistic alternatives are full IEEE 754 decimal128 conformance, a Kyllo-defined arithmetic, or explicit deferral.

10. Acceptance Criteria¶

D1 may be marked ACCEPTED when:

1. This decision record exists and states the decision, the fixed context (§2), the operation set (§4), the signal mechanism (§5), the minimum commitments (§6), and what D1 does not decide (§7).
2. TECHSPEC-21 §3 is amended with the GDA foundation and the fixed context configuration, and TECHSPEC-21 §9 records the Python-backend rules as requirements on OQ-011.
3. The Unresolved Questions register records D1 as decided while OQ-002 remains Open until D2–D7 are resolved.
4. Affected Language Guide pages (Types) teach the accepted foundation without resolving D2–D7, OQ-003, or OQ-004.
5. The glossary and cross-reference index gained entries for the new terminology.
6. No D2–D7, OQ-003, or OQ-004 semantics are introduced by the integration.
7. No normative source file (source-original/) is modified.
8. No IEEE 754 conformance claim of any version appears in the integration.
9. The Python-backend rules are recorded as requirements on OQ-011, not as a decided runtime architecture.
10. The CHANGELOG records the acceptance as documentation-level, not compiler implementation.

11. Implementation Notes¶

This decision establishes the intended Decimal semantics. 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, not low: delegating arithmetic to Python's decimal removes the arithmetic emulation layer, but the runtime module — fresh-context isolation, complete signal capture, exception translation, checked-Integer emulation, float-contamination protection, conformance tests, integration — is substantial work. Fresh-context-per-operation performance overhead is unmeasured; no performance claim is made. Availability of the GDA dectest suite in a usable form was confirmed on 2026-11-08 during D2 preparation (downloaded from speleotrove.com; 144 .decTest files).

Evidence: OQ-002 investigation report (reports/oq-002-numeric-representation-investigation.md); OQ-002 D1 report (reports/oq-002-d1-gda-conformance-foundation.md, §9 decision statement, §6 minimum commitments, §2.8 operation list, §2.7 and §3.7 signal preservation); General Decimal Arithmetic Specification Version 1.70 (25 March 2009, Cowlishaw); Python 3.12 decimal documentation and empirical checks (D1 report Appendix B).

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

12. Acceptance¶

Accepted on 2026-11-08, as written — Blake tapped "Accept D1 as written" on the decision brief in the main chat. No refinement rounds: the §9 decision statement and the §6 minimum commitments were accepted verbatim. The acceptance criteria in §10 were verified during documentation integration:

1. The decision record exists and states the decision (§1), the fixed context (§2), the operation set (§4), the signal mechanism (§5), the minimum commitments (§6), and what D1 does not decide (§7).
2. TECHSPEC-21 §3 is amended with the GDA foundation and the fixed context configuration, and TECHSPEC-21 §9 records the Python-backend rules as requirements on OQ-011 — TECHSPEC-21 amendment.
3. The Unresolved Questions register records D1 as decided while OQ-002 remains Open — TECHSPEC-57 amendment; the register still counts 28 open questions.
4. The Language Guide Types page teaches the accepted foundation without resolving D2–D7, OQ-003, or OQ-004 — types amendment.
5. The glossary and cross-reference index gained entries for GDA, the fixed Kyllo context, Decimal signals, and cohorts.
6. No D2–D7, OQ-003, or OQ-004 semantics are introduced by the integration — cross-document consistency audit completed 2026-11-08 (read-only audit of the record and all five amendments against the D1 report: no factual errors, no scope leaks, no IEEE conformance claim, no implementation claims).
7. No normative source file (source-original/) is modified — verified by git status: only the two OQ-002 reports (new), the decision record (new), amendments (new), builder, CHANGELOG, and generated docs/ pages changed.
8. No IEEE 754 conformance claim of any version appears in the integration — the record (§§1, 4, 7) and the TECHSPEC-21 amendment state explicitly that GDA adoption confers no IEEE conformance claim; the only IEEE statement is the GDA specification's own 754-2008 decimal-arithmetic compatibility statement, quoted as such (with the three documented restrictions).
9. The Python-backend rules are recorded as requirements on OQ-011, not as a decided runtime architecture — TECHSPEC-21 amendment (§9) and record §6, commitment 6.
10. The CHANGELOG (0.2.9) records the acceptance as documentation-level, not compiler implementation.

Interpretations recorded at acceptance¶

• "decimal128-compatible" is now a precise statement. TECHSPEC-21 §3 used the phrase without naming a standard. D1 defines it: GDA 1.70 with the decimal128 parameter set. The 34-digit and ties-to-even bullets are confirmed, not replaced.
• The exponent limits are adjusted-exponent limits. A stored exponent may lie outside [Emin, Emax] while the number is normal; only the adjusted exponent is bounded. Any future statement of the range that omits "adjusted" is incorrect.
• No program's meaning changes. No program's Decimal edge behavior was defined before D1; D1 defines it for the first time. Integer is untouched.
• The display-similarity sentence is not an equality rule. (Recorded here because D2 preparation raised it: TECHSPEC-21 §6's "must not treat two different numeric representations as equal merely because they appear similar when displayed" forbids display-based equality; it does not decide whether 1.50 == 1.5. That is D2's question.)

Evidence note¶

During D2 preparation (2026-11-08), the GDA dectest suite was confirmed available in usable form (downloaded from speleotrove.com; 144 .decTest files), removing the uncertainty recorded in §6, commitment 7 and §11. Conformance evidence under commitment 7 can therefore draw on the dectest suite for the adopted scope.

Remaining open (not resolved by D1)¶

• D2 (equality), D3 (failure outcomes, failure representation, special values), 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 D2–D7 are resolved.
• Fresh-context-per-operation performance overhead is unmeasured; no performance claim is made.

Scope of acceptance¶

Acceptance is documentation-level: it makes D1 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, TECHSPEC-57 (register note), TECHSPEC-49, TECHSPEC-43, Language Guide (Types), Glossary, Cross-Reference Index, Unresolved Questions register, Decision Records index, CHANGELOG.md (0.2.9).