Status: Active; optional desktop IDE release 0.9.0 implemented

IMPLEMENTATION SNAPSHOT - TING 0.9.0

Adds the optional PySide6 section editor and compiler around the unchanged
0.8.5 reasoning core. The light Ting theme uses original green/gold/mint icons,
custom window chrome, file dialogs, menus, tooltips, and categorized offline help.
File previews, loads, saves, validation, tests, and compilation run in separate
processes. Successful verified builds publish atomically; cancelled builds leave
the prior output intact. Saved source and local module mappings reopen at startup.

The supplied v0.8.3 language HTML manual remains byte-for-byte unchanged. The
optional GUI has its own help. Base runtime dependencies remain empty; PySide6
is installed only through the ide extra. Local Qt checks use Linux/offscreen;
Windows native chrome, display scaling and system integration await user review.

The roadmap revision below is the same decision-capability plan as the separate
Revision 3.0 HTML roadmap. Its numbered sections are document chapters, and its
implementation table lists eight deliverables. Performance applies throughout.
Its 0.2.0 baseline is historical; the snapshot above describes this release.

# Ting Reasoner — Decision Capability Roadmap

**Roadmap revision:** 3.0  
**Date:** 27 September 2026  
**Implementation baseline:** Ting Reasoner 0.2.0  
**Status:** Forward requirements; proposed capabilities are not shipped APIs.

## 1. Product purpose

Ting computes decisions from explicit knowledge, evidence, constraints, and decision policies. Its output is a typed result that an application can inspect, verify, store, and act upon. The product succeeds when it selects a justified option, identifies a precise obstacle to selection, or proves that no permitted option satisfies the stated requirements.

The central objective is **better decisions under changing, incomplete, or conflicting information, with reproducible evidence and bounded computation**.

Conversational behavior and English sentence generation are outside the roadmap. There is no grammar engine, sentence planner, surface realizer, chatbot, dialogue memory, or LLM integration objective. A diagnostic code, developer-written label, or ordinary API error message does not require a language-generation subsystem. Structured explanations remain essential: they are the evidence behind a decision.

This revision replaces the earlier product priorities and delivery ordering. It preserves the established correctness, portability, licensing/provenance, project-domain, and resource obligations unless a change is expressly recorded below. Historical implementation details remain in the 0.2.0 source release and revision 2.1. The roadmap revision is independent of the package version; this document does not release Ting 3.0 or change the 0.2.0 executable artifacts.

## 2. What is already available

The 0.2.0 source release is the implementation baseline. Completed components are retained and extended.

| Area | Current capability | Remaining boundary |
| --- | --- | --- |
| Authoring | Readable `.ting` rules, typed declarations, explicit imports/exports, isolated embedded tests, and Python compilation APIs | Seed knowledge, classifications, reference types, full semantic source maps, and migration are unfinished |
| Execution | Deterministic forward rules, Boolean conditions, quantified patterns, stratified negation, fixed-shape arrays, transactions, and logical work budgets | Complete incremental retraction, aggregates, goal solving, and richer decision policies remain unfinished |
| Explanations | Structured rule, fact, and binding provenance through `engine.explain()` | Complete multiple-support proof graphs, decision certificates, and why-retracted records are unfinished |
| Performance | Equality/range indexes, pruning, bounded optional caches, and independent-session multiprocessing | A single live engine is not partitioned across workers; exact memory accounting remains unfinished |
| Artifacts | Verified `.tingir` Compact-IR, source and compiled file APIs, documentation, wheel, and source distribution | `.tingpack` deployment, generation activation, and durable rollback are unfinished |
| Verification | The last 0.2.0 Linux run passed 605 tests with one environment-related skip | Windows/macOS execution and the complete production release criteria remain outstanding |

Current base-fact changes invalidate retained inference state. This must not be advertised as the precise incremental support maintenance specified in this roadmap. Current structural/source identity comparison is also not behavioral equivalence checking.

## 3. Decision request and result contract

Define the result contract before adding individual decision features. All names in this section are proposed contract names, not imports or functions available in 0.2.0.

A request must identify the goal, candidate options or a bounded candidate generator, hard constraints, preference policy, evidence policy, fact snapshot, logical evaluation time, and computation limits. It must state whether the candidate universe is closed and which assumptions bound the decision.

Hard constraints establish feasibility. Preferences rank feasible options. A preference score cannot cancel a hard-constraint failure. Rule firing priority must not silently become decision preference.

Keep these dimensions separate:

| Dimension | Proposed values or contents | Meaning |
| --- | --- | --- |
| Evaluation status | `COMPLETE`, `BUDGET_EXHAUSTED`, `CANCELLED`, `FAULTED` | Whether the requested computation finished |
| Decision outcome | `SELECTED`, `NO_FEASIBLE_OPTION`, `NEEDS_DATA`, `CONFLICTED`, `MULTIPLE_VALID_OPTIONS`, `UNDETERMINED` | What the completed analysis establishes; incomplete evaluation returns `UNDETERMINED` |
| Candidate feasibility | `FEASIBLE`, `INFEASIBLE`, `UNKNOWN`, `CONFLICTED` | Whether each option satisfies the hard requirements under the declared evidence policy |
| Evidence state | `SUPPORTED`, `REFUTED`, `UNKNOWN`, `CONFLICTED` | The available support and opposition for a particular proposition |
| Search coverage | Domain identifier, bounds, coverage, pruned regions, and completion | Where a search claim applies |
| Selection claim | Feasible choice, policy-ranked winner, tied set, Pareto set, or certified optimum | Exactly what has been established about alternatives |

`COMPLETE` with `NEEDS_DATA` is valid: evaluating the available information can finish even though a necessary fact is unknown. A resource limit must not be disguised as missing evidence. An incomplete run may return a validated feasible candidate separately, but must not label it the final winner or a proved optimum.

`NO_FEASIBLE_OPTION` requires a complete check or sound impossibility certificate over the declared closed candidate universe. An unknown or conflicted option prevents that claim unless an explicit, recorded policy excludes it. A result valid within a bounded domain never becomes a claim about all possible options.

Each result also carries stable reason codes, constraint evaluations, support and opposition references, unresolved dependencies, alternatives, policy identity, program identity, snapshot identity, logical time, work counters, and verification scope. Final decisions expose why a candidate was chosen and why competing candidates were rejected or left unresolved.

Ties remain ties unless the author explicitly supplies a tie-breaking policy. Sorting candidates by ID for display does not authorize selecting the first one.

### Illustrative machine-readable result

This is a design example, not the output schema of a released function. A job-placement policy prefers lower energy use among feasible workers. One worker has a stale capacity observation and might outrank the known feasible worker.

```json
{
  "evaluation_status": "COMPLETE",
  "decision_outcome": "NEEDS_DATA",
  "selected_option": null,
  "candidate_domain": {
    "id": "registered-workers-v1",
    "closed": true,
    "size": 2
  },
  "candidates": [
    {"id": "worker_a", "feasibility": "UNKNOWN"},
    {"id": "worker_b", "feasibility": "FEASIBLE"}
  ],
  "unresolved": [
    {
      "reason_code": "STALE_EVIDENCE",
      "candidate": "worker_a",
      "required_fact": "available_capacity",
      "blocks": ["FEASIBILITY", "PREFERENCE_COMPARISON"]
    }
  ],
  "scope": {
    "program_id": "example-program-v1",
    "policy_id": "energy-then-latency-v1",
    "snapshot_id": "example-snapshot-17",
    "logical_time": 3600
  }
}
```

Production identities must use the documented canonical identity scheme. The example labels above are placeholders. The result communicates everything required for application control without generating a paragraph.

## 4. Reliable decisions as facts change

Implement multiple-support justification tracking for every derived fact and conclusion. Retraction removes a conclusion only when its final valid support disappears. Removing one of two independent supports preserves the conclusion and updates its evidence.

Dependencies must cover positive facts, closed-world absence, quantified conditions, aggregate groups, rule versions, and relevant evidence-policy decisions. A newly inserted fact can invalidate a conclusion that depended on its absence. Recursive support cycles must not preserve conclusions after all grounding support disappears.

Maintain counts, distinct counts, sums, minima, maxima, and averages incrementally. Define empty-group behavior, duplicate semantics, numeric types, overflow/precision policy, and retraction behavior explicitly. Array reductions require their own typed, bounded semantics. Recursive aggregates remain deferred until their semantics and termination bounds are established.

Use immutable snapshots and atomic publication so a result refers to one coherent state. Failure leaves the last committed state usable. Explain changes using structured support-added, support-removed, condition-invalidated, and decision-changed records linked to public `.ting` declarations.

**Acceptance:** Removing either independent support alone preserves the conclusion; removing both withdraws it and all unsupported consequences. Groundless cycles, negation changes, aggregate updates, and failed transactions agree with the independent reference interpreter. Incremental and fresh recomputation produce equivalent decisions and logical evidence under documented identity mapping.

## 5. Feasibility, alternatives, and decision policy

Provide first-class candidate evaluation with explicit hard constraints and preferences. Support lexicographic priorities and Pareto alternatives before more elaborate objective combinations. If weighted scores are added, authors must specify units, normalization, numeric rules, and tie handling; unrelated quantities cannot be added implicitly.

For each candidate, record satisfied, failed, unknown, and conflicted constraints. Return the exact blocking constraints and the rules/facts establishing them. Preserve viable alternatives rather than discarding every option except one winner.

Offer structured conflict policies such as refusing selection, applying a declared authority order, or excluding an option under a named rule. Conflict resolution must retain the opposing evidence and the policy that resolved it. Priority does not establish that one source is true.

**Acceptance:** A high preference score never overcomes a failed hard constraint. Identical inputs and policy produce identical choice sets and ordering. Ties, unknown feasibility, incomplete candidate generation, and incomparable Pareto options remain visible. Small finite problems are checked against exhaustive enumeration.

## 6. Evidence validity and scoped absence

Represent positive support and explicit opposition separately. Missing evidence is unknown under an open-world policy. Closed-world absence requires an explicit scope and completeness declaration; an empty relation alone must not prove that an event or object cannot exist outside that scope.

Record the source, observation time, applicable interval, permitted age, and any declared authority or completeness boundary. Use an injected logical clock. Reading the host wall clock during inference must not silently change a result.

Keep evidence freshness separate from the truth value of a proposition. A stale positive observation does not automatically become negative evidence. Duplicate reports or multiple derivations from the same observation do not automatically increase confidence. Support counts are not probabilities.

The core policy returns supported, refuted, unknown, or conflicted states. Probability intervals, fuzzy memberships, and certainty factors are separate later extensions requiring explicit semantics; there is no generic confidence percentage attached to every result.

**Acceptance:** An expired observation, a fresh contradiction, and a missing observation lead to distinct machine-readable records. Changing logical time alone can invalidate affected evidence deterministically. Completeness assertions identify their issuer and scope; verification checks their use, not their truth in the external world.

## 7. Bounded goals and constraint solving

Add typed goals and memoized subgoals over the same public semantic model and verified execution representation. Goal evaluation returns proof, failure under a declared policy, missing evidence, or incomplete computation as distinct results. It must not launch unbounded recursive search.

Add a finite-domain constraint subset for candidate construction and feasibility: explicit domains, equality/inequality, bounded arithmetic, all-different, propagation, and bounded backtracking. Domain restrictions and pruning must preserve every permitted solution. Return a solution witness or a checkable failure explanation within the specified domain.

Solvers consume an immutable snapshot and return proposed results. They do not mutate the live fact store while searching. No general-purpose theorem prover or universal optimizer is promised.

**Acceptance:** Exhaustive small-domain oracles agree on solutions and failures. Bounds and cancellation produce honest incomplete results. Goal caches are invalidated when their relevant facts, rules, or policies change.

## 8. Decision robustness and counterfactuals

Answer structured questions about a completed decision: which permitted changes alter it, which do not, and what smallest admissible change reaches a specified alternative outcome.

The caller defines mutable inputs, immutable facts, admissible edits, change cost, domain bounds, and target outcome. Counterfactuals cannot satisfy a goal by silently changing the rule set, the decision policy, or facts declared immutable. Change costs use explicit non-financial measures such as number of edits, elapsed time, or resource consumption.

Return a concrete changed-fact witness, the resulting decision, the assumptions held fixed, and the exact scope of any robustness or minimality claim. A failed bounded search means no witness was found within the examined scope. It does not establish unrestricted impossibility.

Minimal by set inclusion, smallest number of changes, and minimum declared cost are different claims. Every result names the one proved. Sampling establishes only behavior on sampled cases. A robustness region requires exhaustive finite coverage or a sound certificate for the unexamined region.

**Acceptance:** Every returned witness reproduces the claimed outcome in a fresh session. Brute-force cases confirm minimality and invariance claims. Exhausted searches never report unproved robustness. Pruning remains sound with negation, aggregates, and conflicting evidence.

## 9. Next useful data acquisition

Return typed requests for measurements, inspections, or facts that could resolve a decision. This is a planning capability; it does not produce conversational questions or collect data itself.

Authors declare available observations, possible outcomes or bounded outcome classes, acquisition prerequisites, latency, resource cost, and admissibility. Compare how each outcome changes candidate feasibility, conflict, or preference. Return the decision dependencies affected by each proposed observation.

Start with deterministic objectives: minimizing worst-case unresolved alternatives, minimizing the number of observations required, or finding a least-cost sufficient observation set within a declared finite search space. Each objective defines its own ordering and ties. A sufficient set must resolve the stated goal for every admitted outcome combination, or report exactly which combinations remain unresolved.

No expected value or probabilistic information-gain claim is permitted without an explicitly supplied probability model. An observation that cannot affect any unresolved decision dependency should be pruned. If no available observation can resolve the question, return that limitation within the declared observation model.

**Acceptance:** An irrelevant observation ranks below one that improves the declared objective when other requirements are equal. The chosen observation or set has a replayable comparison record. Search truncation cannot be labeled globally cheapest or guaranteed sufficient. Actual data acquisition remains a host action.

## 10. Behavioral comparison of rule versions

Compare versions using decisions, feasibility classifications, selected alternatives, and declared policy outcomes. A changed digest establishes that something changed; it does not explain whether behavior changed.

Accept a fixed corpus or a bounded generated input domain with shared candidate, evidence, clock, and policy assumptions. Return concrete inputs that produce different outcomes, affected source declarations, and any change in validity requirements. Distinguish changed supporting derivations from changed decisions.

Use separate comparison results for a counterexample found, exhaustive equivalence within a stated finite domain, agreement on a finite corpus, and incomplete comparison. Budget exhaustion on one version must not be silently treated as logical disagreement or agreement; report evaluation differences separately.

**Acceptance:** Each counterexample reproduces both results from preserved artifacts. Claimed bounded equivalence agrees with an independent exhaustive oracle. A ruleset with no counterexample in a sample is never labeled universally equivalent.

## 11. Decision receipts and independent verification

Produce immutable decision receipts binding the result to program, policy, input snapshot, logical time, candidate universe, relevant semantic versions, and logical computation limits. Receipts include structured reasons and proof references, not generated narration.

Build a small independent verifier for supported certificate types. A positive derivation certificate checks its rule applications and facts. A certificate involving absence, aggregate values, optimality, or a closed candidate universe must also establish the relevant coverage obligations. A list of winning facts alone cannot prove those claims.

Use bounded encoding and explicit verifier results: valid, invalid, unsupported certificate type/version, or incomplete verification. A verifier reaching its budget must not return valid. Shared subproofs and bounded retention control size without silently deleting evidence needed for verification.

Integrity digests detect changed content. They are not source authentication or a guarantee that observations are true. Verification establishes a derivation under the supplied inputs and policies.

Deploy through `.tingpack` with exact resolved dependencies, source maps, and test evidence. Preserve generation-pinned sessions, atomic activation, corruption rejection, and rollback by a new generation. A failed activation must leave the prior valid generation intact, subject to the existing explicit project-policy closure rules.

**Acceptance:** An independent verifier accepts valid supported receipts and rejects tampered facts, policies, rules, scope, and proof edges. Crash-injection tests establish old-or-new package visibility. Existing sessions keep their original program identity after a new package is published.

## 12. Time-dependent decisions

Extend basic logical-time freshness into explicit event-time reasoning: bounded windows, order constraints, expiration, out-of-order input, lateness policy, and window closure.

An event not yet observed is not the same as an event proved absent from a closed interval. Watermarks or equivalent completeness declarations establish when the relevant interval is closed. Temporal dependencies join the same support graph so late or expired evidence updates affected decisions precisely.

**Acceptance:** Replaying the same events, logical times, completeness declarations, and lateness policy produces identical decisions. An open window cannot supply proof of temporal absence. Boundary-time cases and permitted late arrivals are tested against reference semantics.

## 13. Pure-Python performance strategy

Keep the implementation entirely Python with the standard library as the core runtime dependency set. Preserve the universal wheel, explicit executor ownership, and absence of import-time workers or global multiprocessing configuration changes.

Prioritize selective incremental work: dependency-directed re-evaluation, shared support graphs, typed indexes, aggregate deltas, memoized bounded goals, candidate elimination, and reusable immutable snapshots. Compile portable rules before inference. Formatting, documentation, and file lookup do not belong in the matching loop.

Use multiprocessing first where independence is explicit: separate requests, counterfactual branches, candidate scenarios, and rule-version comparisons. Share immutable plan data where practical and transfer bounded work/result records. The parent owns deterministic publication and ordering. Do not allow workers to mutate a common live engine.

Single-engine operator partitions remain later measured work. Admission requires useful end-to-end improvement after process startup, serialization, memory duplication, and merge costs. Inline execution remains available and is preferred below the measured break-even point. Nested evaluation uses the caller's shared parallel budget and creates no implicit worker pool.

Pruning must have a sound reason: a failed hard constraint, a valid dominance relation, an unreachable dependency, or an admissible bound. Optimizations cannot assume monotonicity where negation or other operators invalidate it. Logical-budget charging and result semantics remain consistent with the declared execution contract.

Benchmark decision latency, update work, repeated-request throughput, pruning counts, support/proof memory, and process overhead on the same corpus. Retain the established release performance floors and record new feature baselines before selecting numerical targets. No universal speed advantage over native engines is claimed.

## 14. Implementation sequence and completion evidence

Milestones identify deliverables, not package versions or calendar promises. Every milestone includes its source representation, public API, diagnostics, reference semantics, relevant tests, and HTML examples. Completion is recorded feature by feature.

| Order | Deliverable | Dependency and required evidence |
| --- | --- | --- |
| 1 | Complete `.ting` knowledge/source contracts and specify decision requests/results | Seed knowledge, classifications, references, origin maps, migration, policy gates, and source/API agreement; proposed result fields validated before being published as API |
| 2 | Multiple-support maintenance, aggregates, and structured change explanations | Correctness under insert/retract/replace, groundless cycles, absence, failed transactions, and bounded recursion; reference parity |
| 3 | Candidate feasibility, explicit preferences, evidence validity, and conflict policies | Decisions with ties, unknowns, conflicts, and stale data; no accidental hard-constraint override or hidden tie-break |
| 4 | Immutable decision profiles, complete resource accounting, receipts, and `.tingpack` deployment | Snapshot/policy/program binding, precise budgets, generation pinning, activation failure, and crash recovery |
| 5 | Bounded goals and finite-domain constraints | Exhaustive small-domain agreement and honest incomplete outcomes |
| 6 | Counterfactuals, robustness, and observation planning | Reproducible witnesses, correctly scoped minimality/coverage, acquisition objectives, and measured pruning |
| 7 | Behavioral version comparison and independent certificate verification | Reproducible counterexamples; supported proof types checked independently; no overclaim about equivalence |
| 8 | Full temporal decisions and measured single-engine partitions | Window/late-event semantics; deterministic merging; a positive measured parallel return |

Cross-platform checks, pure-Python packaging, and measured independent-session parallelism continue throughout. A smaller release may deliver a coherent completed subset. It must name that subset and its limits; publication does not mark an entire milestone complete.

The first implementation increment should complete the missing source/knowledge boundary and establish the decision contract. The next concrete reasoning increment should preserve and retract multiple supports correctly. Advanced decision capabilities then build on those verified dependencies.

## 15. Acceptance program

Use an independent reference interpreter and small exhaustive decision oracles alongside the optimized runtime. Keep test effort proportional during development; reserve the broad production campaigns for their release gates.

| Property | Required demonstration |
| --- | --- |
| Decision correctness | Selected options satisfy hard constraints; infeasibility and optimum claims have complete scoped justification |
| Incremental correctness | Incremental updates and fresh evaluation agree, including alternate supports and support cycles |
| Evidence honesty | Missing, stale, opposing, incomplete, and computationally exhausted cases remain distinct |
| Determinism | Fixed program, policy, snapshot, logical clock, semantic versions, and logical budgets reproduce results across hash seeds and supported worker counts |
| Search soundness | Every counterfactual/constraint witness replays; pruning retains all admissible solutions; incomplete searches make no completeness claim |
| Isolation | Scenario evaluation and inspection never mutate the live snapshot; workers honor caller ownership and budgets |
| Portability | Supported Python/Windows/Linux/macOS combinations install and run; native paths, spaces, Unicode paths, and multiprocessing spawn are exercised |
| Publication | Corruption and interrupted writes cannot expose a partial active package; old sessions remain pinned |
| Usability | A developer authors, compiles, executes, and inspects a decision using documented `.ting` and Python APIs |

External deadlines and cancellation are scheduling-dependent service controls. Preserve committed state, but do not promise identical interruption points or terminal traces across worker counts when those controls are used.

The existing full-release obligations remain: at least one million generated differential transitions with no unexplained mismatches, the established benchmark floors, the crash/corruption campaign, at least 90% overall and 95% critical semantic/IR/store branch coverage, and a 72-hour high-churn soak. They are production release evidence, not work to rerun for every documentation edit. Remaining array semantics, hostile-input bounds, artifact verification, licensing/provenance, and dependency-admission requirements from revision 2.1 are retained.

## 16. Public source, API, and documentation

Every portable decision concept must have a documented `.ting` representation and public semantic meaning. A Python convenience API must not introduce knowledge that cannot be inspected or represented through the source contract. Unsupported syntax and feature versions fail explicitly.

Do not publish speculative function names as working examples. Add callable APIs and executable examples when their behavior is implemented. Source format, compiled format, runtime semantics, result schema, and package versions have separate compatibility contracts. New seed or decision semantics must not be silently inserted into the existing format-4/semantics-5 compiled encoding.

Keep the existing HTML library manual's navigation, layout, search, and example style. Organize future additions around developer tasks: defining a decision, handling missing data, resolving conflicts, inspecting alternatives, updating evidence, checking robustness, comparing policies, and verifying receipts. Show Python objects or JSON and concrete `.ting` files. Show failures and incomplete results as clearly as successes.

Roadmap status and implementation history stay in planning/release documents. The library manual describes available behavior and clearly identified limitations. Explanations use structured reason codes, failed/satisfied conditions, source locations, and evidence records. English composition and chatbot interaction are not dependencies of any API, example, or acceptance criterion.

## 17. Relationship to the previous roadmap

| Previous commitment | Treatment in revision 3.0 |
| --- | --- |
| Phases 0–4: semantic foundation, reference engine, compiler, store, and forward execution | Retained; existing work is reused and outstanding correctness/performance obligations remain |
| Phase 4S: full public source and compiler boundary | Retained as milestone 1; the 0.2.0 rules-core subset does not close this work |
| Phase 5: JTMS, aggregates, provenance, recursion, and budgets | Retained in milestones 2–4; explanations are structured decision evidence |
| Phase 6: profiles, action boundaries, and resource governance | Retained in milestones 3–4; the host receives typed results/intents and owns external actions |
| Phase 7: atomic RulePack deployment | Retained in milestone 4 |
| Phase 8: cooperative multiprocessing and observation | Independent-session work retained now; advanced partitions remain in milestone 8 after measured benefit |
| Phases 9–10: production hardening and stable contracts | Retained as release obligations; neither this document nor plain version numbering declares completion |
| Backward goals and finite-domain constraints | Prioritized as bounded decision capabilities in milestone 5 |
| Temporal reasoning | Basic freshness in milestone 3; complete event/window semantics in milestone 8 |
| Deeper explanations | Recast as machine-readable decision changes, alternatives, counterfactuals, and certificates |
| Broad fuzzy/probabilistic evidence algebras | Deferred until exact decision capabilities are reliable; each remains an explicit separately specified extension |
| Rationale sentence templates and the proposed English-generation layer | Removed from the active roadmap; static labels and ordinary diagnostics remain available to host presentation |

The existing project boundary rejecting banking and financial applications is retained. Existing semantic-Text hard-close and declared-purpose requirements remain unfinished work and must be specified and tested consistently before claims of enforcement. This roadmap neither changes the released license nor claims that marker scanning detects real-world purpose. Independent implementation provenance and distribution-license controls also remain in force.

The intended distinguishing capability is a single portable decision system that can select among alternatives, preserve the reasons for selection, update the selection when evidence changes, identify useful missing information, measure sensitivity within explicit bounds, and let another program verify the result. Each of those is a decision capability with a testable contract.
