The engineering problem
Technical requirements may depend on frequency, location, radio service or station characteristics. A single spreadsheet formula can hide those dependencies, and a rule change can leave older tools applying outdated logic.
Our engineering approach
We identify the applicable source documents and agree how each relevant requirement should be interpreted. We model conditions explicitly, separate rule data from application logic where practical, and create boundary cases for review. This can support ITU, ETSI or other applicable regulatory and technical methodologies within the agreed project scope.
What a project can deliver
- A source-to-rule mapping and versioned requirements
- Transparent decision logic with explanations
- Boundary-case and known-case validation
- A documented process for future rule changes
Start with one well-defined methodology or technical requirement and the cases needed to validate it.
What to bring to a first discussion
The applicable technical documents and versions, the clauses you want to implement, agreed interpretations and examples that exercise the rule boundaries. Note any requirements that depend on geography, radio service, frequency or station characteristics.
Questions about this service
How are changes to technical rules handled?
Rule versions and their sources should be retained with the results they produce. A change can then be reviewed against existing reference cases, with new boundary tests added where needed. This makes it possible to explain why an older study differs from one run under updated criteria.
Can ambiguous requirements be automated?
An unresolved interpretation should be surfaced for engineering review. Once the interpretation and scope are agreed, the relevant conditions can be represented explicitly in software. The tool should distinguish missing information and manual-review cases from a clear pass or fail.