Execution evidence

The record behind the decision.

Follow the information, the policy and the model choice in one example. See what a reviewer can use to understand an AI request.

Kordane BoundSense · Decision recordKDR-2026-0714-00381

In this synthetic example, summarisation of a restricted investigation report was permitted in the private VPC using the specialised private model, which met the case-summary rubric. Protected identifiers were tokenised locally before the crossing. A second approved private model is held as fallback only.

Task
Summarise a restricted investigation report
Information class
Restricted
Requested by
Named analyst with authorised case access
Policy version
boundary-policy-17
Permitted environments
Private VPC · isolated local
Rejected environment
Public frontier API, refused for this information class
Quality threshold
All required source facts covered correctly; no unsupported factual statements
Evaluation rubric
Reviewers list required source facts before evaluating a summary. Required-fact recall is correctly covered required facts divided by all required facts. Factual precision is source-supported factual statements divided by all factual statements. Missing required facts and unsupported statements are counted separately.
Transformation
Protected identifiers tokenised locally
Fallback condition
A required fact is missing or a factual statement lacks source support; execution is held for review or uses a second permitted private model that meets the rubric
Human approval
Not required for summarisation · required before any external action

Candidate models

  • local-small-v3rejectedRequired-fact check failed · Required facts not fully covered
  • specialised-private-v2selectedMeets the case-summary rubric · Smallest permitted candidate meeting the rubric
  • private-general-mediumfallbackMeets the case-summary rubric · Held as fallback; not required

Evidence retained

  • Policy decision
  • Information classification
  • Transformation record
  • Evaluation set version
  • Candidate comparison
  • Selection reason
  • Fallback path
  • Response provenance
  • Decision identifier

Synthetic decision record · Illustrative outcomes, not measured results

From an example to your workflow

Agree the test before choosing the model.

A scoped pilot starts with one task, approved data and written acceptance criteria. Here is the evaluation process we agree with your team.

  1. Define the task and the boundary.

    Choose the input, expected output and permitted environment. Record what information may leave, what must stay and when a person must approve.

  2. Agree how to judge the result.

    Choose representative examples and expected answers or fields. Set task-specific quality thresholds, latency and cost limits, and cases that must be blocked or escalated.

  3. Compare permitted candidates.

    Evaluate candidate models on the same agreed examples. Retain outputs, quality checks, timing and the reason for accepting or rejecting each candidate.

  4. Review the evidence and the gaps.

    Review errors, fallback decisions and deployment requirements with your team. Agree whether to proceed, revise the scope or stop.

Real-data evaluation depends on agreed access to your data. Where that is unavailable, we use synthetic examples. Scope and deliverables are agreed before work begins.

The examples on this website use fictional data and illustrative scores. They show how to inspect a decision; they are not customer results or measured production benchmarks.

Run a synthetic information crossingInspect an illustrative model comparisonRead a synthetic decision record

The evidence model

Six categories. One decision.

Each category below lists what the record covers and its current state, using the standard maturity vocabulary.

Task evidence

  • Task class and workflowAvailable in pilots
  • User or service identity and roleAvailable in pilots
  • Requested actionAvailable in pilots
  • Timestamp and decision identifierDemonstrated

Information evidence

  • Information classificationDemonstrated
  • Sensitive values detectedDemonstrated
  • Transformation performedDemonstrated
  • Restoration rulesDemonstrated
  • External transfer decisionDemonstrated
  • Retention ruleAvailable in pilots

Policy evidence

  • Policy version and applicable ruleAvailable in pilots
  • Permitted and rejected environmentsDemonstrated
  • Required approvalDemonstrated
  • Refusal reason where applicableDemonstrated

Model evidence

  • Candidate models and evaluation versionAvailable in pilots
  • Required threshold and measured resultAvailable in pilots
  • Selected model and rejected alternativesAvailable in pilots
  • Selection reasonAvailable in pilots

Execution evidence

  • Final route and runtimeDemonstrated
  • Tool permissionsAvailable in pilots
  • Human approval recordAvailable in pilots
  • Fallback condition and any fallback usedAvailable in pilots
  • Output provenanceAvailable in pilots

Review evidence

  • Export for reviewAvailable in pilots
  • Retention controlsAvailable in pilots
  • Reviewer and review statePlanned
  • Replay and reconstructionPlanned
  • Integrity controlsPlanned

Statuses use the standard maturity vocabulary. Integrity verification and replay are roadmap items and carry the Planned label.

Three controlled workflows

Where the decision materially matters.

Synthetic walkthroughs · Illustrative values

Restricted document analysis

Sensitive input
A restricted investigation report enters locally.
Policy question
May this content cross, and in what form?
Permitted environment
Private VPC or isolated local; the public frontier route is refused for this class.
Model threshold
All required source facts covered correctly; no unsupported factual statements
Selected route
Specialised private model
Fallback
Another permitted private model, or human review if no candidate passes
Evidence produced
Classification, transformation, candidate comparison, selection reason, provenance
See the product

Regulated customer response

Sensitive input
Customer information retrieved under role policy.
Policy question
Which environment may draft this, and who must approve the action?
Permitted environment
Depends on the information class; consequential actions are gated.
Model threshold
Task-specific quality and tone criteria
Selected route
Permitted assistant model for the class
Fallback
Human handling whenever policy or the threshold requires it
Evidence produced
Role policy, environment decision, approval record, response provenance
See the product

Sensitive audio processing

Sensitive input
Audio that may not leave the environment.
Policy question
Must transcription and extraction stay local?
Permitted environment
On-premises or isolated; external escalation only where policy allows.
Model threshold
Language-specific transcription and extraction criteria
Selected route
Local transcription, then a permitted specialist model
Fallback
External escalation only after transformation, and only if permitted
Evidence produced
Transformation record, model choice, output provenance
See the product

Request a demoTry the BoundSense demo