The credential and scoping core, shared by polyc-control-plane's forensics authorization funnel and the standalone Query plane polyc-query-service composes.

Why this crate exists (Epic 1565, chunk 10C-1)

Two entry paths need credential verification and scope derivation: polyc-control-plane's forensics conversation-read funnel, which needs an authorization verdict and never a runnable engine session, and the standalone Query service, which verifies a presented credential at its own boundary. They must not be two implementations — a change that landed on one and missed the other would be an authorization difference reachable from exactly one surface, the hardest kind to notice in review. Before this crate existed, both reached that one mechanism only by depending on polyc-query, which at the time also linked the embedded DataFusion engine — so polyc-control-plane could not stop linking the engine (POLY-359) without losing the credential mechanism too. The embedded engine itself is deleted now (POLY-196); this crate still holds exactly the DataFusion-free half: grant verification, the verified [principal::Principal] types, and the current-participation check a scope derivation performs. Building a runnable query session from a derived scope stays in polyc-query, next to the projected read path it feeds.

The seal

[principal::Scoping], every [principal::Principal] variant's inner type, and [credential::CredentialWitness] have no public constructor, no Default, and no public From in a production build. The only way to obtain one is through [credential::CredentialAuthority]'s own verifying methods. See [principal]'s module doc for the full seal design, including the test-util-gated escape hatches polyc-query's own test fixtures need, and this crate's tests/compile-fail/sealed_construction.rs for the compile-time proof.