The developer writes the policy. You evaluate it. The audit portal shows you whether the policy is being met, where it falls short, and what to ask next.
Who this is for: Compliance assessors, C3PAOs, Notified Bodies, and auditors who receive a .swt3-gate.yml file from a development team and need to evaluate it against the organization's live compliance posture. No engineering background required.
Ask for the gate config. When assessing an organization that uses SWT3, ask: "Can I see your .swt3-gate.yml?" This file is the developer's stated compliance policy. Evaluating it against the live ledger tells you whether they are meeting the policy they set for themselves. If they do not have one, that is itself a finding.
A gate configuration (.swt3-gate.yml) is a YAML file that defines an organization's AI compliance policy as code. It specifies:
The file lives in the developer's source code repository. It is version-controlled, so you can see when the policy was last changed and by whom. For the full spec, see the companion Developer Gate Config Guide.
Request the file from the development team before your assessment. Ask:
.swt3-gate.yml file."strict mode enabled?" (Strict mode fails the gate if the ledger contains models not listed in the config.)If the organization does not have a gate config, document this as a finding: the organization has no codified compliance policy for its AI systems. This is equivalent to running without a security baseline.
The developer provides you with an audit share link (a URL containing an audit token). This link gives you read-only access to the audit portal for their tenant. No account creation is required. If you do not have a share link, ask the developer to generate one from their Settings page.
Once in the portal, navigate to the Policy Assessment tab. You will see an upload area where you can either:
The portal accepts .yml and .yaml files. JSON is not accepted; the config must be in YAML format. If the developer sends a different format, ask them for the YAML source (it lives in their repository as .swt3-gate.yml).
The portal validates the YAML in real time. If the file has syntax errors or is missing the required version: "1.0" field, you will see an error immediately. A valid config shows a green checkmark.
After uploading, the portal shows two selectors:
eu-ai-act and sr-11-7), choose the one you are assessing. If only one framework is defined, it is auto-selected.Click "Evaluate Policy" to run the evaluation against the live compliance ledger.
The results page shows three layers of information:
At the top: the overall gate status (PASS, WARN, or FAIL), the config name, the evaluated model (if scoped), and counts of passed, warned, failed, and missing procedures.
Below the summary, results are grouped by regulatory article (matching the group field in the config). Each group is an expandable section. Groups containing failures are auto-expanded so you see the problems first.
Within each group, every procedure shows:
| Field | What It Tells You |
|---|---|
| Status badge | PASS (green), WARN (amber), or FAIL (red) |
| Procedure ID | e.g., AI-FAIR.1 |
| Reason | Human-readable explanation (e.g., "No verdict found for AI-FAIR.1" or "Verdict is 12 days old, exceeds 7d threshold") |
| Ref | Regulatory reference from the config (e.g., "Art. 10(2)(f)") |
| Critical flag | If marked critical, stale evidence is a FAIL, not a WARN |
| Age | How old the most recent verdict is, compared to the max_age threshold |
When all procedures are within policy, the summary bar shows a green PASS badge with all counts in the "passed" column and zero in "warned" or "failed." Every article group is collapsed (no failures to auto-expand). Each procedure row shows a green badge, the time since last witnessed (e.g., "2h ago"), and the max_age threshold it was checked against. A fully passing evaluation means the organization's live compliance posture meets the policy they defined in their gate config.
What it means: The organization's policy requires this procedure, but no evidence exists in the compliance ledger. The SDK has not witnessed this procedure for any model.
Severity: FAIL (if required: true) or WARN (if optional).
Follow-up: Ask the developer which SDK method produces this procedure's evidence. Verify the method is called in the application code.
What it means: Evidence was produced at some point, but it is older than the policy allows. The AI system may have changed since the evidence was last generated.
Severity: FAIL (if critical: true or strict: true) or WARN.
Follow-up: Ask why the evidence is not being refreshed. Is the witness running? Is the AI system still active? Has the deployment changed?
What it means: The compliance ledger contains witness anchors from AI models that the gate config does not list. In strict mode, this is a FAIL. It indicates either undocumented deployments or a config that has not been updated.
Follow-up: Ask the developer to explain each ungoverned model. Are they test models? Shadow deployments? Models added after the config was written?
What it means: The organization uses SWT3 for witnessing but has not codified a compliance policy. Evidence is being generated, but there is no defined bar for what constitutes compliance.
Follow-up: Recommend the organization generate a config using swt3 gate --init for their applicable framework. This takes less than 5 minutes and immediately creates an evaluable policy baseline.
Click "Export JSON" at the bottom of the results page. The export includes the complete evaluation: overall gate status, per-procedure results with reasons, the config hash (SHA-256 of the YAML, deterministic), and the evaluation timestamp. Include this export in your assessment workpapers as evidence of the policy evaluation.
The config hash is deterministic: the same YAML always produces the same hash. If the developer modifies the config after your assessment, the hash will differ, proving the change.
Based on your evaluation results, consider these follow-up questions:
swt3 gate --init --framework [applicable framework] and share the generated file?"