How it works

Every AXA use case runs through the same governed loop. Nothing is bespoke code — each service is generated from a proven playbook and executed by the same engine.

1. Author. A compliance need (“track new regulations, map them to our frameworks and policies, flag the gaps”) is matched to a best-practice playbook — regulatory gap analysis, policy gap analysis, security-control gap analysis, or regulatory monitoring. The playbook brings a proven tool chain, quality gates, and a deliverable format.

2. Ground. The service can only use read-only capabilities freely (search, document extraction, retrieval). Anything that distributes or exports is reachable only through an approval-gated stage — never automatically.

3. Run. The service executes end to end against real sources — extracting requirements, retrieving the baseline, detecting gaps or changes, and drafting the deliverable.

4. Review & sign off. The outcome pauses at a human gate. A reviewer inspects the findings and their evidence, then signs — producing a signed deliverable with a content hash and full trace. Only then is anything distributed.

Why this matters for AXA

• Repeatable, not bespoke. New compliance work becomes a new service authored from the same governed playbooks — not a new project.
• Evidence-first. Every finding carries a citation to its source; the deliverable is built to be signed by an accountable owner.
• Safe by construction. Side-effecting steps (distribute, export) are always behind a human approval gate.

Note

The generic mechanics — playbooks, capabilities, approval gates, outcomes — are the same ones documented in the main Tredy docs. This site focuses on how they apply to AXA’s specific use cases.