Portal Governance And Operations

Purpose

This functional area gives operators visibility into how the platform is being used and whether governed execution is behaving as expected.

It is the primary operational cockpit for monitoring, investigation, and oversight.

Main Capabilities

• governance summary dashboards
• audit record listing and filtering
• audit record detail inspection with payload data
• runtime call listing and filtering
• end-to-end call trace viewing with per-step timing
• enrichment run monitoring with real-time progress
• external audit target management with delivery statistics
• real-time portal notifications

Governance Dashboards

The Portal provides summary views that help operators understand platform behavior over time.

Functionally these dashboards expose:

• total event counts grouped by status (Allowed, Denied, Error)
• unique actor count across the selected time window
• activity trend over the last 14 days broken down by day and outcome
• top 5 audit categories by event volume
• top 5 audit actions by event volume
• top tenant distribution by event volume

These views support rapid operational awareness and anomaly detection without requiring raw log queries.

Audit Records

The platform records audit events that can be reviewed in the Portal.

Operators can:

• list audit records with pagination
• filter by tenant, category, action, status, actor, subject, path, method, time range, and correlation ID
• inspect individual records in detail

When inspecting an individual record, the full structured dimension data is available. This includes step-specific information such as matched policy, mapping name, tool name, downstream endpoint, execution timing, and when request/response logging is enabled, the captured payload data.

Runtime Call Monitoring

The Portal lets administrators inspect runtime calls from an execution perspective.

Supported views include:

• paginated call listings with correlation ID, tool name, mapping name, caller subject, call type, and overall status
• filtering by tenant, subject, status, and time range
• trace retrieval by correlation ID

The call type distinguishes between invoke calls (tool executions) and list calls (tool catalog requests). The overall status for a call is derived as the most severe outcome across all steps in the correlation group.

Additional call types are also surfaced when present:

• resource for MCP resource reads such as toolset system-prompt resources
• schema for schema discovery activity

Call Trace

When a specific call is selected by correlation ID, the Portal presents a full execution trace.

The trace includes:

• correlation ID
• tenant ID and display name
• tool name and mapping name
• caller subject ID, client application ID, client application display name
• caller IP address when captured
• overall status
• start timestamp and total duration in milliseconds
• ordered list of pipeline steps, each with action name, status, timestamp, step duration in milliseconds, and dimension data

When request/response payload logging is enabled for the invoked tool, the step dimensions for the relevant steps contain the sanitized request and response payloads.

Payload detail can include:

• MCP request and response payloads
• downstream HTTP or SOAP request and response captures
• sanitized query parameters, headers, SOAP security headers, and credential-derived values

Enrichment Monitoring

Semantic enrichment operations are monitored through a dedicated enrichment dashboard.

The dashboard shows a paginated list of enrichment runs. Each run is a top-level record corresponding to one enrichment request submitted by an operator.

While a run is still active, the dashboard combines persisted run data with transient real-time progress updates so operators can see chunk progress before the final record is complete.

Operators can filter runs by:

• tenant
• mapping
• status (Requested, Processing, Completed, Failed)
• provider
• time range

Each run in the list shows:

• request timestamp
• status badge
• chunk progress bar with processed and total item counts
• provider and model
• mapping name
• endpoint suggestion count
• field suggestion count
• warning count
• failed chunk count
• cumulative input, output, and total token counts
• total duration

Opening a run detail view shows the full run record including provider, model, correlation ID, all timestamps, aggregate suggestion and warning counts, a run progress indicator, and an ordered list of chunk activity.

Each chunk entry in the detail view captures one LLM call within the run. It shows:

• pass kind (MappingOverview for the metadata pass, or the chunk identifier for operation chunks)
• chunk position within the run
• provider and model
• status and outcome
• prompt character count and response character count
• endpoint and field suggestion counts
• warning and retry counts
• input, output, and total token counts
• duration
• the full system prompt, user prompt, and raw LLM output

This brings AI-assisted mapping work under normal governance visibility with the same depth of traceability that audit records provide for runtime calls.

Real-time progress events are used only to keep the dashboard current while a run is active. The final persisted run record remains the source of truth for historical review.

Audit Delivery Settings

Governance events can be fanned out to external systems for long-term compliance storage. The Portal provides a dedicated Audit Delivery Settings page under the Governance menu for managing these targets.

The page is accessible to users with the Governance Manage role. Tenant-scoped users can view and manage tenant-scoped targets but cannot create, edit, or delete global targets.

Target Kinds

Four delivery protocols are supported:

• REST Endpoint — HTTP POST to a webhook URL. The request body is rendered from a configurable Mustache-style template. Optional bearer token or API key authentication. Header and query string mappings allow additional metadata to be injected per request.
• SQL Server — INSERT into an operator-managed SQL Server audit table. The base connection string is supplied in plain text; credentials are provided as separate Username Secret and Password Secret references injected at delivery time. Supports AppendOnly, LedgerTable, and TriggerProtected immutability modes.
• PostgreSQL — Same semantics as SQL Server on PostgreSQL, defaulting to TriggerProtected immutability mode. Separate credential secrets follow the same pattern.
• Syslog — RFC 5424 structured messages over UDP, TCP, or TLS. Structured data fields and property mappings are fully configurable.

Schema-Driven Configuration

Each target kind defines its own parameter schema. The Portal renders the correct form fields automatically when a kind is selected — no hardcoded forms per provider. Adding a new target kind in the backend only requires adding its schema definition in the frontend schema registry.

Scope And Tenant Limits

A target with an empty allowed-tenant list is global and receives events from all tenants. A target with one or more allowed tenant IDs is tenant-scoped and receives only those tenants' events.

Tenant-scoped operational (UI-managed) targets are limited to 3 per tenant. Deployment-managed targets do not count against this limit.

Delivery Testing

Operators can test any target using the Test action in the grid:

• Direct test — sends a synthetic Information audit event straight to the provider and returns the result inline in the modal. Use this to verify connectivity and configuration.
• Queue test — enqueues the synthetic event into the standard audit pipeline and routes it only to the selected target. Use this to validate the full Jobs Worker delivery path.

Database Table Provisioning

For SQL Server and PostgreSQL targets, the View panel provides the CREATE TABLE script for the configured schema and table name. This can be copied and executed by a DBA when Auto-create Schema is disabled (the recommended setting for production compliance targets where schema changes must be controlled).

Deployment-Managed Targets

Targets defined in environment configuration files (compliance targets) appear in the list as read-only with a Deployment-managed badge. Their parameters and scope cannot be modified through the Portal.

Delivery Statistics And Health

The grid shows per-target health state (Healthy, Degraded, Critical), pending delivery count, and failed delivery count. Opening the View panel reveals full delivery statistics including retrying and succeeded counts, plus complete configuration detail.

The Monitoring Dashboard shows a summary health card for audit delivery with a direct link to the full settings page.

Outbound Host Allowlist Requirement

REST endpoint URLs must be registered in the Outbound Host Allowlist (Security → Outbound Allowlist) before the Jobs Worker will contact them. Deliveries to unregistered hosts fail with a connectivity error at the network boundary.

Notifications

The Portal includes real-time notifications for important operational events.

Users can:

• list notifications
• mark notifications as read
• mark all notifications as read
• dismiss notifications

For semantic enrichment specifically, users also receive live progress updates while runs are active and completion notifications when enrichment finishes.

This supports day-to-day operator awareness without requiring users to constantly poll dashboards.

Operational Importance

This area is what turns the platform from a configuration tool into a governable operational system.