Current supported implementation
Conditions do not contain provider queries. Each validated condition owns an observation domain, comparator-specific predicate, and evidence-use policy. Separate acquisition bindings prove that one exact operation projects into that domain.
The initial runtime implements four acquisition channels:
- hostile caller submission admitted under authenticated or explicit embedded authority context;
- named time authorities with explicit revision, interval, resolution, and uncertainty;
- immutable startup-captured environment snapshots over explicit allowlists;
- capability-rooted strict JSON/YAML documents selected by whole-document or validated RFC 6901 JSON Pointer projection.
The bounded local-acquisition authorities live inside decision-gate-core so
their source-witness constructors and sealed evidence types share one Rust
privacy boundary. They are not generic plugins or a network-provider registry.
decision-gate-mcp constructs one immutable coordinator from validated
configuration. Completion order is not semantic authority; results are keyed
and canonically assembled before policy admission.
Authority decomposition
ValidatedScenarioLaw
owns condition definitions, binding relations, policies, and limits
Local source authority
owns one named time/environment/document source and revision
Acquisition constructor
validates hostile source material and mints a source-specific candidate
Evidence admission
proves exact condition scope and evidence-use-policy satisfaction
Pure evaluator
consumes only the canonical admitted-evidence snapshot
Source registry or cache presence is never evidence authority. A missing, revoked, unavailable, or failed local source produces an operational failure and mints no semantic evidence.
Removed runtime families
HTTP/REST evidence acquisition, typed-network execution, remote MCP evidence acquisition, MCP stdio/subprocess execution, arbitrary native/executable providers, dynamic provider schemas, and remote evaluation workers are absent from runtime configuration, scenario syntax, tool schemas, CLI paths, and supported capability manifests. They have no placeholder variant or disabled toggle.
PF-08 alone may introduce a future family after closing its mathematical source law, exact witness, threat model, capability manifest, and qualification. A future large provider catalog would require immutable contract/schema catalogs and lazy exact-revision loading; it must not restore provider-coupled conditions or put arbitrary executable code in the DG process.
Current gaps and nonclaims
- Local acquisition is implemented but not yet product/release qualified.
- Diagnostic benchmarks prove neither launch throughput nor qualified deployment-wide node-population capacity.
- A local observation records what the named source returned; it does not prove metaphysical world truth.
- PF-04 owns and implements accepted-run ordering and local durability after a candidate evaluation has been derived; this provider architecture neither reimplements nor weakens that authority.