> ## Documentation Index > Fetch the complete documentation index at: https://standard.aiuc-1.com/llms.txt > Use this file to discover all available pages before exploring further. # Technical evaluations (evals) export const InlineClock = ({city, timeZone}) => { const [time, setTime] = useState('--:--:--'); useEffect(() => { const update = () => setTime(new Intl.DateTimeFormat('en-US', { hour: '2-digit', minute: '2-digit', second: '2-digit', hour12: false, timeZone }).format(new Date())); update(); const id = setInterval(update, 1000); return () => clearInterval(id); }, [timeZone]); return
{city} {time}
; }; Technical evaluations, or evals, are the independent technical testing that AIUC-1 requires for certification: thousands of benign, social engineering, and adversarial scenarios run against the agent and graded against the AIUC-1 risk and attack taxonomy. **AIUC runs evals today. Auditor-led evals are in development.** Guidance for auditors who want to run evals themselves is coming soon. [Get in touch](https://www.aiuc-1.com/contact) to register interest.
| | | | - | - | | Leads | AIUC | | Client | Reviews the preliminary samples and Round 1 results, and remediates P0 and P1 findings | | Auditor | Validates that testing took place, followed the methodology, and met the pass bar | | Timing | Weeks 2 to 8, in parallel with [evidence collection](/auditors/deliver-and-certify/evidence-collection).
Round 2 runs only where Round 1 surfaces P0 or P1 findings; with a clean Round 1 the eval phase ends at week 4 | | Inputs | The signed [scoping document](/auditors/deliver-and-certify/scoping/agent-and-evaluation-scope), covering the agent under test and the risk distribution, and stable technical access to the agent | | Output | Final evaluation results for the audit report, with no open P0 or P1 findings | *Week 2.* A small sample set is run to confirm the methodology and configuration. The client's technical reviewers spend about 30 minutes on it and give feedback on realism, methodology including grading, and debuggability. The final eval count is set from these runs by whoever runs the evals. *Weeks 3 to 4.* The full suite runs and results are shared with the client, followed by a roughly 30-minute results review. *Weeks 5 to 6.* The client remediates the P0 (Critical) and P1 (Major) findings, which are required to pass. Remediation of lower-severity findings, P2 to P4, is at the client's discretion. The environment stays representative and unchanged otherwise, so both rounds run against similar configuration. *Weeks 7 to 8.* Where Round 1 surfaced P0 or P1 findings, the suite is re-run after remediation with the same risk and attack categories and regenerated individual scenarios. Only final results are included in the audit report. The final results are needed by the fieldwork closing meeting. ## How results are graded Every eval response is graded on the AIUC-1 severity scale, based on the potential impact of the agent's response: | Grade | Meaning | | - | - | | Pass | No issues identified | | P4 (Trivial) | Unlikely to cause harm | | P3 (Minor) | Low potential for harm | | P2 (Significant) | Moderate potential for harm | | P1 (Major) | High potential for harm | | P0 (Critical) | Severe harm imminent or active | **Coming soon:** details on how grading is customized based on B2B vs. B2C agents **Pass bar.** No open P0 or P1 findings. Together with a pass on every applicable requirement in [fieldwork](/auditors/deliver-and-certify/fieldwork), this is what earns certification. ## The auditor's role Today, the auditor does not run or design the evals. The auditor's role is to validate that testing took place, that procedures followed the documented methodology, and that results met the AIUC-1 pass bar: review the methodology, sample the test documentation, and verify the results against the pass bar. Auditor-led evals are currently in development. High-level, for auditors considering auditor-led evals once available. The work breaks into five jobs: eval scoping, connection, generation, running, and grading. Most of it is judgment about enterprise risk and software engineering. * **Enterprise risk judgment.** Understanding what a bad answer looks like for this client, in this industry; choosing which risks matter and weighting them; judging severity when grading. This majority of the work, and the hardest to train. * **Understanding the client's product.** Running a structured product walkthrough, mapping tools, data flows, guardrails, and tenancy. * **Platform operation.** Using AIUC's evaluation platform to generate, run, and grade evals, so results stay consistent across clients and auditors.  * **Connection engineering.** Connecting the platform to the client's agent, typically a plug-in when the client has a clean API and sometimes a small translation server. Needs an internal or client-facing technology team.  An AIUC-1 certificate has to mean the same thing whoever audited it. Evals run on one methodology so that results are comparable across clients and auditors; that is why they are centralized today and why auditor-led evals will follow the same methodology. The evaluation and grading methodology, and the risk and attack taxonomy. *** Evidence walkthroughs and a verdict per requirement.
37.782274° N -122.392147° W FIG. A (SITE INDEX)
Artificial Intelligence Underwriting Company
Code Structural unit a. AIUC-1 requirements for agent data, privacy, security, safety, reliability, accountability, and societal risk. b. Evidence templates for technical implementation, legal policy, operational practice, and third-party evaluation. c. Crosswalks to AI regulations, standards, and security frameworks. d. Quarterly updates shaped by enterprise adoption, risk, regulation, and community input.
100 © AIUC — ALL RIGHTS RESERVED
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.