access-control
41 beliefs (30 IN, 11 OUT)
The access-control topic covers how the belief network restricts visibility of nodes to authorized callers and how source integrity ensures the underlying data remains trustworthy. This matters because a shared knowledge base holding beliefs with different sensitivity levels needs fine-grained, principled controls over who sees what, without sacrificing the ability to write and maintain beliefs freely.
The core mechanism is a transitive subset gate (access-control-is-transitive-subset-gated, access-tags-subset-gate). Each node may carry access_tags in its metadata, and a caller's visible_to set must be a superset of those tags for the node to be visible — partial overlap is not enough (visibility-is-subset-check, visible-to-superset-semantics). Nodes without any access_tags are unconditionally public (untagged-always-visible, untagged-nodes-always-visible). When nodes are derived, their access_tags are computed as the sorted, deduplicated union of all ancestor tags across all justification chains, including through diamond dependencies (access-tags-union-inheritance, tag-inheritance-is-transitive-union). This propagation is dynamic: adding a new justification triggers a BFS cascade that recomputes tags on all downstream dependents (tag-propagation-is-dynamic). Enforcement happens exclusively at read boundaries — show_node, explain_node, and trace_assumptions raise PermissionError when the caller lacks sufficient tags (access-control-enforced-at-read-not-write, pg-access-control-raises-permission-error) — while write operations like add_node and retract_node are unrestricted. The visible_to parameter itself is optional; when absent, no filtering is applied (visible-to-is-optional-filter). A practical consequence is that list_gated omits superseded nodes even if they still have active blockers, keeping the blocker view clean (api-superseded-nodes-excluded-from-gated).
A substantial portion of this topic addresses source integrity — how the system tracks whether the external documents backing beliefs have changed on disk. Source references use a repo-alias/relative-path convention decoupled from absolute filesystem paths (source-path-format, source-paths-use-repo-alias-prefix), and resolution returns None rather than raising on missing files (source-resolution-is-convention-based-and-fail-safe). Integrity tracking uses full 64-character SHA-256 digests with additive backfill that never overwrites existing hashes (source-tracking-is-collision-resistant-and-safe), and a legacy 16-character truncated hash is recognized and optionally upgraded (truncated-hash-threshold-is-16-chars, truncated-hash-upgrade-opt-in). The pipeline from hashing through staleness detection is end-to-end fail-safe, with CI-ready nonzero exit codes when drift is found (source-pipeline-is-end-to-end-fail-safe, source-integrity-spans-hashing-through-detection). Source integrity and lifecycle governance form a closed, self-reinforcing loop: source integrity grounds governance decisions, while governance ensures no source verification gap exists (source-integrity-and-governance-form-closed-loop), and this loop is itself dually grounded in two independent evaluation chains (source-integrity-loop-is-dually-grounded, source-governance-loop-is-dually-grounded-and-deterministic).
A number of higher-level derived beliefs about information governance are currently OUT, including claims about end-to-end authorization-and-budget control (information-flow-is-authorization-and-budget-controlled), bidirectional information flow control (information-flow-is-controlled-in-both-directions), tripartite operational assurance (source-grounded-correction-has-tripartite-assurance), and the overarching claim that egress is simultaneously resilient, governed, and self-correcting (egress-is-resilient-governed-and-self-correcting). Their retraction suggests that these broad synthesizing claims — which attempted to unify access control, token budgets, determinism, and self-correction into single composite guarantees — have been found to overreach or depend on antecedents that no longer hold. The more concrete, mechanistic beliefs about how subset gating works, how tags propagate, and how source hashes are computed and checked all remain IN, indicating that the foundational access-control machinery is well-established while the grand unifying narratives built atop it have been retracted.
-
IN
access-control-enforced-at-read-not-write
Access control (`_is_visible`) is enforced at read/query boundaries (`show_node`, `explain_node`, `trace_assumptions`) via `PermissionError`, but write operations (`add_node`, `retract_node`, `assert_node`) do not check visibility. -
IN
access-control-is-transitive-subset-gated
Access control enforces transitive subset-based authorization: visibility requires the caller's tags to be a superset of the node's tags, derived nodes inherit the sorted union of all ancestor tags transitively, and enforcement occurs at read boundaries only — write operations are unrestricted. -
IN
access-tags-subset-gate
A tagged node is visible only when its `access_tags` are a subset of the caller's `visible_to` set; partial overlap (intersection without containment) is insufficient for access. -
IN
access-tags-union-inheritance
A derived node's `access_tags` is the sorted, deduplicated union of all antecedent tags across all justifications, merged with any explicit tags on the node itself. -
IN
api-superseded-nodes-excluded-from-gated
`list_gated()` omits nodes that have been superseded via `api.supersede()`, even if they still have active blockers — stale conclusions don't pollute the blocker view. -
IN
api-visible-to-filters-both-result-and-prompt
Already exists as `api-visible-to-filters-both-result-and-prompt` -
OUT
egress-is-resilient-governed-and-self-correcting
All information leaving the system is simultaneously resilient (queries degrade gracefully across all access paths with deterministic output), governed (authorized, budget-constrained, and CI-ready), and serves a self-correcting knowledge base — the system's complete information egress is both trustworthy and operationally sustainable. -
OUT
information-boundaries-are-controlled-at-all-levels
The system controls information flow at every boundary: internally through access-tag authorization gating and token-budget constraints on output, and externally through bidirectional bounds on LLM input/output quality and defensive belief ingestion pipelines -
OUT
information-flow-is-authorization-and-budget-controlled
Information flow from the belief network is controlled along two independent dimensions: access tags gate which beliefs are visible to each caller (authorization control via transitive subset checks), while token budgets constrain how much of the visible network is emitted (volume control via priority-ordered truncation). -
OUT
information-flow-is-controlled-in-both-directions
Information flow is controlled at every system boundary: inbound data passes through production-hardened LLM integration (bounded execution, fail-soft handling, process isolation) and boundary-controlled information isolation (access tags, namespace partitioning), while outbound data is deterministic, authorized via transitive subset-gated access control, and budget-constrained — no uncontrolled data enters or leaves the belief network -
OUT
information-governance-is-end-to-end-authorized-and-resource-constrained
Information governance is enforced end-to-end from pipeline-level resource management through output-level authorization: the pipeline is resource-governed through accurate bidirectional token budgets and access-controlled through transitive subset-gated tags, while the output layer adds deterministic authorized distillation through pure functions with fixed priority ordering — ensuring governance is not concentrated at a single chokepoint but layered across the complete information flow. -
OUT
information-output-is-authorized-budgeted-and-deterministic
Information leaving the belief network is controlled along three independent dimensions: authorization gating ensures callers see only beliefs their tags permit, token budgets constrain output quantity, and the compact module's pure-function deterministic priority ordering guarantees reproducible distillation — output is simultaneously access-controlled, size-bounded, and predictable. -
OUT
information-pipeline-is-resource-governed-and-access-controlled
The complete information pipeline is governed along two orthogonal axes: token budgets accurately constrain both input (proportional derive allocation) and output (compact distillation with budget enforcement), while access tags enforce transitive subset-based authorization at every read boundary — every piece of information is simultaneously resource-bounded and access-controlled. -
IN
pg-access-control-raises-permission-error
`PgApi.show_node()` raises `PermissionError` when called with a `visible_to` list that doesn't intersect the node's `access_tags`, enforcing per-node access control at the API boundary -
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. -
IN
source-governance-loop-is-dually-grounded-and-deterministic
The closed source-integrity-governance loop is both dually grounded (resting on two independent evaluation chains — purity and uniformity) and fully deterministic (governance determinism emerges from minimality through source integrity and is preserved by exception safety), achieving both epistemic independence and operational predictability from independent foundations -
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. -
OUT
source-integrity-grounds-lifecycle-self-correction
The system's lifecycle-spanning self-correction is concretely grounded in fail-safe source integrity: the end-to-end source pipeline (convention-based path resolution, collision-resistant SHA-256 hashing, comprehensive staleness detection, CI gating) provides the verification mechanism that makes maintenance-time self-correction practically achievable alongside creation-time exhaustive derivation. -
IN
source-integrity-is-deterministic-and-architecturally-grounded
The fail-safe source integrity pipeline — from convention-based path resolution through collision-resistant SHA-256 hashing to comprehensive staleness detection — operates within the same deterministic, architecturally-grounded lifecycle framework as all other system operations, ensuring source verification is both predictable and structurally safe. -
IN
source-integrity-is-fail-safe-deterministic-and-grounded
The source integrity pipeline achieves triple assurance from two independent chains: fail-safe operation (convention-based path resolution returning None on missing files, collision-resistant SHA-256 hashing with additive backfill, comprehensive staleness detection) combined with architectural determinism (grounded within clean layer boundaries ensuring predictable state trajectories). -
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-integrity-unifies-determinism-exception-safety-and-lifecycle
The source integrity pipeline achieves triple assurance from two independent chains: the source-to-TMS path is deterministic (convention-based resolution, collision-resistant SHA-256) and exception-safe (fail-safe across both TMS and source lifecycle domains), while lifecycle governance uses that same deterministic source integrity to drive staleness decisions and belief currency management — source integrity simultaneously serves pipeline correctness, failure recovery, and lifecycle governance. -
IN
source-lifecycle-is-fail-safe-and-gapless
The end-to-end fail-safe source integrity pipeline — from convention-based path resolution through collision-resistant SHA-256 hashing to comprehensive drift detection — feeds directly into gapless lifecycle management, ensuring every source material change on disk is detected, surfaced, and managed through the full belief lifecycle without gaps. -
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. -
IN
source-pipeline-is-end-to-end-fail-safe
The complete source integrity pipeline from path resolution through hash computation to staleness detection is end-to-end fail-safe: convention-based resolution returns None on missing files rather than raising exceptions, collision-resistant SHA-256 hashing backfills additively without overwriting, and staleness detection catches all drift with CI-ready exit codes — no stage in the pipeline raises exceptions on adverse conditions, and each stage's output gracefully feeds the next. -
IN
source-resolution-is-convention-based-and-fail-safe
Source path resolution follows a convention-based repo-alias/relative-path format and returns None on missing files rather than raising exceptions, providing safe path resolution for the staleness checking pipeline. -
IN
source-to-tms-integrity-is-deterministic-and-exception-safe
The complete integrity pipeline from source files through TMS truth maintenance is both deterministic (convention-based path resolution, collision-resistant SHA-256 hashing, uniform pure evaluation) and exception-safe (fail-safe source resolution, contradiction-triggered backtracking, challenge-to-justified recovery) — no failure in either source verification or truth maintenance can corrupt system state or produce unpredictable outcomes. -
IN
source-tracking-is-collision-resistant-and-safe
Source integrity tracking uses full 64-character SHA-256 digests with exact string comparison for collision resistance, and backfills hashes additively without overwriting existing values — ensuring high-fidelity drift detection with no accidental data loss -
IN
tag-inheritance-is-transitive-union
Derived nodes inherit the sorted union of all ancestor `access_tags`, propagating transitively through arbitrarily long justification chains including diamond dependencies. -
IN
tag-propagation-is-dynamic
Adding a justification to an existing node triggers access tag recomputation that cascades through all downstream dependents via BFS, not just at node creation time. -
IN
truncated-hash-threshold-is-16-chars
A stored `source_hash` of exactly 16 characters that is a prefix of the current full SHA-256 hash is classified as `truncated_hash` (legacy format), not `content_changed`. -
IN
truncated-hash-upgrade-opt-in
Prefix hash upgrade (16-char truncated SHA-256 to full digest) only occurs when `upgrade_hashes=True` is passed to `check_stale`; without it, truncated hashes produce a warning result with `reason="truncated_hash"`. -
IN
untagged-always-visible
Nodes with no `access_tags` key in metadata are never filtered by `visible_to` — they are treated as unconditionally public. -
IN
untagged-nodes-always-visible
Nodes without `access_tags` metadata pass all `visible_to` filters unconditionally and are never hidden by access control. -
IN
visibility-is-subset-check
`_is_visible` requires ALL of a node's `access_tags` to be present in the caller's `visible_to` list (subset check, not intersection); nodes with no tags are always visible. -
IN
visible-to-is-optional-filter
`_parse_visible_to` returns `None` when `--visible-to` is absent, which the API interprets as "no access restriction"; it never defaults to an empty list. -
IN
visible-to-superset-semantics
A node with `access_tags: ["finance", "hr"]` is only visible to callers whose `visible_to` list contains both tags (superset/subset check, not intersection).