quantum-reasoning-skill 1.0.0 → 1.1.0

package/LICENSE

@@ -1,21 +1,21 @@
-MIT License
-
-Copyright (c) 2026 Furox
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
+MIT License
+
+Copyright (c) 2026 Furox
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -1,133 +1,86 @@
-# Quantum Reasoning Skill
-> **Superseded:** this standalone skill was merged into **Axiomize 2.0** and now lives as
-> `axiomize.reasoning` in **[Furox-Art/axiomize-quantum-skills-2.0](https://github.com/Furox-Art/axiomize-quantum-skills-2.0)**,
-> where it ships next to the scientific modeling engine as `skills/quantum-reasoning/`.
-> New work, issues, and contributions should go to the Axiomize repo. This repository is kept
-> for historical reference and will be archived.
-
-A **model-agnostic reasoning skill** that keeps multiple genuinely different possibilities alive, verifies and compares them, suppresses weak paths, revives useful alternatives when evidence changes, and selects the best-supported result only at the end.
-
-> This is quantum-inspired classical reasoning, not quantum computation.
-
-## Main artifact
-
-The project is centered on [`SKILL.md`](./SKILL.md). The skill changes the model's reasoning procedure without retraining the model.
-
-```text
-problem
-  -> open diverse possibilities
-  -> verify independently
-  -> compare contradictions and shared assumptions
-  -> score / classify branches
-  -> allocate compute dynamically
-  -> suspend or reject weak branches
-  -> revive branches when evidence changes
-  -> verify collapse criteria
-  -> select the best-supported answer
-```
-
-## Design goals
-
-- Reduce early lock-in to the first plausible answer.
-- Maintain genuinely independent hypotheses or solution strategies.
-- Prefer falsification and tool-based verification over self-confidence.
-- Expand search when uncertainty is high and concentrate compute when evidence is strong.
-- Detect correlated branches so repeated assumptions are not counted as independent evidence.
-- Keep high-information alternatives recoverable instead of deleting them too early.
-- Work across hosts that can preserve the skill instruction contract.
-- Make reasoning-control decisions measurable without exposing private chain-of-thought.
-
-## Repository contents
-
-- [`SKILL.md`](./SKILL.md) — model-facing protocol
-- [`reference/branch_controller.py`](./reference/branch_controller.py) — deterministic reference scoring, state transition, revival, uncertainty and collapse logic
-- [`docs/MEASUREMENT.md`](./docs/MEASUREMENT.md) — explicit formulas, thresholds and calibration requirements
-- [`docs/COMPATIBILITY.md`](./docs/COMPATIBILITY.md) — capability-based host compatibility contract
-- [`examples/usage.md`](./examples/usage.md) — task examples
-- [`examples/host-integration.md`](./examples/host-integration.md) — generic host integration patterns
-- [`benchmark/cases.jsonl`](./benchmark/cases.jsonl) — deterministic seed cases
-- [`benchmark/evaluate.py`](./benchmark/evaluate.py) — baseline-vs-skill evaluator
-- [`benchmark/validate_submission.py`](./benchmark/validate_submission.py) — reproducible community-result bundle validator
-- [`benchmark/schemas/`](./benchmark/schemas/) — JSON Schema contracts for cases, metadata, result rows and comparison output
-- [`benchmark/README.md`](./benchmark/README.md) — reproducible benchmark protocol
-- [`CONTRIBUTING.md`](./CONTRIBUTING.md) — contribution and independent benchmark-submission policy
-- [`SECURITY.md`](./SECURITY.md) — vulnerability-reporting policy
-- [`CITATION.cff`](./CITATION.cff) — citation metadata
-- [`tests/`](./tests/) — behavioral and validation tests
-- GitHub Actions validation on pushes and pull requests
-- CI-gated automated tag and GitHub Release publishing
-
-## Core capabilities
-
-- Adaptive multi-branch reasoning
-- Semantic diversity requirements
-- Active / dormant / rejected branch states
-- Independent verification rules
-- Contradiction and shared-assumption checks
-- Correlation penalty for duplicated/shared-assumption branches
-- Interference-like cross-branch comparison
-- Dynamic compute allocation from uncertainty
-- Measurable branch revival rules
-- Explicit stopping / collapse criteria
-- Baseline-vs-skill benchmark telemetry
-- Final requirement and contradiction check
-
-## Usage
-
-Install or provide `SKILL.md` to a compatible agent/skill system, then invoke it for difficult reasoning tasks. No Python package or model fine-tuning is required to use the skill itself.
-
-See [`docs/COMPATIBILITY.md`](./docs/COMPATIBILITY.md) before integrating a new host and [`examples/host-integration.md`](./examples/host-integration.md) for generic installation patterns.
-
-The Python reference implementation is optional. It exists to make the qualitative policy auditable and testable:
-
-```python
-from reference.branch_controller import Branch, BranchMetrics, collapse_decision
-```
-
-## Benchmarking
-
-The repository provides the **protocol, cases, schemas, evaluator and submission validator** needed to test the skill. Real model evaluations are intentionally **community-run**: users test the models/providers they have access to and may submit reproducible results back to the project.
-
-The project does not require the maintainer to run every commercial or local model, and it does not treat the absence of maintainer-run model tests as a missing implementation feature.
-
-A valid comparison uses the **same model, model version, task set, tool access, temperature/sampling settings and token-budget policy** with and without `SKILL.md`.
-
-```bash
-python benchmark/evaluate.py \
-  --cases benchmark/cases.jsonl \
-  --baseline path/to/baseline-results.jsonl \
-  --skill path/to/skill-results.jsonl \
-  --output comparison.json
-```
-
-Community PR bundles are machine-checked. They must contain their own `cases.jsonl`, raw baseline and skill JSONL files, metadata, the generated comparison output and a short README. CI recomputes the comparison and rejects tampered or incomplete bundles.
-
-```bash
-python benchmark/validate_submission.py \
-  --root benchmark/results/community \
-  --allow-empty
-```
-
-Third-party results remain measurements from their submitters, not automatic project endorsements or universal performance claims. A single positive run is not enough to claim general improvement.
-
-Users can submit results through the **Benchmark result** issue template or as a reproducible benchmark-result pull request. See [`benchmark/README.md`](./benchmark/README.md) and [`CONTRIBUTING.md`](./CONTRIBUTING.md).
-
-## Validation
-
-Run the repository checks locally with:
-
-```bash
-python -m unittest discover -s tests -v
-python benchmark/evaluate.py --help
-python benchmark/validate_submission.py --root benchmark/results/community --allow-empty
-```
-
-CI validates the skill contract, local links, Python syntax, benchmark seed data, JSON Schema files, community benchmark bundles and behavioral tests. Third-party GitHub Actions are pinned to exact commit SHAs.
-
-## Releases
-
-Release publishing is repository-native and CI-gated. Update `CHANGELOG.md`, then change the root `VERSION` file to a semantic version. A release is considered only after the `validate-skill` workflow succeeds on `main`; the `publish-release` workflow then creates the corresponding `v<version>` tag and GitHub Release if it does not already exist.
-
-## Status
-
-**v0.3.1 — hardened measurable prototype.** The branch-control mechanism, benchmark infrastructure, host compatibility contract, community-result validation, repository security/citation metadata and CI-gated release controls are implemented. Real-model evaluation is intentionally delegated to independent users and contributors, and the project makes no universal performance claim without reproducible external evidence.
+# Quantum Reasoning Skill  
+  
+[![PyPI](https://img.shields.io/pypi/v/quantum-reasoning-skill)](https://pypi.org/project/quantum-reasoning-skill/)  
+[![npm](https://img.shields.io/npm/v/quantum-reasoning-skill)](https://www.npmjs.com/package/quantum-reasoning-skill)  
+[![PyPI stats](https://img.shields.io/badge/PyPI%20stats-informational)](https://pypi.org/project/quantum-reasoning-skill/#stats)  
+[![License](https://img.shields.io/badge/license-MIT-blue)](LICENSE)  
+  
+I built this because I noticed that most AI reasoning goes like this:  
+  
+1. Here's a plausible answer  
+2. Let me justify it  
+3. Done  
+  
+That's backwards. Real thinking explores multiple paths, tests them against evidence, and only commits when the alternatives have been genuinely eliminated.  
+  
+This skill forces that process. It keeps multiple hypotheses alive, assigns them probabilities based on actual evidence (not just "sounds good"), and collapses to a conclusion only when one path is clearly better supported than the rest.  
+  
+## Quick Start  
+  
+```bash
+pip install quantum-reasoning-skill
+```
+
+```python
+from quantum_reasoning_skill import ReasoningSession
+
+session = ReasoningSession(problem="Should we migrate our monolith to microservices?")
+session.open_branch("strangler-fig incremental")
+session.open_branch("big-bang rewrite")
+session.open_branch("modular monolith refactor")
+
+session.evaluate(evidence="team has zero k8s experience", branch="big-bang rewrite", impact=-0.4)
+session.evaluate(evidence="current deploys take 45min", branch="modular monolith", impact=+0.2)
+
+verdict = session.collapse()
+print(verdict.winner, verdict.confidence, verdict.rejected)
+```
+
+Also available as an [Agent Skill](SKILL.md) for Claude and MCP-compatible hosts, and on npm: `npm i quantum-reasoning-skill`.
+
+## How it compares
+
+| Approach | What it does | Where it falls short |
+|---|---|---|
+| Chain-of-Thought | One linear reasoning path | Early anchoring; no alternatives kept alive |
+| Tree-of-Thought | Branches + scoring | Static scoring; no evidence weighting or revival |
+| Self-consistency | Samples the same prompt N times | Paraphrase diversity, not genuine hypothesis diversity |
+| **This skill** | Branches with evidence-weighted probabilities, cross-checking, pruning with revival, and explicit collapse criteria | — |
+
+## The protocol  
+  
+1. **Frame the problem** - what do we actually know vs. assume?  
+2. **Open branches** - generate genuinely different approaches, not paraphrases  
+3. **Evaluate independently** - each branch gets judged on evidence, not eloquence  
+4. **Cross-check** - branches that reach the same conclusion independently get boosted  
+5. **Prune and revive** - kill contradicted paths, but keep dormant ones that might come back  
+6. **Collapse** - only when one answer is clearly better than the rest  
+  
+## Why "quantum"?  
+  
+It's a metaphor, not a claim about actual quantum computing. The idea is to keep possibilities in superposition until measurement (evidence) forces a collapse. Most AI systems measure too early.  
+  
+## Common use cases
+
+- **Multi-branch reasoning** for difficult questions where one early answer can anchor the rest of the analysis.
+- **AI agent planning and decision support** with explicit competing hypotheses.
+- Evidence-based **problem solving, search, pruning, and branch selection**.
+- Scientific or technical analysis where independent approaches should be compared before a conclusion is chosen.
+- Benchmarking reasoning systems that need an inspectable explore-score-prune-merge protocol.
+
+## Documentation
+
+- [SKILL.md](SKILL.md) — agent skill contract and protocol
+- [Usage examples](examples/usage.md)
+- [Host integration](examples/host-integration.md)
+- [Branch controller reference](reference/branch_controller.py)
+- [Measurement methodology](docs/MEASUREMENT.md)
+- [Compatibility notes](docs/COMPATIBILITY.md)
+- [Benchmark documentation](benchmark/README.md)
+- [Contributing](CONTRIBUTING.md)
+- [Security](SECURITY.md)
+- [Citation metadata](CITATION.cff)
+
+## License  
+  
+MIT. 

package/SKILL.md

@@ -1,146 +1,146 @@
----
-name: quantum-reasoning
-description: Maintain multiple genuinely different candidate hypotheses or solution paths, test them against evidence and tools, suppress weak or contradictory paths, revive useful alternatives when new evidence appears, and collapse to the best-supported answer only at the end.
----
-
-# Quantum Reasoning Skill
-
-A model-facing reasoning protocol inspired by the idea of keeping multiple possibilities alive before selection. It runs on classical models and classical hardware; it is not quantum computation.
-
-## When to use
-
-Use this skill when a problem is difficult, ambiguous, high-stakes, multi-step, or vulnerable to early commitment: mathematics, scientific reasoning, debugging, planning, architecture, model selection, hypothesis testing, and technical diagnosis.
-
-Do not add branching overhead to trivial questions.
-
-## Core protocol
-
-### 1. Frame the state
-
-Identify the objective, constraints, verified facts, assumptions, unknowns, and available tools. Keep facts separate from hypotheses.
-
-### 2. Open a diverse possibility set
-
-Create several materially different candidate paths. Diversity is mandatory: do not count paraphrases, cosmetic variants, or branches that depend on the same hidden assumption as independent possibilities.
-
-Prefer orthogonal strategy classes when applicable, such as:
-
-- direct derivation
-- counterexample / falsification
-- decomposition
-- alternative model or mechanism
-- numerical or executable test
-- independent reconstruction
-- adversarial critique
-
-### 3. Maintain branch states
-
-Treat each candidate as one of:
-
-- **active** — worth more compute now
-- **dormant** — currently weak but potentially recoverable
-- **rejected** — contradicted or decisively invalidated
-
-Never permanently reject a branch merely because another branch initially looks more plausible.
-
-### 4. Evaluate each branch independently
-
-Judge branches using evidence, not eloquence. Consider:
-
-- empirical or logical support
-- external verification
-- independence from other branches
-- information gain
-- contradiction count and severity
-- unresolved assumptions
-- expected value of another reasoning step
-- compute / tool cost
-
-Self-reported model confidence alone is weak evidence.
-
-### 5. Use tools to falsify, not merely confirm
-
-When available, route claims through the strongest suitable verifier: executable code, numerical tests, formal solvers, source lookup, direct file inspection, unit tests, symbolic algebra, or an independent model pass.
-
-Actively search for evidence that would disprove leading branches.
-
-### 6. Apply interference-like comparison
-
-Compare branches against each other without pretending to perform quantum interference.
-
-- Reinforce conclusions independently reached by different verified paths.
-- Penalize branches that conflict with verified facts.
-- Detect shared assumptions so correlated branches are not double-counted.
-- Transfer newly verified facts to every branch they constrain.
-- Preserve meaningful disagreement instead of averaging incompatible claims.
-
-### 7. Allocate compute dynamically
-
-Use uncertainty to control width and depth.
-
-- **Low uncertainty:** narrow quickly and deepen the strongest path.
-- **High uncertainty:** widen the possibility set.
-- **High-value unresolved branch:** spend additional tool or reasoning budget.
-- **Redundant or contradicted branch:** move to dormant or rejected.
-
-Branch count is adaptive, not fixed.
-
-### 8. Permit branch revival
-
-If new evidence invalidates a leading assumption or materially improves a dormant branch, restore that branch to active status and re-evaluate the ranking.
-
-### 9. Stop when more search has low value
-
-Collapse the possibility set when one result is sufficiently verified, remaining branches are redundant or falsified, or additional search is unlikely to change the decision enough to justify its cost.
-
-If multiple branches remain genuinely unresolved, report the alternatives and what evidence would distinguish them.
-
-### 10. Produce the answer
-
-Synthesize only from the strongest supported surviving branches. Run a final contradiction and requirement check before answering.
-
-Do not expose hidden chain-of-thought. Return the conclusion, concise supporting evidence, important uncertainty, and materially different surviving alternatives when necessary.
-
-## Adaptive intensity
-
-Use a rough internal intensity level:
-
-- **light:** 2–3 distinct candidates, one comparison pass
-- **standard:** 4–8 candidates, verification + pruning + one revival check
-- **deep:** 8+ candidates only when the problem and compute budget justify it; use repeated verification and adaptive expansion
-
-Do not mechanically maximize branch count. The goal is better search of the possibility space, not more text.
-
-## Operational reference policy
-
-When the host system can track aggregate branch metadata, use explicit normalized values in `[0, 1]` for evidence, verification, independence, information gain, contradiction severity, unresolved assumptions, compute cost, shared-assumption overlap, and semantic redundancy.
-
-A provider-agnostic reference controller is available in [`reference/branch_controller.py`](./reference/branch_controller.py). Its defaults make the qualitative protocol testable:
-
-- independence is reduced when branches share critical assumptions or are near-duplicates
-- strong contradiction can reject a branch
-- weak branches become dormant instead of disappearing
-- dormant branches can revive after a material evidence, verification, or contradiction change
-- uncertainty controls a recommended search width
-- collapse requires a verified leader, low contradiction, and a meaningful margin over surviving alternatives
-
-The exact scoring weights and thresholds are **reference defaults, not validated constants**. They must be calibrated against benchmark evidence rather than treated as universal truths. See [`docs/MEASUREMENT.md`](./docs/MEASUREMENT.md) for the auditable formulas and thresholds.
-
-Hosts that cannot expose these aggregate measurements should still follow the qualitative protocol above and must not invent numeric telemetry.
-
-## Benchmark requirement
-
-Do not claim that this skill improves reasoning merely because the protocol sounds plausible. Compare the same model and task configuration with and without the skill and measure at least accuracy, compute/token cost, latency, error recovery, contradiction resolution, and branch diversity when observable.
-
-The reproducible benchmark schema and evaluator live under [`benchmark/`](./benchmark/README.md).
-
-## Non-negotiable rules
-
-1. Do not call this real quantum computation.
-2. Do not treat repeated wording as independent evidence.
-3. Do not let one branch evaluate itself without challenge when verification is possible.
-4. Prefer falsification and executable checks over intuition.
-5. Preserve a recoverable record of high-information dormant branches.
-6. Collapse only after cross-branch comparison.
-7. Never fabricate evidence, tool results, sources, certainty, or branch telemetry.
-8. Do not present reference thresholds as empirically validated until benchmark evidence exists.
+---
+name: quantum-reasoning
+description: Maintain multiple genuinely different candidate hypotheses or solution paths, test them against evidence and tools, suppress weak or contradictory paths, revive useful alternatives when new evidence appears, and collapse to the best-supported answer only at the end.
+---
+
+# Quantum Reasoning Skill
+
+A model-facing reasoning protocol inspired by the idea of keeping multiple possibilities alive before selection. It runs on classical models and classical hardware; it is not quantum computation.
+
+## When to use
+
+Use this skill when a problem is difficult, ambiguous, high-stakes, multi-step, or vulnerable to early commitment: mathematics, scientific reasoning, debugging, planning, architecture, model selection, hypothesis testing, and technical diagnosis.
+
+Do not add branching overhead to trivial questions.
+
+## Core protocol
+
+### 1. Frame the state
+
+Identify the objective, constraints, verified facts, assumptions, unknowns, and available tools. Keep facts separate from hypotheses.
+
+### 2. Open a diverse possibility set
+
+Create several materially different candidate paths. Diversity is mandatory: do not count paraphrases, cosmetic variants, or branches that depend on the same hidden assumption as independent possibilities.
+
+Prefer orthogonal strategy classes when applicable, such as:
+
+- direct derivation
+- counterexample / falsification
+- decomposition
+- alternative model or mechanism
+- numerical or executable test
+- independent reconstruction
+- adversarial critique
+
+### 3. Maintain branch states
+
+Treat each candidate as one of:
+
+- **active** — worth more compute now
+- **dormant** — currently weak but potentially recoverable
+- **rejected** — contradicted or decisively invalidated
+
+Never permanently reject a branch merely because another branch initially looks more plausible.
+
+### 4. Evaluate each branch independently
+
+Judge branches using evidence, not eloquence. Consider:
+
+- empirical or logical support
+- external verification
+- independence from other branches
+- information gain
+- contradiction count and severity
+- unresolved assumptions
+- expected value of another reasoning step
+- compute / tool cost
+
+Self-reported model confidence alone is weak evidence.
+
+### 5. Use tools to falsify, not merely confirm
+
+When available, route claims through the strongest suitable verifier: executable code, numerical tests, formal solvers, source lookup, direct file inspection, unit tests, symbolic algebra, or an independent model pass.
+
+Actively search for evidence that would disprove leading branches.
+
+### 6. Apply interference-like comparison
+
+Compare branches against each other without pretending to perform quantum interference.
+
+- Reinforce conclusions independently reached by different verified paths.
+- Penalize branches that conflict with verified facts.
+- Detect shared assumptions so correlated branches are not double-counted.
+- Transfer newly verified facts to every branch they constrain.
+- Preserve meaningful disagreement instead of averaging incompatible claims.
+
+### 7. Allocate compute dynamically
+
+Use uncertainty to control width and depth.
+
+- **Low uncertainty:** narrow quickly and deepen the strongest path.
+- **High uncertainty:** widen the possibility set.
+- **High-value unresolved branch:** spend additional tool or reasoning budget.
+- **Redundant or contradicted branch:** move to dormant or rejected.
+
+Branch count is adaptive, not fixed.
+
+### 8. Permit branch revival
+
+If new evidence invalidates a leading assumption or materially improves a dormant branch, restore that branch to active status and re-evaluate the ranking.
+
+### 9. Stop when more search has low value
+
+Collapse the possibility set when one result is sufficiently verified, remaining branches are redundant or falsified, or additional search is unlikely to change the decision enough to justify its cost.
+
+If multiple branches remain genuinely unresolved, report the alternatives and what evidence would distinguish them.
+
+### 10. Produce the answer
+
+Synthesize only from the strongest supported surviving branches. Run a final contradiction and requirement check before answering.
+
+Do not expose hidden chain-of-thought. Return the conclusion, concise supporting evidence, important uncertainty, and materially different surviving alternatives when necessary.
+
+## Adaptive intensity
+
+Use a rough internal intensity level:
+
+- **light:** 2–3 distinct candidates, one comparison pass
+- **standard:** 4–8 candidates, verification + pruning + one revival check
+- **deep:** 8+ candidates only when the problem and compute budget justify it; use repeated verification and adaptive expansion
+
+Do not mechanically maximize branch count. The goal is better search of the possibility space, not more text.
+
+## Operational reference policy
+
+When the host system can track aggregate branch metadata, use explicit normalized values in `[0, 1]` for evidence, verification, independence, information gain, contradiction severity, unresolved assumptions, compute cost, shared-assumption overlap, and semantic redundancy.
+
+A provider-agnostic reference controller is available in [`reference/branch_controller.py`](./reference/branch_controller.py). Its defaults make the qualitative protocol testable:
+
+- independence is reduced when branches share critical assumptions or are near-duplicates
+- strong contradiction can reject a branch
+- weak branches become dormant instead of disappearing
+- dormant branches can revive after a material evidence, verification, or contradiction change
+- uncertainty controls a recommended search width
+- collapse requires a verified leader, low contradiction, and a meaningful margin over surviving alternatives
+
+The exact scoring weights and thresholds are **reference defaults, not validated constants**. They must be calibrated against benchmark evidence rather than treated as universal truths. See [`docs/MEASUREMENT.md`](./docs/MEASUREMENT.md) for the auditable formulas and thresholds.
+
+Hosts that cannot expose these aggregate measurements should still follow the qualitative protocol above and must not invent numeric telemetry.
+
+## Benchmark requirement
+
+Do not claim that this skill improves reasoning merely because the protocol sounds plausible. Compare the same model and task configuration with and without the skill and measure at least accuracy, compute/token cost, latency, error recovery, contradiction resolution, and branch diversity when observable.
+
+The reproducible benchmark schema and evaluator live under [`benchmark/`](./benchmark/README.md).
+
+## Non-negotiable rules
+
+1. Do not call this real quantum computation.
+2. Do not treat repeated wording as independent evidence.
+3. Do not let one branch evaluate itself without challenge when verification is possible.
+4. Prefer falsification and executable checks over intuition.
+5. Preserve a recoverable record of high-information dormant branches.
+6. Collapse only after cross-branch comparison.
+7. Never fabricate evidence, tool results, sources, certainty, or branch telemetry.
+8. Do not present reference thresholds as empirically validated until benchmark evidence exists.

package/VERSION

@@ -1 +1 @@
-0.3.1
+1.1.0