derive

45 beliefs (38 IN, 7 OUT)

• IN derive-achieves-flexibility-with-reproducibility
  The derive pipeline resolves the tension between strategic flexibility and deterministic reproducibility: three budget strategies (alphabetical truncation, random sampling, semantic clustering) provide diverse exploration approaches, while fixed-seed deterministic sampling and accurate proportional allocation ensure each strategy produces identical results across runs.
• IN derive-agent-budget-proportional
  When agents are present, `_build_beliefs_section` allocates prompt token budget proportionally to each agent's belief count, with a floor of 5 beliefs per agent
• OUT derive-agent-count-bug
  `_build_beliefs_section` has a bug: `count += len(belief_ids)` is inside the per-belief loop instead of outside it, inflating the count and shrinking the non-agent budget below intended size
• IN derive-apply-is-isolated-and-caller-validated
  The derive apply stage achieves defense-in-depth: callers must run validation before apply (trust boundary), and even if invalid proposals reach apply, each proposal is wrapped in independent error handling so one failure cannot corrupt the batch.
• IN derive-apply-isolates-per-proposal-errors
  `apply_proposals` wraps each `api.add_node()` call in try/except and accumulates `(proposal, error_string)` tuples, so one malformed proposal does not abort the batch.
• IN derive-budget-allocation-is-accurate
  The derive pipeline's proportional belief-budget allocation produces correct per-agent token counts
• IN derive-budget-count-is-linear
  Agent belief counting in `_build_beliefs_section` accumulates as N (number of beliefs shown per agent), not N² — the corrected behavior after the issue #23 fix where `count += len(belief_ids)` was moved outside the per-belief loop
• IN derive-budget-floor-five
  Each agent group and the non-agent group are guaranteed at least 5 belief slots in the prompt regardless of proportional budget allocation.
• IN derive-budget-is-efficient-and-floor-bounded
  The derive pipeline's per-agent budget allocation is both computationally efficient (O(N) linear accumulation, not quadratic) and representation-safe (each agent and local group guaranteed at least 5 belief slots), ensuring proportional allocation never starves minority agents.
• IN derive-budget-is-flexible-and-efficient
  The derive pipeline's budget allocation is both strategically flexible (three selection strategies: alphabetical truncation, random sampling, semantic clustering) and computationally efficient (linear accumulation with guaranteed floor of 5 per agent group), enabling callers to trade off reproducibility, diversity, and semantic coherence without performance penalty.
• IN derive-budget-local-floor-is-five
  `_build_beliefs_section` guarantees at least 5 local beliefs are shown regardless of agent budget pressure, via `max(5, max_beliefs - count)`
• IN derive-budget-tests-parse-output-headers
  Test implementation detail (regex parsing of `"showing N"` headers), not a production code invariant
• IN derive-budget-three-strategies
  `_build_beliefs_section` supports three budget strategies — alphabetical truncation (default), random sampling (`sample=True`), and semantic clustering (`cluster=True`) — all controlled by a single `max_beliefs` parameter.
• IN derive-depth-cycle-guard
  `_get_depth` sets `memo[node_id] = 0` before recursing to prevent infinite recursion on cyclic justification chains; cycles resolve to depth 0
• IN derive-fail-soft-validation
  `validate_proposals` filters invalid proposals into a skipped list rather than raising; `apply_proposals` catches per-item exceptions so one bad proposal never blocks others
• IN derive-min-antecedents-is-prompt-only
  The minimum-2-antecedents rule for derived beliefs is enforced only by the LLM prompt instructions, not validated in code by `validate_proposals`.
• OUT derive-no-llm-call
  `derive.py` builds prompts and parses responses but never calls an LLM itself; the caller (CLI or API) is responsible for the model invocation.
• IN derive-parse-supports-two-format-versions
  `parse_proposals` tries the new `### DERIVE id` format first, falling back to the older `### DERIVE: \`id\`` format only when the new parser returns zero matches.
• IN derive-parse-supports-two-formats
  `parse_proposals` tries the new format first (v0.10+: `### DERIVE id`), falls back to old format (v0.9: `### DERIVE: \`id\``) only when no new-format matches are found
• IN derive-pipeline-achieves-end-to-end-fault-tolerance
  The derive pipeline achieves end-to-end fault tolerance through three independent layers: proactive defense (fail-soft validation, Jaccard retraction guards, environment isolation), reactive resilience (partial results persisted via JSON reports after each round, error states signaled through return codes), and prompt reproducibility (deterministic sampling with fixed seeds enables consistent re-runs after failures).
• OUT derive-pipeline-has-end-to-end-quality-enforcement
  The derive pipeline achieves end-to-end quality enforcement: defensive validation prevents invalid proposals, Jaccard retraction guards prevent re-derivation of known-bad conclusions, budget allocation is accurate, AND the minimum-antecedents rule for derived beliefs is enforced in code — not just as an LLM prompt instruction that can be ignored.
• IN derive-pipeline-is-defensive
  The derive pipeline applies multiple defensive measures: fail-soft validation, Jaccard-based retraction guard, and environment variable stripping to prevent recursive spawning
• IN derive-pipeline-is-error-accumulating
  Covered by existing `derive-fail-soft-validation` (validation returns skipped entries with reasons) and `derive-pipeline-is-defensive` (broader defensive characterization)
• OUT derive-pipeline-is-exhaustive-and-terminating
  The derive pipeline supports exhaustive exploration mode while guaranteeing termination: `--exhaust` enables automatic application of all discovered proposals, and depth-based cycle detection with pre-recursion memoization prevents infinite loops even when justification chains are cyclic.
• OUT derive-pipeline-is-production-ready
  The derive pipeline correctly allocates budgets, validates proposals defensively, and produces well-formed beliefs through a round-trippable prompt contract.
• IN derive-pipeline-is-reproducible-and-defense-in-depth
  The derive pipeline achieves both reproducibility (deterministic sampling with fixed seeds and accurate budget allocation) and defense-in-depth at the application stage (validation-before-apply trust boundary with per-proposal error isolation), ensuring pipeline runs are repeatable and any surviving bad proposal cannot corrupt sibling proposals.
• OUT derive-pipeline-is-reproducible-and-fully-assured
  The derive pipeline achieves quadruple assurance: reproducibility (deterministic sampling with fixed seeds and accurate budget allocation), safety (fail-soft validation, Jaccard retraction guards, environment isolation), completeness (exhaustive exploration with guaranteed termination), and efficiency (O(N) budget accumulation with guaranteed floor) — four independently established properties reinforcing pipeline trustworthiness.
• IN derive-prompt-round-trippable
  `write_proposals_file` output can be parsed back by `parse_proposals` with no data loss, enabling a write-review-accept cycle where humans edit proposals in the same format the parser reads
• IN derive-prompt-roundtrips-through-parser
  The `### DERIVE` / `### GATE` format is a shared contract between `DERIVE_PROMPT` LLM output, `parse_proposals()` input, and `write_proposals_file()` output, forming a closed serialization loop
• OUT derive-quality-is-comprehensively-code-enforced
  All derive pipeline quality constraints — structural validation, retraction guards, environment isolation, format contracts, AND minimum-antecedent requirements — are enforced through code-level validation, ensuring no invalid proposals can reach the database regardless of LLM prompt compliance.
• IN derive-report-json-has-rounds-array
  The `reasons derive --auto --report-dir` command writes a JSON report containing a `rounds` array where each entry has `proposals_found` and `added` counts.
• IN derive-reports-survive-partial-runs
  `cmd_derive` and `cmd_review_beliefs` write partial JSON reports after each round/batch via `_write_derive_report`, so crash recovery is possible from the last completed step.
• IN derive-resilience-preserves-progress-on-error
  The derive pipeline is resilient to partial failures: partial results are persisted via JSON reports after each round, and error states are signaled through return codes (-1 for error, 0 for saturation, positive for progress) rather than exceptions, enabling callers to recover and resume.
• IN derive-retraction-guard-uses-jaccard
  `validate_proposals` rejects any proposed belief ID with Jaccard similarity >= 0.5 to an existing OUT node, preventing re-derivation of retracted beliefs
• IN derive-returns-negative-one-on-error
  `_derive_one_round` returns -1 on error, 0 on saturation, and a positive int for the number of beliefs added, which `cmd_derive` uses to control the exhaust loop.
• IN derive-round-returns-negative-on-error
  `_derive_one_round` returns -1 on error, 0 on saturation, and a positive count on success — using return values instead of exceptions for flow control in the exhaust loop.
• IN derive-strips-claudecode-env
  `_derive_one_round` explicitly removes the `CLAUDECODE` environment variable before spawning the model subprocess, preventing recursive Claude Code invocation.
• IN derive-unused-imports
  Dead code observation (`subprocess`, `sys`, `Path` imported but unused) — unstable detail that will change when cleaned up.
• IN derive-uses-subprocess-not-sdk
  The derive command invokes LLMs by shelling out to `claude` or `gemini` CLI binaries via `asyncio.create_subprocess_exec`, not through any Python SDK.
• IN derive-validate-before-apply
  `apply_proposals` trusts its input unconditionally; callers must run `validate_proposals` first or risk database errors from missing antecedents or duplicate IDs.
• IN derive-validate-blocks-retracted-rediscovery
  `validate_proposals` rejects any proposal whose ID has >= 50% Jaccard token overlap (tokenized on hyphens/colons) with an existing OUT belief, preventing re-derivation of previously retracted conclusions
• IN derive-validate-rejects-duplicate-ids
  `validate_proposals` rejects any proposal whose belief ID already exists in the network, preventing overwrites of existing beliefs through the derive pipeline.
• IN derive-validate-rejects-similar-to-out
  Covered by existing `derive-retraction-guard-uses-jaccard` which captures the same invariant
• IN migrated-retraction-derive-pipeline-is-exhaustive-and-terminating-j0
  Invalid: cycle guard in _get_depth != termination of exhaust loop (defeats derive-pipeline-is-exhaustive-and-terminating justification 0)
• IN migrated-retraction-derive-pipeline-is-production-ready-j0
  review-beliefs: The claim asserts the pipeline "correctly allocates budgets" but neither antecedent establishes budget allocation correctness — the defensive antecedent covers validation and the prompt antecedent covers serialization format. (defeats derive-pipeline-is-production-ready justification 0)