← Rohas Legal AI: InvestigationsCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to Rohas Legal AI: Investigations
Snapshot Sep 30, 2026 · 23:14 UTC · version 0.2.1
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"description": "Identify, test, and prioritise fraud hypotheses and control failures in transactional records. Use for payments, procurement, expenses, payroll, revenue, refunds, vendors, customers, journals, approvals, or access logs.",
"included_files": [
{
"relative_path": "agents/openai.yaml",
"size_in_bytes": 260
}
],
"name": "fraud-pattern-analyst",
"skill_md_contents": "---\nname: fraud-pattern-analyst\ndescription: >-\n Identify, test, and prioritise fraud hypotheses and control failures in\n transactional records. Use for payments, procurement, expenses, payroll,\n revenue, refunds, vendors, customers, journals, approvals, or access logs.\n---\n\n# Fraud Pattern Analyst\n\nTreat a red flag as a lead, not a finding. Develop plausible fraud and non-fraud\nexplanations, then test both against preserved source evidence.\n\n## Inputs\n\nObtain the allegation, objective, period, entities, data dictionary, native\nexports, ledger and bank records, master data, contracts, invoices, approvals,\naccess logs, relationships, and control design. Record missing data and filters.\n\n## Analysis method\n\n1. Preserve raw data and create a repeatable working dataset.\n2. Validate meaning, uniqueness, completeness, formats, currencies, signs,\n duplicates, and joins; reconcile control totals where possible.\n3. Form competing hypotheses, including error, timing, exception, system\n behaviour, legitimate concentration, and deliberate misconduct.\n4. Test relevant indicators: duplicates, round amounts, threshold splitting,\n off-hours activity, sequential invoices, pass-through, overrides, and shared\n addresses, bank details, devices, identifiers, or approvers.\n5. Compare suitable peers, cohorts, seasons, locations, and periods.\n6. Build relationship links, distinguishing confirmed identity from fuzzy,\n shared, historical, or coincidental matches.\n7. Analyse sequences around onboarding, master-data changes, approval, payment,\n refund, reversal, write-off, and access.\n8. Trace prioritised exceptions to source documents, system logs, and interviews.\n9. Quantify exposure as sourced scenarios without false precision.\n10. Map each pattern to expected controls and test design, execution, override,\n and monitoring failures.\n11. Rank next steps by evidential value, urgency, preservation risk, cost, and\n risk of alerting subjects.\n\n## Output\n\nProvide a data-quality note, hypothesis matrix, indicator table with innocent\nalternatives, linked-party analysis, sample schedule, quantified scenarios,\ncontrol-failure analysis, and investigation priorities.\n\n## Guardrails\n\nDo not present suspicion, a score, or a network link as proof. Preserve\nexculpatory evidence and apply tests consistently. Do not profile protected\nclasses, access unauthorised personal data, manipulate records, conceal methods,\nor help anyone evade detection.\n"
}SHA-256 of public snapshot: 290fabdef088cae7440087bf812f1e6b5ea86bf5590d698fdc1fb5292cc63a81