Complete governed reporting execution and publication

This commit is contained in:
2026-08-04 02:23:24 +02:00
parent a81151391b
commit 8337aec19a
29 changed files with 3611 additions and 81 deletions
+30
View File
@@ -14,12 +14,28 @@ existing parent revision. Editing creates a new immutable revision and
requires the currently observed revision number. Existing runs continue to
reference the historical revisions they used.
Each definition also records system, tenant, group, or user governance scope,
whether it is inherited, and whether lower scopes may run, reuse, or automate
it. A child may tighten but never broaden any effective ancestor limit. System
definitions require system governance permission; tenant definitions are bound
to the active tenant; group and user definitions require the matching subject
unless a Reporting administrator performs the operation. Policy is consulted
for view, edit, run, reuse, and automation decisions.
Datasets may bind a static fixture, a pinned Dataflow output, or a capability
published by a source-owning module. Do not expose another module's ORM or an
unbounded SQL connection as a report source. Configure an explicit schema,
freshness policy, source fingerprint expectations, purpose, privacy,
retention, and a row-policy provider where source access alone is not enough.
On PostgreSQL installations, Reporting compiles bounded semantic filters,
grouping, measures, calculated measures, ordering, offsets, and limits into a
parameterized PostgreSQL plan over the already authorized provider rows. Field
paths and values are bound parameters and result limits remain mandatory. Pivot
plans retain the safe provider-neutral engine fallback. SQLite development and
other database engines use the same typed semantics through the bounded runtime
engine.
## Access and publication
Tenant-visible definitions are readable by principals with Reporting read
@@ -32,6 +48,20 @@ the Reporting publication-target contract. The target receives one immutable
execution payload and an idempotency key. It must return bounded evidence and
must not expose credentials in that evidence.
Reporting ships two optional adapters. `reporting.publication.files` calls
`files.artifact_store` and stores an idempotent managed artifact with execution,
revision, output-hash, and file-version evidence. `reporting.publication.mail`
calls `mail.notificationDelivery` and submits an idempotent report notice to the
Mail outbox. The latter does not bypass Mail profile, credential, or transport
policy. Adapter availability is evaluated at runtime, so Reporting remains
usable with neither Files nor Mail installed.
Drill contexts expire after 20 minutes, are bound to the creating account, store
only token and context hashes, and must match the original execution output and
source fingerprints. Resolution re-runs definition and row-level authorization.
Treat a fingerprint mismatch as a required report rerun, not as a recoverable
client warning.
## Cross-module provider governance
Source modules register `reporting.report_provider.<provider-id>` capabilities;