The Version That Deletes the Cleverness

Every version of KC Star until now added something. More measures, more governance, more stars, more permissions, more intelligence. V9 was the peak of that accumulation — two fused engines, a group layer, a permission cache, the most capable and most complex version in the project. V9 Simplified does the one thing none of its predecessors did: it takes features away. No permission groups. No group cache. No per-employee-versus-per-group split. Just employees with direct permission lists. It is the version I would actually deploy, and this final series is why deleting cleverness is harder, and more valuable, than adding it.

The rarest release

Removing features is the hardest release to justify and the easiest to skip. Additive versions feel like progress; you can point at the new capability. A simplifying version feels like retreat — you are shipping less than last time. It takes a specific kind of confidence, usually earned by operating the complex thing, to look at a working system and decide that its cleverness costs more than it is worth.

That is exactly the judgement V9 Simplified makes about V9's permission groups. V9 solved a real problem — per-employee recalculation does not scale — with real machinery: PermissionGroups, PermissionGroupMappings, EmployeePermissionGroups, a group-keyed calculation path, and a permission cache with a TTL on top. All of it justified, layer by layer. And V9 Simplified looks at the whole tower and asks: what if we just… didn't?

What it deletes

The README states the rationale in plain terms — it “eliminates the complexity of permission groups while maintaining high performance and security” via Direct Permission Lists. Employees are assigned permissions directly, on EmployeePermissions. Gone:

• PermissionGroups — no group definitions.
• PermissionGroupMappings — no group-to-permission mapping.
• EmployeePermissionGroups — no employee-to-group assignment.
• The entire group-keyed calculation path from V9's files 03/04.
• The group permission cache and its TTL machinery.

What is left is dramatically smaller: PermissionTypes, HierarchyLevels, EmployeePermissions (with a JSONB FilterConditions), and a PermissionCalculationCache that caches something genuinely different. The schema shrinks; the mental model shrinks more. The full schema is part 2.

The README recommends starting here

The most striking thing is that V9 Simplified's own documentation tells you to prefer it. The README says, in as many words, “Start with V9 Simplified for most use cases. Only consider V9 Complex if you have very specific requirements for complex permission group hierarchies.” It quantifies the win as “90%+ reduction in permission management overhead,” and its comparison table rates the simplified version's maintenance overhead and complexity as Low against V9's High.

That is not how projects usually talk about their most advanced version. Normally the newest, most feature-rich release is the recommended one. Here, the simpler option is the default recommendation and the complex one is the special case. V9 and V9 Simplified are explicitly framed as deliberate alternatives, not a linear upgrade — two answers to the same problem, and the honest advice is to take the simpler one unless you have proven you need the other. I find that the most mature thing the whole project says about itself.

Why direct permissions are usually enough

The group model's justification was that permissions cluster — a thousand employees share seven roles, so compute per-role. That is true, and it is a real optimisation at a thousand employees. But most deployments do not have a thousand employees viewing the warehouse. They have a handful — five, fifty — and at that scale, the group indirection is pure overhead. You add three tables and a layer of “what group is this person in” indirection to save recomputation that, for fifty people, was never expensive.

Direct permissions collapse the model back to the obvious thing: a person has permissions, you check them, you compute their view. No group lookup, no group cache invalidation, no per-group-versus-per-employee decision. For the common case, it is not just simpler — it is faster to reason about, which is the kind of performance that does not show up in benchmarks but shows up every time someone has to debug or extend the system. The group model wins on a specific axis (many employees, high recalc volume) and loses on every other, and V9 Simplified bets, correctly I think, that most deployments live on the “every other.”

What it keeps

Simplification is only wise if it deletes cleverness and keeps correctness, and V9 Simplified is disciplined about the line. It keeps everything that was right: the inverted schema, SCD2, time travel, the dependency-driven recalculation from V8 (in a simplified form), and — crucially — the NULL-means-redacted semantics from V9, because that is correctness, not complexity. It deletes only the machinery: groups, the group cache, the dual implementation. Telling those apart — cleverness to cut, correctness to keep — is the entire skill of a simplifying release, and it is part 6's retrospective theme.

Where the series goes

1. The version that deletes the cleverness — this post.
2. Direct permissions, no groups — the shrunken schema, the five personas, and GetFilteredSalesData.
3. A permission gate inside every measure — HasPermission called inline, row filtering versus column masking.
4. Caching calculations, not permissions — caching results instead of yes/no answers, and why that is the better choice.
5. The wishlist — four engines I haven't built — the future-work folder, honestly.
6. Nine versions later — what the star taught me — the retrospective on the whole project.

This is the version I would deploy, and the next post is what deploying it actually looks like: a small schema, five personas, and permissions you can read in one table.