Build: Compliance evidence map

In one line. Turn a pile of SOC 2 evidence into control-tagged, human-confirmed records — with a live coverage picture and a trail that answers the two questions every auditor asks. You’ll build. A Processing collection with a control taxonomy, a Control Mapper agent that assigns control IDs with a confidence, a lifecycle that auto-accepts confident mappings and routes the doubtful ones to a reviewer, a read-only auditor seat, and a coverage page. You’ll use. Collections & schema · Taxonomy, lifecycle, tags & events · Your first agent · Access & roles · Pages & cards

The setup: your team is preparing for a SOC 2 audit. You have evidence — access-review exports, on-call rotas, change-management tickets, a pen-test report, screenshots of MFA settings — and a long list of controls each piece is supposed to satisfy (CC6.1, CC7.2, and so on). Today that mapping lives in a spreadsheet nobody trusts: you can’t easily answer “which controls have no evidence?” or “who confirmed this artefact maps to CC6.1?” The auditor will ask both.

This is a classify-route-report build: a taxonomy names the controls, an agent maps each artefact to control IDs with a confidence, a lifecycle auto-accepts the confident mappings and routes the rest to a human, personas gate that review and give the auditor read-only access, and a page shows coverage. Plan for 75–90 minutes for the core build. You need a project to build in, at least one language model registered (LLMs & services), and a handful of sample evidence files (PDF/PNG/DOCX) to upload.

One honest caveat up front. This is a Processing collection (decide on each artefact), not a Knowledge collection. The platform’s job here is to classify and route each piece of evidence and record an auditable decision — exactly what Processing collections and the Four-Eyes lifecycle are built for. If you also want auditors to chat with the evidence (“show me our access-review evidence”), that is a second, Knowledge collection — a different build.

Steps

Stage 1 — Create the “SOC2 Evidence Q4” Processing collection

Where: Studio > Data > Collections (Collections & schema).

1. Click + Collection.
2. Purpose: leave/select Processing. Evidence gets decided on per artefact — it moves through review stages.
3. Collection Name: SOC2 Evidence Q4.
4. Description: Evidence artefacts mapped to SOC 2 controls for the Q4 audit.
5. Leave the rest at defaults. Click Save.

Watch out — Purpose is permanent. You pick Processing vs Knowledge once, at create time; afterwards it shows as a read-only chip and cannot be changed. We want Processing here — pick it deliberately.

Checkpoint. SOC2 Evidence Q4 appears in the collection list, and selecting it shows the seven-tab workbench (General · Taxonomy · Lifecycle · Tags · Events · Ingestion · Agents). Because it’s a Processing collection, it was seeded with the 8-stage Four-Eyes lifecycle automatically — you’ll reshape that in Stage 5.

Stage 2 — Define the control taxonomy (the fields)

This is the heart of the build: the fields drive extraction, so what you author here is exactly what the agent will fill. Where: select the collection, then the Taxonomy tab.

First, create the Learner:

1. On the Taxonomy tab, click Taxonomy at the bottom of the list to open Create Taxonomy.
2. Taxonomy Name: Control Mapping. Description: Maps an evidence artefact to SOC 2 controls.
3. Type: Document Classification — you’re classifying a whole artefact, not pulling a table.
4. Entity: SOC2 Evidence Q4 (pre-filled). Submit.

Then add the fields. Select Control Mapping, click + Label, and add these five (use Add between them, Add and exit on the last). The Description is what the agent reads to know what to put there — write each one as an instruction to the agent:

Field (Label)	Shape	Description to type
control_family	Single-select — open View Config ▸ Validation and list the families: Security, Availability, Confidentiality, Processing Integrity, Privacy	The SOC 2 trust-services family this evidence supports
control_id	Text (default)	The specific control ID this artefact satisfies, e.g. CC6.1, CC7.2. List all that apply, comma-separated.
evidence_type	Single-select — Validation listing Policy, Screenshot, System Export, Report, Ticket, Log	What kind of artefact this is
coverage_status	Single-select — Validation listing mapped, partial, missing	mapped = clearly satisfies the control; partial = related but incomplete; missing = no control match found
mapping_rationale	Text	One sentence: why this artefact maps to that control. Quote the part of the document that proves it.

Tip — keep the family list flat. A short single-select (control_family) is what the routing in Stage 5 and the per-family coverage page in Stage 6 both read. Five clean values beat a free-text field here.

Watch out — recommendation is not a field on this Learner. Don’t add a recommendation Label here: every Label’s value travels as a list, one entry per instance, so a single-select Label can never deliver the plain approve / decline / needs-info string the Stage-5 gate needs — it reaches the gate as a bundle it can’t parse, which the gate treats as a verdict it doesn’t recognise. Stage 4 teaches the mechanism that actually delivers a plain verdict.

Checkpoint. The Labels tree under Control Mapping shows all five fields. The collection now knows what to pull out of every artefact.

Stage 3 — Bring the evidence in

Where: the collection’s Ingestion tab, or Studio > Data > Ingestion (Ingestion & connectors). For a one-time audit pack, the fastest path is a direct upload:

1. Open the Ingestion tab on SOC2 Evidence Q4 (or use Upload on Studio > Data > Ingestion).
2. Upload your evidence files — drop in 5–10 to start: a couple of access-review exports, an MFA screenshot, a change ticket, the pen-test report.
3. Each artefact appears in the collection’s document list immediately with a “Processing…” chip that climbs to 100% as the agent reads it.

For a recurring pull. If evidence keeps arriving in, say, a SharePoint “Evidence” library, set up a connector once and a scheduled job instead of uploading by hand — same page, Studio > Data > Ingestion (Ingestion & connectors). An older multi-source setup wizard still opens from bookmarks, but it is no longer in the menu; build new sources here.

Checkpoint. Your artefacts are listed in SOC2 Evidence Q4. They have no control mappings yet — that’s the agent’s job, next.

Stage 4 — Build the “Control Mapper” agent

Where: Studio > Agents > Agent Toolkit > Agents → + Agent ▸ Agent (Your first agent).

1. Persona tab.
   • Name: Control Mapper
   • Description: Maps each evidence artefact to the SOC 2 controls it satisfies, with a confidence.
   • Instructions: click the co-pilot, seed it with “Read a piece of audit evidence and decide which SOC 2 controls it satisfies,” then refine to roughly:

     You are a SOC 2 compliance analyst. For each evidence artefact, identify which SOC 2 control(s) it satisfies and return the control family, the specific control ID(s), the evidence type, a coverage status, and a one-sentence rationale quoting the document. If the artefact clearly satisfies a control, set coverage_status to mapped. If it is related but incomplete, use partial. If you cannot tie it to any control, use missing and leave control_id blank. Never invent a control ID; only use IDs the evidence genuinely supports. Then, separately from those fields, state your overall confidence (0-1) and a recommendation: approve for a confident mapped, decline for a confident missing, needs-info for anything you’re unsure of. Always give a confidence — a mapping with no stated confidence cannot auto-accept.

2. Model tab. Pick your project’s language model (LLMs & services). Set Agent Mode = Thinking while you build (so you can watch its reasoning), then flip to Fast for production. Leave Advanced sampling at defaults — extraction wants a low temperature.
3. Output tab. This is what turns chatter into data — but leave Structured output off, so the model isn’t schema-bound to Control Mapping’s five Labels alone:
   • Turn on Auto-annotate document and pick the Taxonomy/learner Control Mapping (the fields from Stage 2) in the picker it shares with Structured output.
   • Have the agent reply with one flat JSON object: a key per field (control_family, control_id, coverage_status, evidence_type, mapping_rationale) plus top-level recommendation and confidence. Auto-annotate maps the field-name keys onto Control Mapping’s Labels, and reads recommendation/confidence from the flat reply or a _meta block, never from a Label. You lose the per-field Confidence score/References display (Structured-output-only) in exchange. This recipe is unverified — don’t rely on it until someone has checked it on a live project.
4. Save Agent.
5. Test in the playground (right pane). Set Input Type = Document, pick one uploaded artefact, press Enter. Watch it stream the Thinking block, then the flat JSON reply — the filled fields (control_family, control_id, coverage_status…) alongside recommendation and confidence. Watch out — with Auto-annotate on, this isn’t a side-effect-free preview: the run writes the fields back onto that real artefact and can move it through the lifecycle, the same as a live arrival. Wrong mapping? Sharpen the Instructions and re-run. Once a few come out clean, flip Agent Mode = Fast.

Checkpoint. In the playground, the agent reads an artefact and returns CC6.1 (or similar) with a confidence and a quoted rationale. It isn’t wired to the collection yet — that’s Stage 5.

Stage 5 — The gap-review lifecycle: auto-accept vs route to a reviewer

Now make the decision auditable. Two parts: shape the stages so confident mappings auto-accept and shaky ones go to a human, then assign the agent so every new artefact runs through it. Where: the collection’s Lifecycle tab (Taxonomy, lifecycle, tags & events).

Your Processing collection already has the Four-Eyes flow. For evidence mapping you want a leaner shape — one human gate, not two — so edit the stages:

1. Keep Intake → AI Processing → AI Recommendation as-is: intake, the agent runs, then the branch.
2. Open L1 Review’s stage editor and set its Alias Name to Compliance Review — leave the State Name itself as L1 Review. The router that moves a document forward matches stages by their literal State Name, not the alias a person reads; renaming the State Name breaks automatic routing silently. Confirm Send to Inbox (human review) is on (this is what makes it a review stage). The alias shows on a document’s stage stepper and on the move choices of its action pane; the Inbox card and the Lifecycle tab keep showing L1 Review.
3. Set the terminal stages to read Mapped (the approve/End stage) and Gap (the reject/End stage — no good evidence found). Use the stage editor’s Final Name for the display label.
4. You can delete L2 Approval for this lighter flow — one reviewer is enough for evidence triage — or keep it if your audit demands four eyes. The editor doesn’t check the graph’s shape when you save, so keep one Start stage and a path from it to an End yourself; several End stages are fine — this flow ends in Mapped or Gap.

Watch out — don’t Reset to default. Reset to default rebuilds the standard Four-Eyes flow and asks you to confirm by typing the collection’s identifier. Edit the stages in place; don’t reset a lifecycle that has live documents.

Next, turn on Auto-decide for confident mappings. Below the stage graph, the Auto-decide policy card lets the platform accept clean mappings without sending them to a human — but only for an artefact whose agent run actually reported a verdict:

1. Switch it to Auto-decide is ON.
2. Min confidence = 0.90 — high-confidence mappings auto-accept; everything below routes to review. This is the overall confidence the Control Mapper reports itself, top-level in its reply (Stage 4).
3. Leave Require zero open flags on (its default). An open flag is a value on the artefact still marked as a problem and not cleared — a mark someone raised on it, a quality check it failed, a validation rule it broke. One is enough to hold the artefact for a reviewer, however confident the mapping was. On an evidence queue that is exactly right.
4. Applies to = Approve only (recommended start) — auto-accept confident mappings, but always keep human eyes on the rest.

The card’s summary line now reads “Auto-approve when AI confidence ≥ 90% AND zero open flags.” Three things have to be true for an artefact to take that path: recommendation = approve and confidence ≥ 0.90, both reported by the agent in Stage 4, and no open flag on it. Without a recommendation, every artefact lands in Compliance Review no matter how high its confidence — there is no verdict to weigh. A clean CC6.1 mapping with recommendation = approve lands straight in Mapped; a 0.6-confidence guess or a missing routes to Compliance Review and the Inbox. A needs-info is different again — it routes straight to the collection’s Needs Info stage (still present and still Inbox-enabled in this leaner flow, even though Stage 5 didn’t rename or gate it), not to Compliance Review.

The trail never pretends a human decided. An auto-accepted artefact’s audit entry shows that the platform accepted it automatically, plus the confidence it accepted at; a human confirmation shows the reviewer’s email. Nothing is signed in someone’s name that they didn’t do — which is the entire point for an auditor.

Finally, wire the agent to the collection. On the collection’s Agents tab, Assign Control Mapper as the intake/processing agent. From now on, every artefact that lands — uploaded or pulled by a connector — is run by the agent automatically, filling the five fields and entering the lifecycle.

Checkpoint. Upload one new artefact. Watch it: chip climbs, fields fill, and if confident it lands in Mapped; if not, it appears in the Inbox at Compliance Review for a human. If an item isn’t in the Inbox yet, refresh it: for a document moved automatically, the item is added when the Inbox list loads, or by a background pass within about five minutes.

Stage 6 — People, the auditor’s seat, and the coverage page

Two jobs left: give people the right access — including a read-only seat for the auditor — and build the picture of mapped-vs-missing.

Access first. Where: Studio > Governance > Access > Users & Access, then the Personas view (Access & roles). A persona is this solution’s own workflow role — the vocabulary your compliance team already uses.

1. + Add persona → name it Compliance-Reviewer. Choose the SOC2 Evidence Q4 collection and the review stage it works in, and grant the review actions a reviewer needs. Save, then add your reviewers to it from the People view.
2. Back on the Lifecycle tab, edit the Compliance Review stage and set Can be viewed by = Compliance-Reviewer. Now only that persona can act on artefacts waiting for review.
3. + Add persona again → name it Auditor, cover the same collection, and leave the actions read-only — no document-edit actions. Someone who should never build anything at all gets the Viewer workspace role as well; a Viewer can read what they’ve been given and change nothing.

The audit trail is the compliance record. Every stage move — an automatic accept, a reviewer’s confirmation, a re-classification — is written to Audit & Usage: Studio > Governance > Oversight > Audit & Usage. The page opens on Audit (who, when, what operation); a switch under the title flips it to Usage. When the auditor asks “prove who confirmed this artefact maps to CC6.1”, you filter Audit by document and hand them the trail — you never edit it. Export CSV on the project Audit view downloads exactly the rows your filters produce, up to 10,000.

One limit to state plainly, because an auditor will eventually ask: actions taken with an API key that change something are recorded; reads made with a key are not. An empty API-key feed proves nobody changed anything — it does not prove nobody read anything.

Then a “Control Coverage” View. Watch out — Studio > Data > Views doesn’t build one. That page lists, inspects and deletes the Views that already exist; it has no “+ View” of its own. You build a View from the SOC2 Evidence Q4 Documents list:

1. Open the collection’s Documents surface and shape it: add columns control_family, control_id, coverage_status, evidence_type, plus the document title and current stage.
2. Options ▸ Save View as → Name Control Coverage, Save Under = Project Views, Help Message Every artefact with its control mapping.
3. Back in Options, use Allowed Roles to scope it to Compliance-Reviewer and Auditor.
4. It now appears as a tab on the Documents surface, and as a row on Studio > Data > Views — where you can re-open its details or delete it, but not where you made it.

Finally the coverage page: Studio > Experience > Designer > Pages (Pages & cards). Create a page, choose a layout, and drop in cards from the card library (Studio > Experience > Designer > Cards) that answer “which control families are evidenced, and which are bare?”:

1. A DocList card — the list auditors browse. A DocList card has no setting that binds it to a saved View — give it the same picture by hand: add control_family, control_id, coverage_status, evidence_type as Label columns (the fixed Columns list is title/stage/assigned/updated and the like — it doesn’t carry a Learner’s Label values), and add the same filter under Label filter that Control Coverage uses. The View stays the one your auditors pick from the Documents surface’s tab row; the card just mirrors its shape.
2. A chart card grouping by control_family and coverage_status, drawn as a stacked bar so each family shows its mapped / partial / missing split at a glance. A family with a tall missing segment is a gap you need more evidence for.
3. A single-number card for a headline like “% artefacts mapped”.

Configure each card in the inspector on the right, then Preview the page to see exactly what your end users get.

Checkpoint. The page shows mapped-vs-missing per family. A control family with no mapped rows is a coverage gap — visible, not buried in a spreadsheet.

Stage 7 — Test the whole machine

A full pass, end to end:

1. Upload a fresh access-review export. It enters at Intake, the Control Mapper runs, and it auto-lands in Mapped tagged CC6.1 (or similar), with recommendation = approve, a confidence at or above 0.90 and no open flag — no human needed. Open its stage history: the entry records an automatic accept plus the confidence. If it stops at Compliance Review instead, look for an open flag on it before you suspect the confidence (Stage 5).
2. Upload something that clearly doesn’t map to any control — a lunch-menu PDF or an unrelated internal memo. The agent returns coverage_status = missing with a confident recommendation = decline (or a confidence below 0.90); it routes to Compliance Review and appears in the Inbox. Sign in as someone in the Compliance-Reviewer persona, open it, correct or confirm the mapping, and push it to Mapped or Gap. The audit trail now shows your email on that move. Then upload a third file the agent genuinely cannot resolve — a half-finished policy draft, or an export with its control references redacted. That one comes back recommendation = needs-info, per Stage 4’s Instructions, and waits at the separate Needs Info stage, not Compliance Review. Two different queues, two different conversations: we disagree with the mapping versus we need more from you.
3. Open the coverage page. The stacked bar shows which families are evidenced and which still read missing — that’s your gap list for the audit.
4. Sign in as the Auditor. Confirm you can browse the Control Coverage View and read every mapping and citation, but cannot edit anything. Filter Audit & Usage by one document and confirm it tells the full who-did-what story.

If a clean artefact auto-mapped, an unmappable one routed to Compliance Review, a genuinely ambiguous one waited at Needs Info, and the page surfaced a gap — the machine works.

Make it production-worthy

• Measure the mapper’s accuracy (AI Builder). Once reviewers have corrected a few dozen mappings, those corrections are labelled examples. Train a model on the Control Mapping Learner at Studio > Agents > Classic ML > AI Models → + Model, then run Studio > Agents > Classic ML > Prediction Report against a small reference project of known-correct mappings. Read the per-field accuracy — if control_id lags, that’s where to feed more corrections. The Control Mapper agent already targets that Learner, so a better-trained model improves mappings with no re-wiring.
• Lock the configuration for the audit period (Access & roles). You built the read-only Auditor persona above; pair it with Studio > Governance > Versioning > Configuration lock once the audit period opens — the project’s configuration cannot be changed while it is locked, so nobody can quietly rewrite a control taxonomy you’ve blessed, and you unlock it again afterwards. Audit & Usage remains the proof of every mapping decision.
• Export a control-coverage report. From the Control Coverage View, export the coverage table for your auditor — or wire an Event (Taxonomy, lifecycle, tags & events) to POST to your GRC tool the moment a reviewer approves an artefact into Mapped: a stage-change trigger with a Webhook action. An artefact the gate auto-approves into Mapped doesn’t raise that Event today, so the View’s export is the way to report those.

The pattern travels. Taxonomy names the categories, the agent assigns them with a confidence, the lifecycle auto-accepts the confident and routes the rest, the page reports coverage. The same shape fits risk tiering, PII discovery, vendor due-diligence, records classification — swap the taxonomy and the rationale prompt, keep the machine. And wherever an agent’s output feeds a decision, have it report recommendation and an overall confidence and let Auto-decide plus Send to Inbox split clean from uncertain: it’s the cheapest, most auditable form of human-in-the-loop on the platform.

Where to go next

• Build: Contract review — the other “agent reads a document and makes a judgement” build.
• Package & ship a solution — publish this whole compliance machine as a reusable Solution.
• The Agentic System pattern — this build is the compliance facet standing alone; here’s how it fits a whole domain brain.