feat: always-on RDFS entailment for SHACL and policy enforcement

[bplatz]

Adds always-on RDFS entailment (subclass + subproperty) to SHACL and policy enforcement, matching what query reasoning already did — a Manager-typed record no longer slips past an Employee-targeting shape or an f:onClass ex:Employee policy. Built on the validate branch; richer entailment regimes (OWL modes) stay opt-in future work behind the same seam.

The bug this fixes

Commit-time SHACL expanded sh:targetClass over subclasses using snapshot.schema_hierarchy() — frozen at the last index build. Any rdfs:subClassOf committed since reindex was invisible to enforcement, so subclass-typed records skipped their shapes. Policy targeting had no entailment at all.

Mechanism: epoch counters + shared caches (zero cost on the common path)

Two counters on Novelty, bumped inside the per-flake routing loop apply_commit already runs (one integer compare per flake, same pattern as the existing f:reifies* check):

• schema_epoch — bumps only when a commit asserts/retracts rdfs:subClassOf / rdfs:subPropertyOf.
• shacl_epoch — bumps only on SHACL-affecting flakes (any sh:* predicate, or rdf:type edges to SHACL types / rdfs:Class / owl:Class).

Two Arc-shared caches on LedgerState, carried across commits:

• SchemaHierarchyCache (core) — the current subclass/subproperty closure, keyed by (indexed schema t, schema_epoch); rebuilt lazily (two bound-predicate scans) only after a schema-touching commit. Consumed by transaction SHACL, the validate façade, and policy-context construction.
• Compiled-SHACL slot (type-erased on the ledger crate, following the TypeErasedStore precedent) — data-only transactions reuse the previous transaction's compiled shapes via Arc<ShaclCache> and skip ShapeCompiler's ~40 predicate scans entirely. Any shape/schema change or f:shapesSource re-point recompiles; inline opts.shapes and cross-ledger wires bypass.

What entails now

• SHACL targets: sh:targetClass fires for subclass instances (current hierarchy, not index-time); sh:targetSubjectsOf / targetObjectsOf match subjects/objects of subproperties.
• SHACL paths: a constraint on sh:path schema:name governs values asserted via any subproperty — through the simple-predicate fast paths, sequence/inverse/alternative/transitive steps, and pair-constraint target loads. (This exposed a wiring gap: the staged-validation engine was rebuilt hierarchy-less across the transact crate boundary; validate_view_with_shacl now receives the shared Arc<ShaclCache> + hierarchy, which also removes a per-transaction deep clone of the compiled shapes.)
• Policy: f:onClass policies govern subclass instances, f:onProperty policies govern subproperties — expanded once at policy-set build time, so evaluation is untouched.
• Cross-ledger ontologies: when f:reasoningDefaults / f:schemaSource points at a model ledger, its subclass/subproperty edges merge into both SHACL and policy enforcement. Resolution is t-cached in the existing GovernanceCache — an unchanged model head is one nameservice t-read plus an Arc clone, never a re-query.

Semantics rule (deliberate)

Enforcement uses the committed hierarchy only: schema asserted in the same transaction as data does not entail for that transaction (pinned by test). The workaround is the natural one — two transactions, schema first — and matches how shape compilation already behaves.

Tests

Each behavior is pinned end-to-end: the unindexed-subclass rejection repro, the same-transaction rule, compile-cache invalidation on new shapes, policy subclass/subproperty governance (both directions fail without the change), SHACL subproperty paths and predicate targets, and two-ledger topologies for the cross-ledger cases (shape rejection at transaction time; policy visibility on the query path). Docs updated in the SHACL cookbook and policy model.

[aaj3f]

This is nice and nice to get SHACL working w/ ontology characteristics 👍

[aaj3f]

I originally thought the perf-hit I'm about to describe scaled w/ instance data size, but it's actually bound by schema size, so it's a bit more minor than I thought, but I'll include the note anyway (corrected for schema-bounds not instance-bounds), but it's way more minor than I originally thought:

Every policy-enforced query now recomputes the current schema hierarchy here, unconditionally and without the epoch cache. compute_schema_hierarchy_with_overlay clones snapshot.schema (IndexSchema.pred.vals — one entry per predicate/class), builds a HashMap over all of it, and sorts — O(ontology size) allocations plus two bound-predicate range scans, on the per-query policy path. The tx path routes through the epoch-invalidated SchemaHierarchyCache::current(...) (tx.rs:671, validate.rs:434), and that cache is warm across commits (finalize_state_with_base, commit.rs:910); this read path does not use it, because build_policy_context_from_opts_inner operates on &LedgerSnapshot/&dyn OverlayProvider and never receives the LedgerState cache handle. Pre-PR, build_policy_set did zero hierarchy work.

Why minor, not major (verification): the cost is bounded by ontology size, not instance-data size, and this same function already runs a novelty-aware assemble_full_stats per query (policy_builder.rs:356-365) — the whole PolicyContext is rebuilt per query and uncached, so the hierarchy is one more comparable-magnitude step, not a newly-expensive path. The tx-caches/read-doesn't contrast is also imperfect: the cross-ledger tx branch (tx.rs:662-668) recomputes uncached too. Real and worth fixing, but not merge-blocking. Two independent mitigations, the first one is the high-value one:

1. Skip the computation when no restriction can use it (identity-only / default-allow / OnSubject policies pay nothing):

   let needs_hierarchy = restrictions.iter().any(|r| {
       !r.for_classes.is_empty() || r.target_mode == TargetMode::OnProperty
   });
   let hierarchy = if !needs_hierarchy {
       None
   } else {
       match &cross_ledger_schema { /* existing match */ }
   };

2. For the class/property case, thread the ledger's Arc<SchemaHierarchyCache> into this builder (add it to GraphDb and pass it down like tx.rs does) so repeated policy queries reuse one entry instead of rebuilding per call. As written, a large-ontology ledger pays a full schema clone + sort on every governed read.

[bplatz]

Addressed mitigation #1 in 64699d8: the hierarchy computation is now guarded on a needs_hierarchy check (any restriction with for_classes non-empty or target_mode == OnProperty), so identity-only / default-allow / OnSubject policies skip it entirely. Left mitigation #2 (threading the ledger's SchemaHierarchyCache into this read path) as a follow-up — it's the larger plumbing change and only matters for large-ontology ledgers under governed read load.

[aaj3f]

resolve_cross_ledger_schema_for_tx re-runs resolve_ledger_config (config-graph type scan + parse) even though resolve_cross_ledger_shapes_for_tx (L839) loaded the identical config one line earlier. On any config-bearing ledger this doubles config resolution per transaction. The empty-config guard makes it free on plain ledgers, but for configured ledgers it is redundant work on the write path. Suggest resolving the config once in stage_with_config_shacl and passing &config (or Option<&LedgerConfig>) into both resolvers.

// resolve config once, then:
let cross_ledger_shapes = resolve_cross_ledger_shapes_for_tx(&ledger, &config, resolve_ctx).await?;
let cross_ledger_schema = resolve_cross_ledger_schema_for_tx(&ledger, &config, resolve_ctx).await?;

[bplatz]

Addressed in 17ae7eb