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 an immutable 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 dashboard. You’ll use. Collections & schema · Taxonomy, lifecycle, tags & events · Your first agent · Access & roles · Shaping the experience

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, roles gate that review and give the auditor read-only access, and a dashboard shows coverage. Plan for 75–90 minutes for the core build. You need a project to build in, at least one LLM 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 Model ▸ 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 — Category is permanent. You pick Processing vs Knowledge once, at create time; afterwards it’s a read-only chip. We want Processing here — don’t switch it.

Checkpoint. SOC2 Evidence Q4 appears in the left rail, and selecting it shows the seven-tab workbench (General · Schema · 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 schema)

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

First, create the Learner:

1. On the Schema tab, click Taxonomy (footer) 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 dashboard 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 ▸ Connector ▸ 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 the Upload toolbar button on Studio ▸ Connector ▸ 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, then fills in.

Under the hood. On upload the backend creates the document row at once, stores the bytes, and hands off to the orchestrator to run the collection’s ingestion and extraction — you watch the chip climb to 100% live. For a recurring pull from, say, a SharePoint “Evidence” library, build a Connector once and a scheduled Job instead (Ingestion & connectors).

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 ▸ Agent Builder ▸ 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 LLM Model. 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 schema 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. The Reset to default action rebuilds Four-Eyes and is gated behind a confirm-by-EntityId prompt. 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.

Under the hood. Auto-decide never spoofs a user. An auto-accepted artefact’s audit row shows actor AI/auto plus the confidence; a human confirmation shows the reviewer’s email. The trail stays truthful — 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 — Roles, the auditor’s seat, and the coverage dashboard

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

Roles first. Where: Studio ▸ Security ▸ Access Roles (Access & roles).

1. + Role → Role Name = Compliance-Reviewer, Entity = SOC2 Evidence Q4. Under Show Advanced Settings, grant the review/annotate actions a reviewer needs and the relevant Allowed Document Actions. Create.
2. Back on the Lifecycle tab, edit the Compliance Review stage and set Can be viewed by = Compliance-Reviewer. Now only that role can act on artefacts waiting for review.
3. + Role again → Role Name = Auditor, Entity = SOC2 Evidence Q4. Grant read-only actions only: no document-edit actions, leave Allowed Studio Pages empty (consumer-only). The auditor can see evidence and mappings but change nothing.

The audit trail is the compliance record. Every stage move — an AI/auto accept, a reviewer’s confirmation, a re-classification — is written to the immutable Audit log (Studio ▸ Security ▸ Audit: who, when, what operation). When the auditor asks “prove who confirmed this artefact maps to CC6.1”, you filter the Audit log by document and hand them the trail — you never edit it. That trail is your answer.

Then a “Control Coverage” View. Open the collection in Studio ▸ Data Model and create a View (Shaping the experience):

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, Allowed roles = Compliance-Reviewer, Auditor. Save.

Finally the dashboard, in Studio ▸ Intelligence (Dashboards & inbox). Build one that answers “which control families are evidenced, and which are bare?”:

1. Add a View Widget pointed at your Control Coverage View — the table auditors browse.
2. Add a Query Widget grouping by control_family and coverage_status; pick Chart Type = 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. Optionally add a KPI / single-number widget for a headline like “% artefacts mapped”.
4. Open live dashboard to see exactly what your end-users get.

Tip. The Agentic Widget lets you describe a tile in plain language (“a bar chart of evidence count per control family, coloured by coverage status”) and have AI build it — the fastest way to a first chart if you’re unsure which template fits.

Checkpoint. The dashboard 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 audit row shows actor AI/auto 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 a Compliance-Reviewer, 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 dashboard. 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 the Audit log 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 dashboard 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 an AI Model on the Control Mapping Learner (Studio ▸ AI Builder ▸ AI Models ▸ + Model), then run a 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 role above; pair it with Project ▸ Version Control ▸ Governance to Freeze the configuration once the audit period opens — nobody can quietly rewrite a control taxonomy you’ve blessed. The Audit log remains the immutable proof of every mapping decision.
• Export a control-coverage report. From the Control Coverage View or the dashboard, 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 dashboard 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.