AI API Mapper
Technical walkthrough →
Technical walkthrough →
/ docs · functional specification

The full platform
functional reference.

Every functional area of AI API Mapper documented at implementation depth so architects, security reviewers, and platform engineers can evaluate the product with real technical context.

Portal · Governance & operations
On this page

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

The Activity over time chart plots all four outcomes — Total, Allowed, Denied, and Error — on one shared count axis, with a crosshair and tooltip giving the exact figures for a hovered day. Allowed is the events that were neither denied nor errored, the same derivation the summary cards use.

Series colours carry the same meaning as the outcome badges (allowed green, denied red, error amber) and are stepped separately for the light and dark themes so every line clears a 3:1 contrast against the panel it is drawn on. Because red and green are hard to separate for red-green colour blindness, each series additionally carries its own dash pattern and marker shape, repeated in the legend — the chart never relies on colour alone to tell one outcome from another.

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, execution ID, and external 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 execution ID, external correlation ID, tool name, mapping name, caller subject, call type, and overall status
  • filtering by tenant, subject, external correlation ID, status, and time range
  • trace retrieval by execution 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 execution ID, the Portal presents a full execution trace.

The trace includes:

  • execution ID
  • external correlation ID, when the caller supplied one
  • 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 (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. Connection details are configured per target, with credentials supplied as separate secret references rather than embedded in the connection string. Supports AppendOnly, LedgerTable, and TriggerProtected immutability modes.
  • PostgreSQL — Same semantics as SQL Server on PostgreSQL, defaulting to TriggerProtected immutability mode. Credentials follow the same secret-reference 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.

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 asynchronous 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, Warning, 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.

Health is derived as follows:

  • Critical — a delivery has permanently failed recently. The exact window is configurable per deployment.
  • Warning — a compliance target has received no deliveries yet, a delivery is waiting for a retry, or a permanently failed delivery falls outside the critical window. A failed delivery keeps the target at Warning until it ages out of audit retention, because nothing redelivers it automatically.
  • Healthy — no delivery has failed and none is waiting to be retried. Deliveries still queued for their first attempt do not degrade the state.

A disabled target shows a Disabled tag in place of its health state on every screen: it delivers nothing by intent, so a health reading would be misleading. Its health state is reported again once it is re-enabled. A disabled compliance target still counts as missing compliance coverage in the dashboard's overall health card.

A delivery is retried automatically with increasing backoff between attempts, up to a configured attempt budget, and is then marked Failed. While a delivery is retrying, the Audit Events panel shows the timestamp of its next scheduled attempt beneath the status badge.

The Monitoring Dashboard shows a summary health card for audit delivery with a direct link to the full settings page. The card reports Critical whenever any enabled compliance target is critical.

Requeueing Failed Deliveries

A delivery that exhausts its attempt budget is marked Failed and is never retried on its own. The Audit Events panel inside a target's View screen provides three ways to put failed deliveries back on the queue. All three require the Governance Manage role and are hidden from read-only users.

  • Requeue on an individual row — returns that one delivery to the queue. The button appears only on rows whose delivery has failed.
  • Requeue all failed — returns every failed delivery of the target, whatever the current filters show.
  • Requeue matching filter — returns only the failed deliveries matching the filters currently set in the panel (category, action, audit outcome, delivery status, failure code). The button stays disabled until at least one filter is set.

A requeued delivery returns to Pending, becomes due immediately, and gets a fresh attempt budget; it is picked up for delivery automatically in the background. Earlier attempts stay in the delivery history, and the recorded failure remains visible until the new attempt replaces it.

Only failed deliveries are ever requeued. Filtering on Succeeded or Pending deliveries and pressing a requeue button reports how many events matched but changes nothing — a delivered audit event is never sent twice, and a delivery that is currently in progress is left alone.

Requeueing is the way to clear a Critical target: once no failed delivery remains, health returns to normal on the next refresh. Every requeue is itself recorded as a governance audit event.

Outbound Host Allowlist Requirement

REST endpoint URLs must be registered in the Outbound Host Allowlist (Security → Outbound Allowlist) before the platform 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.

PreviousIdentity & trustPortalNextOverviewRuntime