Kuan Wu
← Work

IRALOGIX, Inc.

2026 · Current

Retirement-Plan Compliance Engine

State retirement mandates are spread across official websites and statutes, and each state asks different questions. The engine gives compliance staff a governed way to maintain those rules, then lets IRALOGIX products run employer sessions against an exact approved version.

Tech stack
Python · FastAPI · PostgreSQL · Event sourcing · OAuth2/OIDC · Auth0 · Kubernetes
Operating context
20+ state programs in scope · Portal + API in the Studio environment · Five-person CMU team, no production traffic
Role
Team Lead and system architect, five-person CMU Studio team
Ownership
Product discovery, review workspace, rule registry, session engine, and client integration boundary.

System context

Work I built or ledSurrounding contextDesigned path
IRALOGIX retirement-plan compliance engine system contextOfficial state sources feed a designed source-ingestion worker. Compliance and administrative staff use the review workspace. Employer and customer teams use the existing IRALOGIX product, which will integrate with the engine. All clients cross one authenticated API boundary. Inside the engine, candidate rules pass an attributed human approval gate before becoming approved versions. Employer sessions run against those versions and produce reports and alert events.STAKEHOLDERS AND SOURCESOfficial state sourceswebsites · statutesCompliance teamreviews rule versionsAdmin teammanages accessCustomer team and employersonboarding and guidanceCLIENTS AND AUTOMATIONGoverned rule reviewSource-ingestion workerfetch · diff · parseDESIGNEDGoverned rule reviewReview workspacehuman UI · agent MCP · test sessionsAuthenticated integration boundaryIRALOGIX productemployer-facing integrationINTEGRATION IN PROGRESSAuthenticated integration boundaryAUTHENTICATED API BOUNDARYinternal writesreview + administrationsessions + signed eventsRETIREMENT-PLAN COMPLIANCE ENGINEGoverned rule reviewCandidate rule bundleversioned · source-linkedGoverned rule reviewHumanapprovalGoverned rule reviewApproved rule versionactive · supersedableEvent-sourced employer sessionsEmployer sessionsappend · replay · forkAuthenticated integration boundaryReports + alertssigned event delivery
Stakeholders sit above the interface they use. Highlighted areas are work I built or led. The review workspace and engine run in the Studio environment; scheduled source ingestion and the final IRALOGIX integration are shown as designed paths.

Selected ownership

01

Product direction under ambiguity

Led product discovery from ambiguous requirements to a shared product direction, aligning client stakeholders and a newly formed five-person team on an integration-ready platform architecture.

02

Governed rule review

Architected the source-to-review lifecycle and built the review workbench: AI-assisted ingestion can stage a source-linked bundle, but only an attributed compliance decision can activate it.

How one rule stays traceable

Stable node IDemployee_count

RULE MODEL

Versioned valueheadcount_threshold: N

Stores the interpreted fact used by the engine.

DECISION GRAPH

Question and gateask employee_count

References the value instead of copying it into flow logic.

CONTENT CATALOG

User-facing wordingemployee_count.prompt

Versions wording and locale separately from rule behavior.

PROVENANCE

Source evidencerule path + citation

Connects the interpretation to its URL and quoted source.

Candidate bundleAttributed human decisionApproved version
Illustrative field names, not client rule data. The schema limits what a human or agent can propose; the attributed review decision determines what the engine may treat as authoritative.
03

Event-sourced employer sessions

Designed and implemented the API-to-engine session path: append-only answers are projected against a pinned rule bundle, enabling resume, rewind, and fork without mutating prior history.

Append-only session history

Append-only employer session eventsA session is pinned to one approved rule version. Replaying the main event sequence resumes or rewinds the session. Appending a different answer from an earlier event creates an alternative branch and report without overwriting the original history.PINNED RULE VERSIONSessionstartedAnswerappendedAnswerrewind pointAnswerappendedDifferent answernew branchCurrent resulteligibility state · reportAlternative resultoriginal history remainsRESUME replay to the latest eventREWIND replay to an earlier eventFORK append a new branch
04

Authenticated integration boundary

Designed one API boundary for human, agent, and system clients, with separate JWT trust paths, client-scoped authorization, and signed outbound webhooks.

Two trust paths, one authorization model

Authenticated integration boundaryThe review portal and IRALOGIX systems present OAuth tokens. Internal workers present separately issued Ed25519 tokens. The same middleware verifies the issuer and identifies the client, then a local registry decides whether that client is enabled and which scopes it holds before the request reaches the API.CALLERSCREDENTIALVERIFYAUTHORIZEROUTEPortal UI + MCPone scoped M2M clientIRALOGIX systemsexternal clientsInternal workersscheduled write-backOAuth2 / OIDC JWTAuth0 or stand-in issuerEd25519 JWTinternal issuerAuth middlewareverify signature + issueridentify the clientClient registryenabledgranted scopesScoped APIexternalinternalAuthentication proves the caller.Registry data grants or revokes power.
The portal is deliberately an ordinary client rather than a privileged side channel. If a workflow cannot be completed through the scoped API, the integration contract is incomplete.

IRALOGIX sponsors this year-long CMU Studio project. I lead product direction and architecture and built major engine, API, and Portal slices on a five-person student team; this page does not imply sole authorship. The system runs in a Studio environment and has no production traffic. Dashed elements are designed or integration paths, not launched product behavior.