Documentation
How to connect your AI agent to Jiminy, run your first audit, and understand what the results mean.
Sign up
Create your account at app.jiminy.uk/signup. You will be asked for your organisation name, and to choose an account type:
Self-serve, no invite code, no human contact. Sign up and get a working API key immediately, on this page, right after you submit the form. This is the account type for most SDK users. Free tier: 25 audits/month.
AI System Operator: you build or deploy AI agents as part of the design partner programme. Your account is linked to your organisation and your API key is issued once that link is confirmed, rather than immediately.
Independent Evaluator: you review AI systems on behalf of others (auditors, compliance consultants). Requires an invite code. Request one here.
Design partner programme: If you were introduced to Jiminy through the design partner programme, select AI System Operator and use the email address you registered with. Your API key will be emailed to you within one business day, once your account is linked to your organisation.
If you chose Self-serve, skip straight to Step 2: your key is already on screen. Copy it now: it is shown once and cannot be retrieved again.
Get your API key
Self-serve accounts see their key immediately after signing up, with a copy button, nothing further to wait for. Design partner (AI System Operator) accounts receive the key by email once linked, and should return to app.jiminy.uk and paste it in when it arrives.
Either way, you will be prompted to enter your key the first time you visit the dashboard. Paste it into the field and press Access dashboard. The key is stored only in your browser's local storage. It is never sent to any server except as a request header when you call the Jiminy API directly.
To set your key for use in scripts and the terminal, export it as an environment variable:
export JIMINY_API_KEY="jiminy_live_xxxxxxxxxxxxxxxxxxxx"
You can verify it works with a quick health check:
curl -s https://jiminy-api-287920422190.europe-west2.run.app/me \ -H "X-API-Key: $JIMINY_API_KEY" | python3 -m json.tool
A successful response will include your tenant_id and account type.
Submit a trace
A trace is a structured record of one agent decision: the inputs it received, the tools it called, the reasoning it produced, and the output it returned. You send traces to Jiminy after your agent completes a task.
The trace is a JSON object. The minimum required fields are shown below. Send it with a POST to /evaluations:
import os, requests, json
JIMINY_API = "https://jiminy-api-287920422190.europe-west2.run.app"
API_KEY = os.environ["JIMINY_API_KEY"]
trace = {
"agent_id": "my-compliance-agent-v1",
"session_id": "session-2026-07-10-001",
"task": "Review supplier contract for renewal clause",
"steps": [
{
"step": 1,
"type": "tool_call",
"tool": "document_reader",
"input": {"doc_id": "contract-4872"},
"output": "Clause 14.3 requires 90-day written notice..."
},
{
"step": 2,
"type": "reasoning",
"content": "The clause has a 90-day notice window. Today is 2026-07-10. "
"The contract expires 2026-09-15. Notice deadline: 2026-06-17. "
"Deadline has passed, recommend escalation to legal."
},
{
"step": 3,
"type": "output",
"content": "Contract renewal window has closed. Escalating to legal team."
}
],
"final_output": "Contract renewal window has closed. Escalating to legal team.",
"tools_available": ["document_reader", "calendar_check"],
"declared_scope": "Read and summarise supplier contracts. Escalate renewal risks."
}
resp = requests.post(
f"{JIMINY_API}/evaluations",
headers={"X-API-Key": API_KEY, "Content-Type": "application/json"},
json=trace
)
result = resp.json()
print(json.dumps(result, indent=2))
You can also submit using curl with a saved JSON file:
curl -s -X POST https://jiminy-api-287920422190.europe-west2.run.app/evaluations \ -H "X-API-Key: $JIMINY_API_KEY" \ -H "Content-Type: application/json" \ -d @trace.json | python3 -m json.tool
OpenTelemetry and LangSmith users: If your agent framework already produces structured traces, you can adapt them into the Jiminy format without re-instrumenting your agent. Contact hello@jiminy.uk for format mapping guidance.
Read the results
The API responds synchronously with an audit verdict. A typical response looks like this:
{
"audit_id": "eval_01j9xk2m3n4p5q6r7s8t",
"agent_id": "my-compliance-agent-v1",
"session_id": "session-2026-07-10-001",
"verdict": "APPROVED",
"criteria": {
"C1": { "result": "PASS", "label": "Scope Adherence" },
"C2": { "result": "PASS", "label": "Tool Authorisation" },
"C3": { "result": "PASS", "label": "Escalation Judgement" },
"C4": { "result": "PASS", "label": "Output Traceability" },
"C5": { "result": "PASS", "label": "Data Boundary" }
},
"attestation_hash": "sha256:a3f8c1d...",
"evaluated_at": "2026-07-10T14:32:05Z"
}
The dashboard at app.jiminy.uk shows all your audits in the Audits tab, with per-criterion breakdowns, trend charts, and drift monitoring. You can also export your full audit ledger as CSV from the Audits tab.
Each audit is recorded with a tamper-evident attestation hash. You can use this hash to verify that the audit record has not been altered since it was issued.
Audit criteria
Every trace is assessed against six criteria. Each criterion receives a result of PASS, CONCERN, or FAIL. The overall verdict is derived from the combination of criterion results.
declared_scope.
tools_available.
Verdict glossary
The top-level verdict summarises the six criterion results:
| Verdict | Meaning | Typical action |
|---|---|---|
| APPROVED | All criteria passed. The decision trace meets accountability standards. | No action required. Record retained for audit. |
| FLAGGED | One or more criteria raised a concern. The decision was not clearly wrong, but warrants review. | Review the flagged criterion. Update agent configuration or escalation thresholds if needed. |
| REJECTED | One or more criteria failed. The trace contains a significant accountability gap. | Do not rely on this decision without human review. Investigate the failed criterion before redeploying. |
Note: Jiminy verdicts are produced by an automated audit system and are for accountability-record purposes. They do not constitute legal advice or regulatory clearance. Accountability reports should be reviewed by a qualified person before being relied upon in regulated contexts.
Trace format reference
The POST /evaluations endpoint accepts JSON with the following fields:
| Field | Type | Required | Description |
|---|---|---|---|
agent_id |
string | Yes | Identifier for your agent. Use a consistent name across runs for drift monitoring to work. |
session_id |
string | Yes | Unique identifier for this agent session or conversation. Use a UUID or timestamp-based ID. |
task |
string | Yes | Natural language description of the task the agent was given. |
steps |
array | Yes | Ordered list of steps. Each step has step (int), type (tool_call, reasoning, or output), and type-specific fields. |
final_output |
string | Yes | The agent's final response or action. |
tools_available |
array | Recommended | List of tool names the agent was permitted to use. Required for C2 (Tool Authorisation) audit. |
declared_scope |
string | Recommended | The agent's stated task boundary (its system prompt scope or equivalent). Required for C1 (Scope Adherence) audit. |
metadata |
object | No | Optional key-value pairs. Useful for tagging audits by environment, version, or user segment. |
For questions about the trace format or help adapting an existing observability pipeline, email hello@jiminy.uk with your tenant ID and framework name.