PALO stack and PolicyWatcher impact graph

Status: additive architecture and query preview 0.1.0, 5 September 2026. This extension connects technical dependencies to scoped governance reviews. It builds on the released PALO 3.1 semantic foundation without rewriting that release or changing the production boundary of PALO-AI.

An operational consumer is now implemented separately as Policy impact runtime 0.2.0. It adds persistent inventory revisions, validated polling of native PolicyWatcher signals and evidence packets, authenticated mapping and applicability reviews, and append-only gate decisions. The Explorer below remains a fictional snapshot preview; the operational workspace uses its own private database and authentication.

Explore the implementation#

Open Stack & policy impact. The existing Explorer now has three views: Workflow, Navigation, and Stack & impact. The new view includes a graph, accessible layer and relationship tables, and a read-only impact query over two fictional snapshots.

Choose Change detected to see two affected AI systems and their existing controls, gates and evidence. The independent analytics system is excluded because it uses a different service. Choose After illustrative owner review to see an additional applicability assessment and a hold decision for the support case. The earlier decision remains available. Case scope limits both the affected systems and their governance records.

The examples do not report actual provider changes. They use example.com, fictional systems and a fictional owner. No browser input, case record or query is submitted to PolicyWatcher. This implementation queries supplied snapshots; it does not implement live synchronization, authenticated review, gate mutation or runtime enforcement.

Updated architecture#

The numbering preserves the reference illustration for comparison. It is a capability map, not a mandatory execution sequence. Evaluation and governance operate across layers. A component can provide several capabilities, and a capability can belong to several layers. Conversational memory and governance evidence have different retention, integrity and authority requirements.

Contracts and ownership#

The graph reuses GovernanceCase, ControlImplementation, EvidenceArtifact, EvidenceClaim, EvidenceEvaluation, GateInstance and GateDecisionRecord. Graph nodes are projections of records, not replacement contracts. The example decision nodes embed records valid against palo-gate-decision-record.schema.json; their inputs and digest chain are available in gate-decisions.json.

PublicPolicy, RequirementVersion and executable policy rules remain distinct. A requirement declares whether it is a law, standard, internal rule or contractual term. A provider's public statement cannot create a legal-applicability decision by itself.

Identity, time and cardinality#

Node and relationship IDs are unique within one tenant snapshot. Edges resolve to typed endpoints and declare their mapping basis, source references, review state and evidence references. accepted means an accepted mapping assertion within the supplied snapshot; it does not authenticate a reviewer or confer execution authority.

validFrom and optional validTo define a half-open validity interval. recordedAt states when the assertion became known. Queries take asOf and knownAt separately, so future knowledge is excluded from historical queries. knownAt cannot exceed the available snapshot time. A new correction is represented by a new snapshot/record rather than overwriting an immutable decision.

Required relationships:

• A compared change has exactly one FROM_VERSION and one distinct TO_VERSION belonging to the same public policy. A baseline has one target version and no prior version.
• Each applicability assessment has one signal, one system version and one case, together with purpose, jurisdictions and rationale. A concluded assessment also requires a reviewer.
• A control implementation belongs to one case, implements one control definition and applies to at least one system governed by that case.
• A gate belongs to one case and reviews one or more system versions in that case.
• A decision has one gate and one actor. Sequence numbers and SUPERSEDES preserve decision history. A conditional decision requires recorded conditions.
• An evidence claim uses one artifact and supports one target. Evaluations remain separate entities. Neither a claim nor its similarity to another document constitutes verified evidence.

The JSON validator enforces endpoint types, temporal metadata, cardinality, case boundaries, reviewer requirements and decision history. The supplied RDF and SHACL are portable profiles; this extension's check parses them and runs its operational invariants over JSON. It does not claim full SHACL-engine validation or a live RDF database. The JSON-LD context describes vocabulary terms; the graph-envelope JSON is not automatically an RDF serialization.

Impact query#

npm run impact:query
npm run impact:query -- --case case-support
npm run impact:query -- --graph examples/policy-impact/reviewed-dependency-graph.json --signal signal-demo-retention --at 2026-09-05T09:30:00Z --tenant tenant-fictional-demo

For an actual snapshot, supply the graph path, exact signal ID, time and tenant explicitly. Preserve the complete existing palo-policywatcher-signal object in the ChangeSignal node. Add exact policy-version identifiers and source-to-service mapping records; provider names, topical similarity and confidence scores are insufficient bindings.

The query starts at accepted, current AFFECTS_SERVICE mappings, then follows reverse technical dependencies: DEPENDS_ON, USES_SERVICE, USES_MODEL, CALLS_TOOL and READS. It returns one witness path per reachable system, the relevant cases, control implementations, gates, existing decisions, applicability assessments and evidence to revisit. Provisional mappings are excluded and reported as incomplete coverage.

The read-only profile accepts at most 10,000 nodes and 50,000 edges, with a 128-relationship traversal depth. Reaching the depth limit produces a warning. The tenant parameter checks snapshot consistency; a service exposing this function must bind it to authenticated tenant identity and enforce storage access separately.

Results remain review-required. unmapped, source-versions-unavailable, signal-unavailable-at-query-time, baseline-established and no-mapped-system-in-scope describe distinct information states. None means compliant, approved, unaffected or safe to deploy. There is no automatic control rewrite, gate reopening, capability revocation or legal finding.

Generate and verify#

npm run stack:generate
npm run stack:check
npm run stack:test
npm run validate
npm run build

The generator derives the Explorer asset, RDF vocabulary, context, SHACL profile, ER diagram and extension manifest from the model. Generated files are checked for exactness. The example suite covers indirect dependencies, unrelated services, case scope, valid time and knowledge time, expired and proposed mappings, baselines, cycles, malformed graphs and preserved decision history.

The separate operational runtime implements authenticated inventory import and a review workflow that writes canonical decisions. Organization-specific inventory sources, identity-provider configuration and deployment admission remain explicit integration work. PALO-AI production readiness remains governed by its existing production profile.