derive-pipeline

62 beliefs (47 IN, 15 OUT)

• IN any-mode-creates-per-premise-justifications
  When `any_mode=True` and multiple antecedents are given, each antecedent gets its own SL justification (OR semantics: node is IN if *any* antecedent is IN), rather than the default single multi-antecedent justification (AND semantics).
• OUT any-mode-expansion-is-evaluation-invisible
  Any-mode expansion from conjunctive to disjunctive justifications is invisible to truth evaluation: the expanded justifications propagate completely through the same BFS mechanisms, and truth evaluation produces identical results regardless of whether justifications arrived via original specification or any-mode expansion — a consequence of transformation invariance.
• IN any-mode-expansion-propagates-completely
  When any_mode expands a conjunctive justification into per-premise disjunctive justifications, each resulting justification inherits the complete outlist specification (conjunction semantics, absence tolerance, persistence across save/load), and all resulting truth-value changes propagate completely to every affected dependent — but only when outlist nodes are tracked in the dependents index, ensuring outlist-mediated effects are not silently dropped.
• IN any-mode-is-structural-expansion
  Duplicates existing belief `any-mode-creates-per-premise-justifications` which already captures that any_mode expands N premises into N single-premise SL justifications.
• IN any-mode-outlist-preserved
  When `any_mode` expands `sl="a,b" unless="enemy"`, each resulting single-premise justification inherits `"enemy"` in its outlist.
• IN any-mode-preserves-full-outlist-semantics
  When any_mode expands a single multi-antecedent justification into per-premise justifications (OR semantics), each resulting justification preserves the original outlist entries — ensuring non-monotonic defeat works correctly under disjunctive expansion with no semantic loss.
• IN count-accumulates-linearly
  Documents the bug fix for issue #23 — already covered by existing `derive-agent-count-bug` which tracks this defect
• 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-complete-coverage
  The derive pipeline achieves complete coverage along three axes: safety (fail-soft validation, Jaccard retraction guards, environment isolation), completeness (exhaustive exploration with guaranteed termination), and production-readiness (accurate proportional budgets, roundtrippable prompt format).
• 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.
• OUT derive-pipeline-is-safe-and-complete
  The derive pipeline simultaneously provides safety (fail-soft validation, Jaccard retraction guards, environment isolation) and completeness (exhaustive exploration with guaranteed cycle-free termination), ensuring LLM-driven belief generation discovers all derivable conclusions without corruption risk.
• OUT derive-pipeline-is-safe-complete-and-efficient
  The derive pipeline simultaneously achieves safety (fail-soft validation with Jaccard retraction guards and environment isolation), completeness (exhaustive exploration with guaranteed termination via cycle guards), and efficiency (linear O(N) budget accumulation with a floor of 5 beliefs per agent preventing representation starvation).
• IN derive-prompt-is-deterministic-and-reproducible
  The derive pipeline's prompt construction is fully reproducible: deterministic sampling with fixed seeds selects consistent belief subsets, and accurate proportional budget allocation ensures each agent receives the same token share across runs.
• 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
• OUT derived-belief-pipeline-achieves-code-enforced-quality
  The derived belief pipeline — creation via defensive derivation with structural validation, Jaccard retraction guards, and environment isolation, followed by independent review with scope restricted to derived beliefs and mutation gated behind dry-run — achieves completely code-enforced quality assurance including logical soundness validation, only when inference soundness checking is implemented in code rather than relying solely on LLM prompt instructions.
• IN derived-belief-soundness-is-llm-only
  Structural validation ensures justification references exist and are IN, but the logical soundness of the inference from antecedents to derived conclusion is validated only by the proposing LLM — no code-level check verifies that the reasoning step is logically valid.
• IN exhaust-implies-auto
  In `_derive_one_round`, proposals are auto-applied when either `args.auto` or `args.exhaust` is true; the `--exhaust` flag does not require the user to also pass `--auto`.
• IN expert-pipeline-extracts-per-document
  The expert-agent-builder pipeline extracts beliefs per-document (summarize entire document → propose beliefs → record file path), not per-section — the connection between a belief and its source material is a file-level pointer, not a section-level one.
• OUT quality-lifecycle-is-complete-and-resource-efficient
  The complete LLM-driven quality lifecycle — creation via derive with defensive validation, classification via list-negative with batch scalability, and validation via review with read-only fault tolerance — operates within resource-efficient bounds spanning zero-dependency packaging through lazy-loading startup through bounded runtime execution, ensuring quality assurance scales sustainably with belief network size.
• OUT quality-lifecycle-is-fault-tolerant-and-resource-efficient
  The complete LLM-driven quality lifecycle — creation via derive, classification via list-negative, review, and self-correction — is simultaneously resource-efficient (accurate budgets, linear allocation, minimal footprint) and fault-tolerant at every phase (graceful degradation on LLM failures, batch fault isolation, deterministic fallbacks).
• OUT quality-lifecycle-operates-within-self-maintaining-trust
  The complete belief quality lifecycle — fault-tolerant creation, classification, review, and correction with resource-efficient operation — executes within trust boundaries that are both structurally enforced (zero external dependencies, defensive ingestion) and dynamically maintained (convergent self-correction preserving trust invariants), requiring no external trust infrastructure.
• IN sample-mode-is-deterministic
  `_build_beliefs_section` with `sample=True` and a fixed `seed` produces identical output across calls, enabling reproducible derive prompts