Deterministic logic
Same inputs, same result, every time. No model drift, no probability, just fixed logic.
Rules-based screening and assessment
Know whether you need to notify before the filing work starts.
A rules engine that takes your facts, applies encoded logic and returns a traceable first-pass result. Regulatory screening is the first application.
Two live regulatory packs you can test now.
Illustrative engine run
Inputs
Australian nexusTarget connected with Australia: Yes
ControlAcquirer controls after completion: Yes
RevenueCombined Australian revenue: A$350m
Rules and paths
Australian nexus engaged
Control threshold engaged
Revenue threshold engaged
No obvious carve-out selected
Threshold routeAdvisory route
Indicative result
Indicative onlyCCA Acquisition Screening
Likely notification required
The illustrated facts point to a notifiable acquisition that should be checked before completion.
A quick check of nexus, control, revenue and obvious carve-outs before filing work starts.
Visible reasoning
Every result shows which rules fired and why, so the outcome is explainable and auditable.
Faster triage
Automate the threshold checks so expert time goes to the questions that need judgement.
Any question narrow enough to encode and important enough to explain.
Regulatory thresholds are the starting point. The same engine pattern applies to internal policies, eligibility checks, compliance triage and any other decision that follows a fixed logic path.
Ask for the facts that matter.
Keep the intake tight. Ask for the inputs that drive the decision and leave the rest out.
Show the route, not just the answer.
A first-pass result is more useful when people can see which route won and where uncertainty still sits.
Embed it where the question gets asked.
Whitelabel a pack as a client-facing tool, an internal triage step or a business development entry point.
Built for questions with a right answer.
Works best where the logic is encodable and the outcome matters enough to explain properly.
Inputs, rules, paths, verdict.
Every pack follows four steps. Inputs flow through rules, resolve to a path and produce a traceable result.
Inputs
Ask for the facts that drive the threshold question. Keep the intake tight and the inputs reviewable.
Rules
Apply the pack logic in a fixed order. Same facts, same result, every time.
Paths
Resolve the route that drives the outcome and surface the alternatives.
Verdict
Return a clear first-pass view with the right caveats, not a black box answer.
Step 1
Structured intake
Each pack asks for the facts the engine actually needs, not a loose narrative.
Who it's for.
Lawyers
Run a structured first pass on threshold questions. See the logic path that produced the result and focus your time on the points that still need judgement.
Advisers
Give clients a consistent, traceable triage view early. Embed or whitelabel a pack as a client-facing screening tool, or use it to surface the matters that need your detailed assessment.
Compliance teams
Standardise how your team runs recurring checks. The same logic, the same inputs, the same traceable result every time, whether it is a regulatory filing question or an internal policy screen.
Business teams
Understand whether a filing obligation or policy requirement is likely before you allocate budget and time. The result comes with the reasoning, not just a yes or no.
Live packs
Two regulatory packs, one engine.
Two live packs demonstrate the engine on real regulatory questions. The same pattern extends to any rules-to-outcome problem.
Lead proof of concept
CCA acquisition screening
Test whether a proposed acquisition likely triggers a mandatory notification obligation under Part IVA of the Competition and Consumer Act 2010 (Cth). The pack checks nexus, control, revenue thresholds and obvious carve-outs.
Second proof of concept
Modern slavery reporting
Test whether an entity is likely to be a reporting entity under the Modern Slavery Act. The pack checks business presence, revenue thresholds and exclusions.
Common questions
Short answers, in plain terms.
The engine is the underlying rules system. It takes structured inputs, applies encoded logic in a deterministic order and shows the reasoning path that produced the result. A pack is one specific application of that engine to a defined question or scenario, with its own inputs, rules and outcome. For example, the CCA Acquisition Screening is one pack and the Modern Slavery Reporting Entity Screening is another. The engine is the method. The pack is the individual tool built on that method. We are considering what packs to add next and welcome suggestions and feedback.
Try a live pack
Pick a pack and see the engine work through a real regulatory question.