Gates and evidence

A Runway promotion is not a button that runs a deploy. It is a decision backed by evidence. Before an approved release can reach production, the pipeline proves five things. If any one fails, the release stops with a readable reason and the attempt is recorded.

The evidence chain

The five guarantees

1. Run-bound verdicts

When gate_evaluate requests an evaluation, the returned run id is captured from the adapter-success event into the deployment projection. A later gate_record verdict is only accepted when its runId matches that captured id and it comes from a system actor. You cannot record a verdict for a run that was never requested.

2. Provenance

promotion_approve requires the passing verdict to have source: fabric-experiments and a non-empty evidence URI. A manual or mock verdict is recorded faithfully in the log, but it never unlocks production — the provenance policy blocks the approval.

3. Freshness

Evidence has a shelf life. If the verdict's evaluation timestamp is older than the configured TTL window, the freshness policy rejects the approval as stale and a fresh re-run is required. This prevents a green result from months ago from certifying today's artifact.

4. Separation of duty and multi-approval

The deploy requester can never endorse their own promotion, and one actor cannot endorse it twice. Tenant policy chooses the total number of distinct approvals, a minimum human count, and whether registered Harness agents may count. Every configured gate must have passing, fresh, run-bound evidence. The first endorsement pins these approval/evidence settings for the entire cycle; changing tenant policy cannot alter an in-flight decision. The trusted worker finalizes only after the pinned thresholds pass.

When the current tenant policy differs, the Approvals page shows both revisions. An authorized human or agent can invoke runway.promotion_reopen with a reason. That governed action discards all prior endorsements and returns the release to gate review; the next endorsement pins the current policy.

5. Trusted-worker execution

Endorsement, finalization, and execution are separate actions. Even an approved release is only deployed to production by a trusted worker service principal (promotion_execute). Humans, the CLI, MCP tools, and CI can request and approve, but the production mutation is machine-executed and audited.

What this buys you

Because the gate is a policy checkpoint rather than a convention, "we forgot to run the tests" and "someone approved their own change" are not possible states. The audit log answers, for any production release: which artifact digest, which evaluation run, which evidence, who requested it, and who approved it.

AI Gateway correlation in signed evidence

Evidence exports use schema version 2 and may add a projected platformEvidence.databricksAiGateway section. Configure a Harness Databricks model request with the same Fabric action correlation ID:

import { databricksFoundationModelProvider } from "@fabric-harness/databricks";
import { databricksGatewayRequestTags } from "@fabricorg/runway";

const model = databricksFoundationModelProvider({
  host: process.env.DATABRICKS_HOST!,
  token: getShortLivedToken,
  mode: "ai-gateway",
  requestTags: () => databricksGatewayRequestTags({
    correlationId: action.correlationId,
    organizationId: action.tenantId,
    deploymentId: action.deploymentId,
  }),
});

Harness serializes these tags into Databricks-Ai-Gateway-Request-Tags. Runway queries system.ai_gateway.usage with named SQL parameters and joins only records whose fabric_correlation_id is already present in the Fabric event set. The signed projection reports matched, partial, missing, or not-configured, including unmatched Fabric IDs. Unknown correlations, duplicate request IDs, invalid usage, and inconsistent token totals fail the export.

Only a bounded projection is retained: request/invocation identity, timestamp, model or service, tokens, latency, status, and trace ID. Prompt, response, headers, and arbitrary tag payloads do not enter the Fabric evidence report. Request-level cost is optional because the Gateway usage table is not the billing system; cost reconciliation remains a separate billing evidence path.

The current Databricks Beta documents this system table as account-admin-only. Run the source in a separate, reviewed evidence worker rather than making the customer-facing Runway App principal an account admin. The default App composition therefore emits not-configured honestly.