eyeling 1.24.7 → 1.24.9

package/examples/output/barley-seed-becoming.txt

@@ -1,25 +0,0 @@
-Barley seed lineage — becoming
-
-Answer
-YES for the viable barley lineage.
-NO for the contrast lineages when digital heredity, repair, protected dormancy, or heritable variation are missing.
-
-Reason Why
-The main lineage can be read as a becoming: a protected dormant seed can germinate, an adult plant can become a next seed stage, and the lineage can therefore become a self-renewing cycle. Because its hereditary information is digitally instantiated and repair is available, it can also become an accurately reproduced next generation under no-design laws. And because heritable variation is present under a matching selection environment, it can become an adaptively persistent lineage. The contrast lineages mark blocked becomings: non-digital heredity blocks accurate copying, lack of repair blocks reliable renewal, lack of dormancy protection blocks closure through the seed phase, and lack of heritable variation blocks adaptive becoming.
-
-Check
-B1  OK - no-design laws are assumed
-B2  OK - the viable genome can become accurately copied
-B3  OK - the viable seed can become a protected dormant phase
-B4  OK - the viable seed can become a germinating stage
-B5  OK - the viable adult can become a next dormant seed stage
-B6  OK - the viable lineage can become an accurately reproduced next generation
-B7  OK - the viable lineage can become a closed life cycle
-B8  OK - the viable lineage can become a novel variant lineage
-B9  OK - the viable lineage can become adaptively persistent
-B10 OK - the viable lineage is an evolvable becoming
-B11 OK - the non-digital lineage cannot become an accurately reproduced next generation
-B12 OK - the repair-deficient lineage cannot become an accurately reproduced next generation
-B13 OK - the coatless lineage cannot become a closed life cycle
-B14 OK - the static lineage cannot become an adaptive lineage
-B15 OK - the static lineage cannot become an evolvable becoming

package/examples/output/bmi.txt

@@ -1,20 +0,0 @@
-BMI — ARC-style Body Mass Index example
-
-Answer
-BMI = 22.72
-Category = Normal
-At height 178 cm, a healthy-weight range is about 58.6–78.9 kg (BMI 18.5–24.9).
-
-Reason Why
-BMI is defined as weight in kilograms divided by height in meters squared. This program first normalizes the input to SI units, computes BMI, and then applies WHO adult categories as half-open intervals. The healthy-weight band is the weight range at the same height that corresponds to BMI 18.5 through 24.9.
-
-Check
-C1 OK - the input was normalized into positive SI values.
-C2 OK - height squared was reconstructed from the normalized height.
-C3 OK - the BMI value matches the BMI = kg / m² formula.
-C4 OK - a BMI of 18.49 stays below the normal-weight threshold.
-C5 OK - the lower boundary is half-open: BMI 18.5 is classified as Normal.
-C6 OK - BMI 25.0 starts the Overweight category.
-C7 OK - BMI 30.0 starts the Obesity I category.
-C8 OK - classification behavior is monotonic across representative BMI values.
-C9 OK - the healthy-weight band was reconstructed from BMI 18.5 to 24.9 at the same height.

package/examples/output/calidor.txt

@@ -1,29 +0,0 @@
-=== Answer ===
-The city is allowed to use a narrow heatwave-response insight and recommends Calidor Priority Cooling Bundle for this household.
-case                 : calidor
-decision             : Allowed
-municipality         : Calidor
-recommended package  : Calidor Priority Cooling Bundle
-
-=== Reason Why ===
-The gateway desensitizes local heat, vulnerability, and prepaid-energy stress into an expiring municipal support insight, and the city consumes that envelope only for heatwave response.
-metric               : active_need_count
-threshold            : 3.0
-scope                : household-gateway @ heat-alert-window
-required capabilities: bill_credit, cooling_kit, transport, welfare_check
-signature alg        : HMAC-SHA256
-expires at           : 2026-07-18T21:00:00+00:00
-reason.txt           : The gateway keeps raw indoor heat, vulnerability, and prepaid-energy data local, derives a priority-support signal, and shares only a scoped heatwave-response envelope with expiry.
-dispatches logged    : 1
-
-=== Check ===
-signature verifies              : yes
-payload hash matches            : yes
-minimization strips sensitive terms: yes
-scope complete                  : yes
-authorization allowed           : yes
-heat-alert active               : yes
-unsafe indoor heat              : yes
-recommended package eligible    : yes
-duty timing consistent          : yes
-tenant screening prohibited     : yes

package/examples/output/context-association.n3

@@ -1,9 +0,0 @@
-@prefix : <http://example.org/#> .
-
-:association :subject :Bob .
-:association :dataGraph _:src2_g0 .
-:association :signatureGraph _:src2_g1 .
-:association :metadataGraph _:src2_g3 .
-:association :cryptosuite "ecdsa-rdfc-2019" .
-:association :issuer <https://university.example/issuers/14> .
-:association :status :contextAssociationVerified .

package/examples/output/deep-taxonomy-10.txt

@@ -1,15 +0,0 @@
-Deep Taxonomy - deep classification benchmark
-
-Answer
-The test succeeds: starting from one individual classified as N0, the rules eventually classify it as N10 and then as A2.
-
-Reason Why
-Each rule moves the same individual one level deeper in the taxonomy and also adds two side labels. Because that chain continues all the way from N0 to N10, the final rule deriving A2 fires, and that in turn makes the test true.
-
-Check
-C1 OK - the starting classification N0 is present.
-C2 OK - the first expansion produced N1 together with side labels I1 and J1.
-C3 OK - the chain reaches the midpoint N5 and still carries both side-label branches.
-C4 OK - the final taxonomy step from N9 to N10 was completed.
-C5 OK - once N10 is reached, the terminal class A2 is derived.
-C6 OK - the success flag is raised only after the terminal class A2 is present.

package/examples/output/deep-taxonomy-100.txt

@@ -1,15 +0,0 @@
-Deep Taxonomy - deep classification benchmark
-
-Answer
-The test succeeds: starting from one individual classified as N0, the rules eventually classify it as N100 and then as A2.
-
-Reason Why
-Each rule moves the same individual one level deeper in the taxonomy and also adds two side labels. Because that chain continues all the way from N0 to N100, the final rule deriving A2 fires, and that in turn makes the test true.
-
-Check
-C1 OK - the starting classification N0 is present.
-C2 OK - the first expansion produced N1 together with side labels I1 and J1.
-C3 OK - the chain reaches the midpoint N50 and still carries both side-label branches.
-C4 OK - the final taxonomy step from N99 to N100 was completed.
-C5 OK - once N100 is reached, the terminal class A2 is derived.
-C6 OK - the success flag is raised only after the terminal class A2 is present.

package/examples/output/delfour.txt

@@ -1,30 +0,0 @@
-=== Answer ===
-The scanner is allowed to use a neutral shopping insight and recommends Low-Sugar Tea Biscuits instead of Classic Tea Biscuits.
-case                 : delfour
-decision             : Allowed
-scanned product      : Classic Tea Biscuits
-suggested alternative: Low-Sugar Tea Biscuits
-
-=== Reason Why ===
-The phone desensitizes a diabetes-related household condition into a scoped low-sugar need, wraps it in an expiring Insight + Policy envelope, signs it, and the scanner consumes that envelope for shopping assistance.
-metric               : sugar_g_per_serving
-threshold            : 10.0
-scope                : self-scanner @ pick_up_scanner
-retailer             : Delfour
-signature alg        : HMAC-SHA256
-banner headline      : Track sugar per serving while you scan
-expires at           : 2025-10-05T22:33:48.907185+00:00
-reason.txt           : Household requires low-sugar guidance (diabetes in POD). A neutral Insight is scoped to device 'self-scanner', event 'pick_up_scanner', retailer 'Delfour', and expires soon; the policy confines use to shopping assistance.
-audit entries        : 1
-bus files written    : 6
-
-=== Check ===
-signature verifies              : yes
-payload hash matches            : yes
-minimization strips sensitive terms: yes
-scope complete                  : yes
-authorization allowed           : yes
-high-sugar banner               : yes
-alternative lowers sugar        : yes
-duty timing consistent          : yes
-marketing prohibited            : yes

package/examples/output/digital-product-passport.txt

@@ -1 +0,0 @@
-ACME X1000 SN123 | recycled=13% | lifecycle=52500 gCO2e | CRM=true | hint=http://example.org/dpp#repairFriendly

package/examples/output/dijkstra-risk-path.n3

@@ -1,3 +0,0 @@
-@prefix : <https://eyereasoner.github.io/eyeling/examples/dijkstra-risk-path#> .
-
-:dijkstraRiskPath :selects :pathB .

package/examples/output/eco-route-insight.n3

@@ -1,3 +0,0 @@
-@prefix : <https://eyereasoner.github.io/eyeling/examples/eco-route-insight#> .
-
-:ecoRouteInsight :issues :Insight .

package/examples/output/flandor.txt

@@ -1,31 +0,0 @@
-=== Answer ===
-Name: Flandor
-Region: Flanders
-Metric: regional_retooling_priority
-Active need count: 3/3
-Recommended package: Flandor Retooling Pulse
-Budget cap: €140M
-Package cost: €120M
-Payload SHA-256: 718f5b17d07ab6a95503bc04a1000ddb132409f600659c03d21def81914b780b
-Envelope HMAC-SHA-256: 955968ca99a191783bc00cba068128ccb9ff40a5e6114fda13a52c74ee27329e
-
-=== Reason Why ===
-Export weakness is active because at least one cluster has exportOrdersIndex < 90 (Antwerp chemicals=84, Ghent manufacturing=87).
-Skills strain is active because technical vacancy rate is 4.6% (threshold > 3.9%).
-Grid stress is active because congestion hours = 19 (threshold > 11).
-The recommendation policy is "lowest_cost_package_covering_all_active_needs", so the cheapest package that covers all active needs within budget is selected.
-Selected package "Flandor Retooling Pulse" covers export=true, skills=true, grid=true, cost=€120M.
-Usage is permitted only for purpose "regional_stabilization" and the envelope expires at 2026-04-08T19:00:00+00:00.
-
-=== Check ===
-- PASS: payload hash matches
-- PASS: hmac matches
-- PASS: threshold reached
-- PASS: scope complete
-- PASS: minimization respected
-- PASS: authorized purpose allowed
-- PASS: deletion duty still on time
-- PASS: surveillance reuse prohibited
-- PASS: package exists within budget
-- PASS: package covers all active needs
-- PASS: lowest-cost eligible package chosen

package/examples/output/genetic-algorithm-knapsack.txt

@@ -1 +0,0 @@
-Knapsack GA best genome 101000000101 (feasible=true): weight=50 value=101 after 4 generations.

package/examples/output/genetic-algorithm.txt

@@ -1 +0,0 @@
-GA evolved 11111101010 -> 2026 in 8 generations.

package/examples/output/genetic-knapsack-selection.n3

@@ -1,3 +0,0 @@
-@prefix : <https://eyereasoner.github.io/eyeling/examples/genetic-knapsack-selection#> .
-
-:geneticKnapsackSelection :selects :FinalLocal .

package/examples/output/harborsmr.txt

@@ -1,20 +0,0 @@
-HarborSMR — bounded flexible-export insight for port electrolysis
-
-Answer
-PERMIT
-The port hydrogen hub may use the SMR insight to run PEM electrolyzer train 2 at 16 MW from 14:00 to 18:00.
-
-Reason Why
-The operator shares only a narrow, expiring insight that a temporary 18 MW flexible-export window is available. The request is for electrolysis dispatch only, the requested 16 MW fits inside the permitted window, safety margins are above threshold, no outage blocks the window, and the policy forbids redistribution for market resale. Raw reactor telemetry stays local.
-
-Check
-C1  OK - reserve margin exceeds the dispatch threshold
-C2  OK - cooling margin exceeds the dispatch threshold
-C3  OK - no planned outage blocks the window
-C4  OK - requested MW fits within the export window
-C5  OK - serialized insight omits sensitive telemetry terms
-C6  OK - aggregate excludes core temperature, rod position, neutron flux, and operator IDs
-C7  OK - policy allows use for electrolysis dispatch before expiry
-C8  OK - policy prohibits redistribution for market resale
-C9  OK - scope is explicit: device, event, start, and expiry
-C10 OK - dispatch plan matches the requested load and power

package/examples/output/interop-demo.txt

@@ -1 +0,0 @@
-ACTION: apply GoldDiscount and send invoice reminder (opt-in confirmed).

package/examples/output/matrix-mechanics.txt

@@ -1,14 +0,0 @@
-=== Answer ===
-In this toy matrix-mechanics model, the Hamiltonian has two discrete energy levels and does not commute with a second observable.
-
-=== Reason Why ===
-H = [[1,0],[0,2]]
-X = [[0,1],[1,0]]
-HX = [[0,1],[2,0]]
-XH = [[0,2],[1,0]]
-[H,X] = [[0,-1],[1,0]]
-
-=== Check ===
-trace/determinant match energy levels: yes
-X^2 = I : yes
-[H,X] != 0 : yes

package/examples/output/medior.txt

@@ -1,32 +0,0 @@
-=== Answer ===
-Name: Medior
-Region: Flanders
-Metric: post_discharge_coordination_priority
-Active need count: 4/3
-Recommended package: Medior Continuity Pulse
-Budget cap: €5
-Package cost: €4
-Payload SHA-256: b5fec8971d6c5e313a1387f08151f1c3203effce05d6455469c9f63305be05ae
-Envelope HMAC-SHA-256: 072f4c2774ce362e660649d145c9d784e5e95d63d24d4057b119a419c6ba34dc
-
-=== Reason Why ===
-RenalSafetyConcern holds because eGFR = 52 and the threshold is < 60.
-PolypharmacyRisk holds because the active medication count is 9 and the threshold is ≥ 8.
-ReadmissionHistory holds because admissionsLast180Days = 2 and the threshold is ≥ 1.
-RecentDischargeWindow holds because hoursSinceDischarge = 18 and the threshold is ≤ 48.
-The recommendation rule selects the least-cost package that covers every active need and remains within budget.
-The selected package is "Medior Continuity Pulse" with cost €4, touches=3.
-Use is permitted only for purpose "care_coordination" and expires at 2026-04-11T08:00:00+00:00.
-
-=== Check ===
-- PASS: payloadHashMatches
-- PASS: signatureVerifies
-- PASS: thresholdReached
-- PASS: scopeComplete
-- PASS: minimizationRespected
-- PASS: authorizationAllowed
-- PASS: dutyTimely
-- PASS: insurancePricingProhibited
-- PASS: packageWithinBudget
-- PASS: packageCoversAllActiveNeeds
-- PASS: lowestCostEligiblePackageChosen

package/examples/output/n3-speaks-for-itself.txt

@@ -1,52 +0,0 @@
-@prefix : <https://example.org/n3-speaks#> .
-@prefix foaf: <http://xmlns.com/foaf/0.1/> .
-@prefix id: <https://example.org/id/> .
-
-:report :aliceReaches id:bob .
-:report :aliceReaches id:carol .
-:report :aliceReaches id:dave .
-:report :believes {
-    id:alice foaf:knows id:bob .
-} .
-:report :believes {
-    id:alice foaf:name "Alice" .
-} .
-:report :believes {
-    id:bob foaf:knows id:carol .
-} .
-:report :believes {
-    id:bob foaf:name "Bob" .
-} .
-:report :believes {
-    id:carol foaf:knows id:dave .
-} .
-:report :believes {
-    id:carol foaf:name "Carol" .
-} .
-:report :believes {
-    id:dave foaf:name "Dave" .
-} .
-:report :trusts <https://alice.example/profile.n3> .
-:report :trusts <https://bob.example/profile.n3> .
-:report :trusts <https://carol.example/profile.n3> .
-{
-    id:alice foaf:knows id:bob .
-} :believedFromDoc <https://alice.example/profile.n3> .
-{
-    id:alice foaf:name "Alice" .
-} :believedFromDoc <https://alice.example/profile.n3> .
-{
-    id:bob foaf:knows id:carol .
-} :believedFromDoc <https://bob.example/profile.n3> .
-{
-    id:bob foaf:name "Bob" .
-} :believedFromDoc <https://bob.example/profile.n3> .
-{
-    id:carol foaf:knows id:dave .
-} :believedFromDoc <https://carol.example/profile.n3> .
-{
-    id:carol foaf:name "Carol" .
-} :believedFromDoc <https://carol.example/profile.n3> .
-{
-    id:dave foaf:name "Dave" .
-} :believedFromDoc <https://carol.example/profile.n3> .

package/examples/output/parcellocker.txt

@@ -1,20 +0,0 @@
-ParcelLocker — One-time parcel pickup by a friend
-
-Answer
-PERMIT
-Noah may collect Maya's parcel from locker B17.
-
-Reason Why
-Maya created a one-time authorization for Noah only, for this parcel only, at this locker only, and for pickup only. The token is active, the parcel is ready, and the same authorization does not reveal billing details or allow redirection.
-
-Check
-C1  OK - requester matches the named delegate
-C2  OK - requested parcel matches the authorized parcel
-C3  OK - requested locker matches the authorized locker
-C4  OK - requested action is parcel collection
-C5  OK - requested purpose is pickup only
-C6  OK - authorization is active
-C7  OK - authorization is single-use
-C8  OK - parcel is ready for pickup
-C9  OK - billing details stay hidden
-C10 OK - parcel redirection is not allowed

package/examples/output/pn-junction-tunneling.txt

@@ -1,23 +0,0 @@
-=== Answer ===
-In this toy PN-junction tunneling model, heavy doping narrows the depletion region enough for a tunneling window that rises to a peak and then falls, producing a negative-differential region.
-case                          : pn-junction-tunneling
-peak bias                     : 2
-peak current proxy            : 4
-negative differential region  : yes
-
-=== Reason Why ===
-We model tunneling current as an exact overlap count between filled N-side states and empty P-side states while forward bias shifts the bands. Heavy doping is represented by a much narrower depletion region.
-ordinary depletion width (nm) : 8
-tunnel depletion width (nm)   : 1
-filled N-side states          : [1, 2, 3, 4]
-empty P-side states at 0 bias : [3, 4, 5, 6]
-bias -> overlap current proxy : 0->2, 1->3, 2->4, 3->3, 4->2, 5->1, 6->0
-peak point                    : 2 -> 4
-high-bias point               : 6 -> 0
-
-=== Check ===
-heavily doped barrier is narrower : yes
-peak occurs before overlap closes : yes
-negative differential region present : yes
-high-bias overlap closes           : yes
-peak equals full four-state overlap: yes

package/examples/output/queens.txt

@@ -1,21 +0,0 @@
-Solving 14-Queens...
-Printing at most 1 solution(s).
-
-Solution 1:
-Q . . . . . . . . . . . . .
-. . Q . . . . . . . . . . .
-. . . . Q . . . . . . . . .
-. . . . . . Q . . . . . . .
-. . . . . . . . . . . Q . .
-. . . . . . . . . Q . . . .
-. . . . . . . . . . . . Q .
-. . . Q . . . . . . . . . .
-. . . . . . . . . . . . . Q
-. . . . . . . . Q . . . . .
-. Q . . . . . . . . . . . .
-. . . . . Q . . . . . . . .
-. . . . . . . Q . . . . . .
-. . . . . . . . . . Q . . .
-As column positions by row: [1, 3, 5, 7, 12, 10, 13, 4, 14, 9, 2, 6, 8, 11]
-
-Total solutions for 14-Queens: 365596

package/examples/output/rc-discharge-envelope.n3

@@ -1,9 +0,0 @@
-=== Answer ===
-exact decay symbol : exp(-1/4)
-certified decay interval : [0.7788007830, 0.7788007831]
-first below tolerance step : 13
-first below tolerance time : 0.325 s
-upper voltage at step 13 : 0.930581 V
-
-=== Explanation ===
-The physical decay factor is exp(-1/4), but the example uses a finite double interval as the certificate. Because the interval lies strictly between 0 and 1, the capacitor voltage envelope contracts each sample. The upper envelope is the safety-relevant bound: once it falls below 1.0 V, every compatible exact trajectory is below tolerance.

package/examples/output/rc-discharge-envelope.txt

@@ -1,9 +0,0 @@
-=== Answer ===
-exact decay symbol : exp(-1/4)
-certified decay interval : [0.7788007830, 0.7788007831]
-first below tolerance step : 13
-first below tolerance time : 0.325 s
-upper voltage at step 13 : 0.930581 V
-
-=== Explanation ===
-The physical decay factor is exp(-1/4), but the example uses a finite double interval as the certificate. Because the interval lies strictly between 0 and 1, the capacitor voltage envelope contracts each sample. The upper envelope is the safety-relevant bound: once it falls below 1.0 V, every compatible exact trajectory is below tolerance.

package/examples/output/rdf-dataset.n3

@@ -1,5 +0,0 @@
-VERSION "1.2"
-
-@prefix : <https://eyereasoner.github.io/eyeling/examples/rdf-dataset#> .
-
-:workOrder :entails <<( :sensor :needs :inspection )>> .

package/examples/output/rdf-message-flow.n3

@@ -1,7 +0,0 @@
-@prefix : <https://eyereasoner.github.io/eyeling/examples/rdf-message-flow#> .
-
-:rdfMessageFlowExample :demonstrates :ContinuousFlow .
-:rdfMessageFlowExample :demonstrates :BackPressureRelease .
-:rdfMessageFlowExample :demonstrates :AtomicMessageContext .
-:rdfMessageFlowExample :demonstrates :HeartbeatInFlow .
-:rdfMessageFlowExample :demonstrates :ThresholdRouting .

package/examples/output/rdf-messages.n3

@@ -1,7 +0,0 @@
-@prefix : <https://eyereasoner.github.io/eyeling/examples/rdf-messages#> .
-
-:rdfMessagesExample :demonstrates :ExplicitBoundaries .
-:rdfMessagesExample :demonstrates :AtomicMessageContext .
-:rdfMessagesExample :demonstrates :EmptyHeartbeat .
-:rdfMessagesExample :demonstrates :MessageScopedBlankNodes .
-:rdfMessagesExample :demonstrates :ReplayableMessageLog .

package/examples/output/school-placement-audit.n3

@@ -1,3 +0,0 @@
-@prefix : <https://eyereasoner.github.io/eyeling/examples/school-placement-audit#> .
-
-:schoolPlacementAudit :reports :Audit .

package/examples/output/smoke-arithmetic.n3

@@ -1,5 +0,0 @@
-=== Answer ===
-product = 42
-
-=== Explanation ===
-The compiled rule multiplies :x and :y using math:product.

package/examples/output/smoke-arithmetic.txt

@@ -1,5 +0,0 @@
-=== Answer ===
-product = 42
-
-=== Explanation ===
-The compiled rule multiplies :x and :y using math:product.

package/examples/output/sqrt2-cauchy.txt

@@ -1,13 +0,0 @@
-Approximation (at limit): sqrt2 ≈ 1.414213562373095
-n=0  x=1.0  delta=seed  err=1
-n=1  x=1.5  delta=0.5  err=0.25
-n=2  x=1.4166666666666665  delta=0.08333333333333348  err=0.006944444444444198
-n=3  x=1.4142156862745097  delta=0.002450980392156854  err=0.000006007304882427178
-n=4  x=1.4142135623746899  delta=0.0000021238998197947723  err=4.510614104447086e-12
-n=5  x=1.414213562373095  delta=1.5949463971764999e-12  err=4.440892098500626e-16
-n=6  x=1.414213562373095  delta=0  err=4.440892098500626e-16
-n=7  x=1.414213562373095  delta=0  err=4.440892098500626e-16
-n=8  x=1.414213562373095  delta=0  err=4.440892098500626e-16
-n=9  x=1.414213562373095  delta=0  err=4.440892098500626e-16
-n=10  x=1.414213562373095  delta=0  err=4.440892098500626e-16
-Tail check: for i,j in (4..10), all |x_i - x_j| < 0.0001 (finite check)

package/examples/output/sqrt2-dedekind.txt

@@ -1,31 +0,0 @@
-q=-2  q^2=4  => LEFT (q<0 OR q^2<2)
-q=-1  q^2=1  => LEFT (q<0 OR q^2<2)
-q=-0.5  q^2=0.25  => LEFT (q<0 OR q^2<2)
-q=-0.1  q^2=0.010000000000000002  => LEFT (q<0 OR q^2<2)
-q=0  q^2=0  => LEFT (q<0 OR q^2<2)
-q=0.5  q^2=0.25  => LEFT (q<0 OR q^2<2)
-q=1  q^2=1  => LEFT (q<0 OR q^2<2)
-q=1.3  q^2=1.6900000000000002  => LEFT (q<0 OR q^2<2)
-q=1.4  q^2=1.9599999999999997  => LEFT (q<0 OR q^2<2)
-q=1.41  q^2=1.9880999999999998  => LEFT (q<0 OR q^2<2)
-q=1.414  q^2=1.9993959999999997  => LEFT (q<0 OR q^2<2)
-q=1.4142  q^2=1.9999616399999998  => LEFT (q<0 OR q^2<2)
-q=1.4143  q^2=2.0002444899999996  => RIGHT (q>=0 AND q^2>=2)
-q=1.42  q^2=2.0164  => RIGHT (q>=0 AND q^2>=2)
-q=1.5  q^2=2.25  => RIGHT (q>=0 AND q^2>=2)
-q=2  q^2=4  => RIGHT (q>=0 AND q^2>=2)
-successor: from -2 to -1   (s^2=1)
-successor: from -1 to -0.5   (s^2=0.25)
-successor: from -0.5 to -0.25   (s^2=0.0625)
-successor: from -0.1 to -0.05   (s^2=0.0025000000000000005)
-successor: from 0 to 1   (s^2=1)
-successor: from 0.5 to 1.2   (s^2=1.44)
-successor: from 1 to 1.3333333333333333   (s^2=1.7777777777777777)
-successor: from 1.3 to 1.393939393939394   (s^2=1.9430670339761251)
-successor: from 1.4 to 1.411764705882353   (s^2=1.9930795847750868)
-successor: from 1.41 to 1.4134897360703813   (s^2=1.9979532339763162)
-successor: from 1.414 to 1.4141769185705917   (s^2=1.9998963570178139)
-successor: from 1.4142 to 1.4142112354285044   (s^2=1.9999934184122166)
-Check: cut is proper on the sample (has LEFT and RIGHT witnesses)
-Check: downward-closed on the sample (finite for-all test)
-Check: no maximal element witnessed for all LEFT seed members (constructive successors)

package/examples/output/sudoku.txt

@@ -1,43 +0,0 @@
-=== Answer ===
-The puzzle is solved, and the completed grid is the unique valid Sudoku solution.
-case              : sudoku
-default puzzle    : classic
-
-Puzzle
-1 . . | . . 7 | . 9 . 
-. 3 . | . 2 . | . . 8 
-. . 9 | 6 . . | 5 . . 
-
-. . 5 | 3 . . | 9 . . 
-. 1 . | . 8 . | . . 2 
-6 . . | . . 4 | . . . 
-
-3 . . | . . . | . 1 . 
-. 4 . | . . . | . . 7 
-. . 7 | . . . | 3 . . 
-
-Completed grid
-1 6 2 | 8 5 7 | 4 9 3 
-5 3 4 | 1 2 9 | 6 7 8 
-7 8 9 | 6 4 3 | 5 2 1 
-
-4 7 5 | 3 1 2 | 9 8 6 
-9 1 3 | 5 8 6 | 7 4 2 
-6 2 8 | 7 9 4 | 1 3 5 
-
-3 5 6 | 4 7 8 | 2 1 9 
-2 4 1 | 9 3 5 | 8 6 7 
-8 9 7 | 2 6 1 | 3 5 4 
-
-=== Reason Why ===
-The solver starts from 23 clues and fills the remaining 58 cells by combining constraint propagation with depth-first search. At each step it chooses the empty cell with the fewest legal digits, places forced singles immediately, and only guesses when more than one candidate remains. Across the search it made 213 forced placements and tried 22 guesses, visited 23 search nodes overall, and backtracked 12 times before reaching the completed grid. The solver also confirmed that the solution is unique. Early steps: r2c3=4: guess, r5c3=3: forced, r2c1=5: guess, r2c4=1: guess, r2c6=9: forced, r2c7=6: guess, r2c8=7: forced, r1c7=4: guess, … and 50 more placements
-
-=== Check ===
-C1 OK - every given clue is preserved in the final grid.
-C2 OK - the final grid contains only digits 1 through 9, with no blanks left.
-C3 OK - each row contains every digit exactly once.
-C4 OK - each column contains every digit exactly once.
-C5 OK - each 3×3 box contains every digit exactly once.
-C6 OK - replaying the recorded placements from the original puzzle remains legal at every step.
-C7 OK - the search statistics and the successful proof path are internally consistent.
-C8 OK - a second search found no alternative solution, so the solution is unique.