Data validation without an engineering ticket

When validation rules sit in code, they sit in the wrong place. Domain knowledge — what is a plausible fuel consumption, a plausible waiting time, a plausible vendor scoring — belongs with the people who know the domain. But it rarely sits there, because the tooling is missing.

Why nailing rule logic into code fails

Domain drift is faster than release cycles. Aviation standards change, wet-lease partners come with their own rules, compliance frameworks get revisions, tolerance thresholds change after seasonal observations. If every one of these adjustments triggers a code change, testing, a release cycle, the system runs behind the business.

Domain experts and engineers speak different languages. A person who knows which fuel consumption is still realistic must phrase their rule in tickets, send it to an engineer, test the result, give feedback — and three weeks later the rule goes into production. The waiting time isn’t the problem. The translation is.

Audit requirements demand traceability. Who changed which rule when, with what reasoning. In a classical codebase: reconstructable via git history, but not verifiable without engineering effort. In a declarative rule set: a question of seconds.

How declarative rule sets shift this

Rules become configuration, not code. A validation check like “fuel consumption between source A and source B may deviate by at most 5%” doesn’t live in a Java class, but in a declarative rule entry. Updated at runtime, without deployment.

Domain experts maintain directly. With a domain-fitting editor — no code, no engineering ticket — tolerances, thresholds, classification logic are entered directly by the person holding the domain knowledge. Engineering remains responsible for platform mechanics. The rule logic sits with the domain.

Audit trail built in. Every rule change is versioned, traceable, commentable. The question “why did we lower the tolerance from 7% to 5% last May?” has an answer, not just a story.

Test mechanics before production. A rule that affects hundreds of thousands of data points wants to be tested against historical data first. Low-code platforms bring this along — dry run against past data, diff to current rule, then activation.

Where this runs productively in aviation operations

Fuel validation. Five data sources deliver six statements about the same value. The rule set consolidates: which source is leading when, which tolerance applies, when a discrepancy becomes an attention marker. Thousands of flights per day, without an engineer being addressed.

Wet-lease partner onboarding. New partners deliver data in their own formats and conventions. Instead of custom code per partner: a parser template plus validation rules are set up in days — by the person who understands the data convention.

Compliance framework updates. A NIST revision or a new NIS-2 clause is a configuration task, not a code migration. The engineering platform stays unchanged; the rule layer changes.

What used to be ticket backlog becomes self-contained domain engineering. Engineers focus on platform topics, domain experts on the domain. The friction at the hand-off point disappears.

If you have an operational system whose rules sit in code — the Tactical Assessment clarifies whether shifting that is the next lever.