Config-driven Compliance Questionnaire Engine

Compliance questionnaires tend to start life hardcoded into application logic and then slowly turn into an engineering tax. Every policy change becomes a code change. Every audit question becomes a hunt through controller logic and conditionals. This POC asked whether we could move that logic into a structured, versioned configuration model without losing auditability.

The interesting part was not whether the UI could render dynamic questions. That part is relatively easy. The harder question was whether the configuration itself could stay understandable once conditional exclusions, versioning, scoring, and policy churn all showed up together.

Using PostgreSQL and Rails, we modeled questionnaire structure relationally. That let us version configurations, define dependencies between questions, express conditional exclusions, and tie answers into risk scoring. In plain terms, it gave us a way to ask later: which version was active, why was this question shown, why was that one skipped, and how did this result get calculated?

That is the line between a useful internal feature and something that can survive audit pressure.

The trade-off was giving up some speed and casual flexibility. Hardcoded flows are faster at the start. A config-driven engine needs stronger validation, cleaner admin workflows, better tooling, and more discipline around who changes what. But that is also the point. If the domain is sensitive, uncontrolled flexibility is not really a benefit.

I liked this POC because it raised the bar instead of just proving a trick. It did not answer "can we make dynamic forms?" It answered "what kind of structure do we need if we want dynamic behavior without creating a compliance mess later?"