Policy Diff Engine

Policy Diff Engine

Project Overview

Not every engagement is about writing the code yourself. This one was architecture and mentorship: helping a junior developer design and build a backend that compares policy documents over time and reports the changes in a way that's actually useful to the people who have to act on them.

The Challenge

• Naive Diffing Produces Noise: A generic line-by-line text diff on a policy document is close to unreadable — reformatting alone can make it look like everything changed
• Department Relevance: Changes needed to be grouped by which department's policy area they belonged to, not presented as an undifferentiated list
• Junior Developer, Senior Problem: The engineer building this needed architectural direction on how to approach the comparison problem, not just a spec to implement

Technical Solution

Structure-Aware Comparison

Rather than treating a policy document as plain text for diffing purposes, the architecture called for comparing at the level of the document's actual structure — sections and provisions — so a detected change reads as "this specific provision changed" instead of a wall of reformatted text.

Department-Grouped Reporting

Changes are grouped by the department responsible for the relevant policy area before the report is generated, so a reader gets a report relevant to their part of the organization rather than the entire document's changelog.

Mentorship-Led Implementation

My role was architecture and design guidance — establishing the comparison approach, the grouping logic, and the report structure — while the junior developer owned and shipped the actual implementation.

Results and Impact

• A working diff engine that produces department-relevant, readable change reports instead of raw text diffs
• A junior developer who shipped it independently, with the architecture holding up under real implementation
• A repeatable comparison approach that generalizes beyond the first set of policy documents it was built for

Key Learnings

Some of the highest-leverage work is architecture and mentorship rather than code you write yourself — the diff engine's real value came from deciding how to compare documents (structurally, not as plain text) before any implementation started. Getting that decision right up front is what let someone else build it correctly.