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: DocumentClassification — 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.

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.

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. Turn on Structured output, then:
   • Pick the Taxonomy/Learner Control Mapping (the fields from Stage 2).
   • Process unit = Page (most artefacts are short; sectioned reports can use Section).
   • Confirm the five Labels appear; tighten any Description if needed.
   • Turn on Confidence Score and References. The per-field confidence is what routes a mapping to human review in Stage 5; References give the reviewer — and the auditor — the source citation.
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 filled fields (control_family, control_id, coverage_status…), each with a confidence and a reference to the page. Wrong mapping? Sharpen a field Description 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. Rename L1 Review to Compliance Review — confirm Send to Inbox (human review) is on (this is what makes it a review stage). This is where uncertain mappings land.
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. Remember the validation rule: exactly one Start, one End, no dangling stages.

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:

1. Enabled = true.
2. Min Confidence = 0.90 — high-confidence mappings auto-accept; everything below routes to review.
3. Require Zero Flags = true.
4. Applies To = approve — auto-accept confident mappings, but always keep human eyes on the rest.

The card’s preview should read roughly “Auto-approve when AI confidence ≥ 0.90 AND zero flags.” A clean CC6.1 mapping lands straight in Mapped; a 0.6-confidence guess (or a missing) routes to Compliance Review and the Inbox.

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.

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. Where: Studio > Data > Views — Views has its own entry under Data; it is not a tab inside the collection, and not under Experience > Search.

1. New View → Name Control Coverage, Description Every artefact with its control mapping.
2. Columns: control_family, control_id, coverage_status, evidence_type, plus the document title and current stage.
3. Type = Project, and set which personas can use it — Compliance-Reviewer and Auditor. Save.

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 table card pointed at your Control Coverage View — the list auditors browse.
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 a confidence at or above 0.90 — no human needed. Open its stage history: the entry records an automatic accept plus the confidence.
2. Upload something ambiguous — a generic architecture diagram. The agent returns low confidence (or coverage_status = missing); 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.
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 ambiguous one routed to a human, 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.
• Freeze the configuration for the audit period (Access & roles). You built the read-only Auditor persona above; pair it with Studio > Governance > Versioning > Freeze once the audit period opens — the project’s configuration cannot be changed while it is frozen, so nobody can quietly rewrite a control taxonomy you’ve blessed, and you lift the freeze 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 an artefact reaches Mapped: a stage-change trigger with a Webhook action.

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, turn on Confidence Score 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.