Kurtosys
Enterprise rule design
Rules that decide what a report shows
- Role
- Product Designer
- Client
- Kurtosys
- Year
- May 2026
- Tools
- Figma, Claude, HTML
The challenge
Rule logic is powerful and unreadable. How do you make it understandable without making it simplistic?
What it turned out to be
Plain English readback of every rule, in one component, wherever a rule appears.
Kurtosys automates investor reporting for asset managers. Inside its Documents module, rules decide which sections of a fund report appear, for which funds, for which audiences.
That sounds administrative until you look at what a section is. A risk warning. An ESG disclosure. A jurisdiction-specific disclaimer. Get the rule wrong and a regulatory disclosure goes missing from a document that has already reached an investor.
So the logic has to handle real regulatory conditions, and still be readable enough that whoever configures it knows what they have built. Those two pull against each other.
Process
Before designing screens, I needed to understand the system
Four levels down, from the platform to the two sections a rule can actually touch. Each level narrows the next.
- 01
Platform
Kurtosys Cloud, five modules
- 02
Module
Documents, where reports are automated
- 03
Document
A sequence of sections
- 04
Section
Two of them are rule touchpoints
Data comes in, rules shape the report, outputs go out
A sideways view before going further down. Rules sit between the data coming in and what a reader ends up seeing.
Inputs
- Fund admin systems
- Market data providers
- ESG / ratings data
- Risk & performance
- Document metadata
Documents / Rules
- Templates
- Conditional logic
- Production rendering
- Approval checks
Outputs
- PDF reports
- Investor portals
- Fund websites
- PowerPoint decks
- Email delivery
A document is a sequence, and only part of it is a rule's business
Level three. Opening a single report shows where a rule can and cannot reach. Most sections are fixed. Two are the reason this feature exists.
Which becomes three states a section can be in
The same document, as the template that generates it. Always, Optional, Conditional. Only the conditional rows can be touched by a rule.
Rules control
section visibility.
By the time I got to the screens, most of the decisions had already been made by the model underneath.
Where to design
Three surfaces, three states of mind
A rule gets written once, audited later, and questioned after a report has gone out. Those are three different jobs.
Rules Library
Auditing
Managing rules across the workspace. Which are live, where they are used, and which have quietly stopped working.
Inline Template Editor
Authoring
Writing a rule while editing the template it belongs to, with the section already in hand.
Production Preview
Debugging
A report has gone out and a section is missing. Working backwards from the render to the reason.
A · Authoring
Lock what the system already knows
The builder opens from inside a template, on a specific section, so the THEN clause is already known. Asking someone to restate it would be asking them to repeat themselves. Underneath, the rule is echoed back in plain English as it is edited.
B · Auditing
Rules as objects, not settings buried in templates
Once rules are shared across templates they need somewhere to live. Status, usage, last edited and health in one table, so a broken rule shows up before it reaches a report.
C · Debugging
Answer the question asked after the fact
The harder moment is a month later, when a section is missing from a delivered report and nobody can say why. The trace shows each condition against the data as it was at render time.
Systems thinking
Three calls that reach past this feature
Three decisions about the model underneath rather than the screens. Each one applies elsewhere in the platform.
Status is not health. Status is intent: Active, Draft, Archived. Health is reality: does this rule still run against the data that exists today? An Active rule whose field no longer exists is the urgent case, and one combined column would hide it. This applies to any object with a publishing lifecycle.
One readback, three contexts. The same plain-English echo appears in the builder, in the stress test and in the debug trace. The audience learns the pattern once and recognises it everywhere. Reusable in any form that produces a parseable rule.
Complexity earned, not toggled. The group affordance appears after three conditions exist, rather than always or never. No Advanced mode, so there is no second interface to maintain.
Proving the readback holds at scale
An echo that only works on simple rules is not much use, so I tested it on the worst realistic case I could find. A five-condition EU distribution rule across two groups joined by OR.
When should nesting admit it exists?
Most rules never need nested groups. The question was when to show the option, not whether to support it. Three options, compared on what each costs.
The states that finish a management surface
Empty, bulk selection and overflow. The states that decide whether the table holds up with real data in it.
What the mapping surfaced
- 01
Rule Builder belongs inside the Documents module
It sits with Templates, Production Centre, approval workflows and audit, not on its own
- 02
Data comes in from fund admin, market data, ESG and risk systems
Rules shape the report. Outputs go to PDFs, investor portals, fund websites, decks and email
- 03
A document is a sequence of sections and only some are rule touchpoints
Cover and disclaimers always appear. Risk warning and ESG highlights are conditional
- 04
Status and health answer different questions
Status is intent, health is whether the rule can still run against the data that exists today
- 05
The simple case dominates
Most rules are one or two conditions, so the interface should not be built for the tail
Outcome
Five decisions carried the work. Rules are human-readable, simple by default with advanced available when it is needed, reusable from a central library, connected live to the data dictionary, and backed by version history and an audit trail.
Six screens covered creation, management, debugging, behaviour at scale, the nested-groups decision, and the empty, bulk and overflow states.
Scope
What I deliberately left out
Each of these needs its own thinking, so I left them out rather than half-answer them.
- Bulk editing across templatesOut of scope
- Prebuilt rule templatesPhase two
- Advanced formula modePower-user track
- Permissions and governancePlatform layer
- Internationalisation supportPlatform layer
Reflection
What I took from it
- 01
Status is not health. Combining lifecycle and runtime into one column would hide the urgent case, an Active rule that can no longer run
- 02
One readback component across three contexts means the audience learns the pattern once and recognises it everywhere
- 03
Complexity should be earned rather than toggled. The group affordance appears after three conditions exist, so beginners never meet it and no second interface has to be maintained
- 04
Writing down what I left out, and why, saved re-arguing it later