The problem
Removing access is easy to describe as a permissions change. The harder question is what the organization can no longer do afterward. A role might be the only thing keeping a time-sensitive business workflow covered.
RoleImpact models employees, roles, permissions, capabilities, and workflow requirements together so an access change can be evaluated in terms of its operational consequences.
What I built
I designed and built the React and TypeScript interface, Spring Boot REST API, object-oriented Java impact-analysis engine, and PostgreSQL persistence layer. The application connects an interactive organization model to deterministic backend simulations so users can trace why a workflow is affected and compare possible mitigations.
From change to consequence
A user opens an organization model, removes a role, and runs an impact simulation. RoleImpact traces the affected relationship paths from employee access through permissions and capabilities to business workflows.
The user can then evaluate a replacement, compare the original and mitigated results, and inspect the evidence behind each recommendation. Because the engine is deterministic, identical organization states and changes produce identical results.
Architecture
- React + TypeScript: interactive organization modeling, impact visualization, relationship paths, and before-and-after comparisons.
- Java 21 + Spring Boot: REST API and application services for organization models, impact simulations, mitigation scenarios, and saved drafts.
- Deterministic Java impact engine: evaluates access changes against immutable organization snapshots, traces affected workflows, produces stable result hashes, and ranks eligible mitigation options.
- PostgreSQL + Spring Data JPA + Flyway: stores organization data and simulation relationships while maintaining versioned database migrations.
- JUnit + Testcontainers: validates application and persistence behaviour against real PostgreSQL container instances rather than relying only on mocked database tests.
- Docker: provides a reproducible local PostgreSQL environment and consistent development setup.
Engineering challenges
A replacement recommendation cannot simply match a role name. It must satisfy the permissions and capabilities required by the affected workflows while actually restoring coverage. That required recommendation logic to operate on the same domain model used by the impact engine rather than relying on superficial similarity.
Another challenge was making simulation results reproducible. Organization state is assembled into immutable snapshots, allowing the engine to compare original and alternative scenarios without mutating the underlying model. Stable result hashing also makes equivalent simulations identifiable.
The interface also needed to explain relationship-rich results without making a graph the only way to understand them. RoleImpact therefore exposes textual relationship paths and rule-based evidence alongside the visual representation.
Result and scope
RoleImpact demonstrates an end-to-end workflow from an access change to an evidence-backed impact explanation and tested mitigation. Simulations can be persisted and compared while organization data remains available across sessions.
The application is a portfolio simulation using synthetic organization data. It does not connect to production identity providers or modify real permissions, and it is not intended for confidential organizational data.
What the project taught me
The biggest design lesson was that explainability has to exist in the domain model and engine but not be added only in the interface. A useful result needs to preserve the relationship path and rule that produced it so the frontend can explain why a workflow was affected and why a mitigation is valid. The project also reinforced the value of deterministic state, explicit domain models, database-backed integration testing, and designing APIs around business behaviour rather than UI screens.