source
24 beliefs (19 IN, 5 OUT)
-
IN
ask-source-chunks-persist-across-tool-iterations
Source document content included in the initial ask prompt is re-included in all subsequent prompts after tool-call round-trips, ensuring the LLM retains source context across the entire multi-turn loop. -
IN
belief-source-metadata-is-file-level
Belief source tracking uses flat file-level pointers (source path + source_hash) with no structural awareness of where within a document the claim originated — section, page, or paragraph level provenance is not supported. -
IN
check-stale-detects-source-staleness-only
`check-stale` detects source staleness (source file changed on disk) via hash comparison but cannot detect world staleness (the belief is outdated even though the source file hasn't changed) — beliefs can silently decay without any artifact triggering re-examination. -
IN
check-stale-no-dedup-by-source-path
Multiple nodes referencing the same missing source file each produce independent `source_deleted` results — no deduplication by file path. -
IN
check-stale-requires-both-source-fields
A node must have both `source` (non-empty) and `source_hash` (non-empty) to be eligible for staleness checking; nodes missing either field are silently skipped. -
IN
check-stale-source-deleted-returns-none-hashes
When a source file is missing, `check_stale` returns a result dict with `reason="source_deleted"`, `new_hash=None`, and `source_path=None` (fix for issue #25 — previously this case was silently skipped). -
IN
governance-achieves-topology-and-source-completeness
Rich governance — deterministic, exception-safe, and source-grounded with topology-complete transitions — simultaneously achieves gap-free source coverage, ensuring governance completeness along two independent dimensions: propagation reach (every state change reaches all transitively dependent nodes) and integrity coverage (every source file is tracked with no silent gaps). -
IN
governance-determinism-is-minimality-emergent-through-source
Rich governance achieves end-to-end determinism spanning revision semantics through source integrity, and this determinism is itself an emergent consequence of unified minimality, completeness, and determinism rather than an independently-engineered property — the same minimal foundations that produce governance completeness also produce its end-to-end deterministic reach. -
OUT
integrity-is-boundary-and-source-agnostic
System integrity is enforced agnostically along two independent dimensions — across the internal/external boundary (local mutations vs. external ingestion) and across mutation sources (human dialectics, LLM derivation, agent import) — because the same atomic-deterministic pipeline processes all combinations without branching on origin or direction. -
OUT
missing-source-file-is-silent
If a node's source file no longer exists on disk, `check_stale` silently skips it; callers cannot distinguish "file deleted" from "file never tracked." -
IN
resolve-source-defaults-to-home-git
When no `repos` mapping is provided, `resolve_source_path` falls back to `~/git// ` by convention. -
IN
resolve-source-fallback-path
When no `repos` mapping is provided, `resolve_source_path` constructs paths as `~/git// ` by convention. -
IN
resolve-source-path-db-dir-precedence
`resolve_source_path` follows a strict precedence chain: `db_dir` resolution takes priority over agent repo resolution, which takes priority over repo-key-split resolution; missing files return `None`. -
IN
resolve-source-path-never-raises
`resolve_source_path` returns `None` for nonexistent files instead of raising exceptions; callers must check the `None` case. -
IN
resolve-source-path-returns-none-on-missing
`resolve_source_path` returns `None` (not an exception) when the resolved file does not exist on disk or when the source string is empty. -
IN
search-source-chunks-filters-stop-words
`_search_source_chunks` filters out single-character tokens and common stop words before constructing FTS5 queries, returning empty string when no usable terms remain. -
OUT
source-correction-achieves-resource-efficient-assurance
Source-grounded lifecycle correction with tripartite operational assurance — externally controlled, internally self-correcting, and query-resilient — achieves these guarantees within resource-efficient bounds spanning the full operational pipeline, ensuring correction mechanisms never exhaust the system's computational budget. -
OUT
source-grounded-correction-has-tripartite-assurance
The system's lifecycle self-correction — concretely grounded in fail-safe source integrity verification with governed output — operates within a tripartite assurance framework providing external control (bounded interfaces with defensive ingestion), internal self-correction (contradiction resolution and staleness detection), and query resilience (graceful degradation across all access paths). -
OUT
source-grounded-correction-produces-governed-output
The system's lifecycle self-correction — concretely grounded in fail-safe source integrity verification — feeds into a governed output pipeline that is authorized (access-tag gated), bounded (token-budget constrained), and CI-ready (deterministic with nonzero exit codes), ensuring that source-level drift detection translates into actionable, permission-respecting output -
IN
source-integrity-and-governance-form-closed-loop
Source integrity enables lifecycle governance by unifying determinism, exception safety, and lifecycle management into a single pipeline, while lifecycle governance achieves gap-free source coverage — forming a self-reinforcing closed loop where source integrity grounds the governance that in turn ensures no source verification gap exists. -
IN
source-integrity-loop-is-dually-grounded
The closed source-integrity-governance loop is itself dually grounded — the governance half of the loop rests on two independent semantic foundations (evaluation purity and edge-case uniformity), so the bidirectional feedback cycle between source integrity and lifecycle governance remains sound even if one grounding chain is weakened. -
IN
source-integrity-spans-hashing-through-detection
Source integrity forms a complete end-to-end pipeline with no gap between measurement and verification: collision-resistant SHA-256 hashing with additive backfill computes integrity markers without overwriting existing hashes, while comprehensive staleness detection with CI gating and nonzero exit codes consumes those markers to catch all source drift. -
IN
source-path-format
Source references use `"reponame/relative/path"` format; `resolve_source_path` splits on the first `/` to look up the repo key in a `repos: dict[str, Path]` mapping. -
IN
source-paths-use-repo-alias-prefix
Node source paths follow a `repo-alias/relative-path` convention where the first `/`-delimited segment is a key into the `repos` dict that maps aliases to filesystem roots, decoupling belief source references from absolute paths.