Selected systems,
in production.

The problem

Generic ATS platforms optimize for the recruiter's clicks, not the hiring team's reality. Hiring managers were managing scorecards in side documents; candidates had no visibility into where they stood; interview scheduling was a three-party email chain; background checks, I-9s, and offer logistics lived in different systems with no audit trail tying them together.

What was built

• End-to-end ATS spanning intake, screening, scheduling, evaluation, offer, and onboarding handoff — one system, one source of truth
• Applicant-facing interface with step tracking, self-scheduling against hiring manager availability, and direct communication channels
• AI-driven resume analysis comparing each application against the job description — flagging congruence, divergence, red flags, and suggested follow-up questions on job-relevant areas
• Standardized hiring scorecards enforced across managers, producing defensible documentation for every hiring decision
• Integrated background check, I-9 verification, and external recruiting platform connections, with movement of every applicant fully auditable

Architecture choices worth noting

The system was designed around three audiences with different needs — HR, hiring managers, and applicants — each receiving an interface calibrated to what they actually do. AI resume analysis was scoped to augment the human screening decision, not replace it: every flag is explained, every comparison is grounded in the job description, and the final call is always a person's.

The problem

Employee information was spread across multiple drives, shared folders, and email chains. Reporting required reconciling the same data from three or four different files. Regular processes — onboarding, status changes, role transitions, separations — meant emails moving back and forth between HR, managers, and employees, with the number of files and touch-points growing exponentially as the company grew. Information went missing. The same questions got asked twice.

What was built

• Unified HR/Employee platform consolidating personnel data, documents, and process state into a single auditable source
• Self-service surfaces for employees — transparency into their own records, statuses, and pending actions
• Structured workflows replacing email back-and-forth for routine HR processes
• Uniform data schema eliminating the multi-file reconciliation that reporting had previously required
• Designed to grow with the firm — adding states, roles, or new processes is a configuration change, not a rebuild

Architecture choices worth noting

The system was deliberately built to be transparent to employees, not just useful to HR. Employees can see what HR sees about them — which produces better data, fewer questions, and a workforce that trusts the system because nothing is hidden in it. Compliance and audit-trail requirements were treated as first-class schema concerns, not bolted on later.

The problem

HR teams document policies. They write FAQ sheets. They maintain handbooks and benefits guides. And then they spend hours each week answering questions whose answers are already in those documents. The documents exist. The answers exist. The bridge between an employee with a question and the document with the answer was still HR's inbox — and HR's time was the bottleneck.

What was built

• Custom AI assistant trained against the firm's actual documentation — employee handbook, hand-tailored FAQ, policy documents, benefits information and supporting materials
• Designed to answer the recurring, high-frequency questions that consume HR time without consuming HR judgment
• Intelligent routing layer: queries the assistant isn't equipped to handle, that require the human touch, or that surface a request or notification beyond Q&A — are escalated directly to HR stakeholders
• Escalations arrive with the original query, the surrounding context, and the routing reason — so HR can respond quickly and accurately without first having to ask three follow-up questions
• The corpus is editable: as policies evolve or new FAQ enters the wild, the assistant's source of truth evolves with it

Architecture choices worth noting

The assistant is grounded in the firm's own documentation — not general internet HR advice, not a generic LLM's training data. This is the Mímir-class signature: AI built on the corpus you already wrote, answering questions in your voice, citing the policies you actually wrote. The routing layer is what makes the system trustworthy at scale — the assistant doesn't pretend to handle what it can't. It hands off, with context, to the human who should. The goal was never to replace HR's judgment; it was to free HR's time for the questions that actually require it.

The problem

FMLA tracking sits at the intersection of regulatory exposure, employee dignity, and operational coordination — and most employers treat it as a paperwork problem to solve with a spreadsheet. The result is opaque to employees, frustrating for leads who need to plan coverage, and a compliance liability for HR. The information is the same; the people who need to see it have different needs.

What was built

• FMLA tracking system with three distinct interfaces — one for the employee on leave, one for their lead, one for HR and leadership
• Eligibility, certification, and intermittent-leave tracking handled in-system, with documentation and audit trail tied to each leave instance
• Status visibility calibrated to each audience — employees see their own leave standing; leads see what they need to plan coverage; HR sees the compliance picture
• Designed to handle multi-state variation in leave law, with state-specific overlays where state benefits exceed federal FMLA

Architecture choices worth noting

Three-audience design isn't decorative — it's the entire point. Most leave systems are built for HR to administer, and then bolt on partial visibility for employees and managers. This one was designed from the start around the question "what does each person in this process actually need to see and do?" The compliance posture is a property of the system, not a separate checklist HR maintains.

The problem

Two operational patterns were quietly consuming the HR function's week. First: reports that the HRIS ecosystem didn't natively produce — reports requiring data from multiple sources, cleaned, cross-referenced, and assembled by hand each cycle, then distributed to the right stakeholders. Second: HR requests arriving by email, missing the information needed to act on them, generating a second round of email to gather it, then a third to confirm, then a fourth when the wrong person was looped in.

What was built

• Reporting pipeline producing reports the HRIS couldn't natively generate — multi-source data assembly, cleaning, and reconciliation handled automatically, with refreshable scheduled distribution
• Structured HR request system enforcing complete-information intake — every event type captures what's needed up-front, including required approvals and routing
• Audit trail and direct-communication threads attached to each request, replacing the email chain entirely
• Both systems were designed to be modular and additive — new report types or request types can be added without rebuilding the system

Architecture choices worth noting

The HR request system isn't a ticketing tool. It's a structured intake layer that solves the actual problem — requests arriving without the information needed to act on them. By enforcing the right schema at the moment of intake, the system eliminates the follow-up rounds that previously consumed the most time. The reporting pipeline applies the same principle to data: define the shape once, source it correctly, and let the report be produced as a consequence of the data being right.