Custom Checks & Validations

Standard design rules cover geometry and electrical correctness. Custom checks cover everything else – your company's standards, your industry's requirements, and your organization's institutional knowledge.

Altium's Behavior Extensibility framework lets you write custom validation logic in Python and connect it to platform checkpoints across the design lifecycle: ERC and DRC in Altium Designer, BOM and component validation, release gates, design review stages, and workflow steps on the server. Custom checks appear and behave identically to built-in platform checks – same UI, same error panel, same cross-probe to the affected component or net.

Checks are not sandboxed to Altium data. A check can call your internal parts database, your approved vendor list, your ERP system, or any external data source your validation pipeline depends on. The result is returned and surfaced in Altium Designer exactly like a native check result.

What Custom Checks are Actually For

Most organizations discover they need custom checks when they encounter a class of problem that keeps recurring despite existing DRC passing. Common examples:

• Voltage derating rules – specific to your product family or industry segment. Capacitors on low-voltage rails, electrolytic caps near heat sources

• Component qualification gates – parts from unapproved manufacturers, ITAR-controlled components, end-of-life parts that procurement has flagged

• BOM completeness rules – required parameters not populated, missing approved alternates, incomplete manufacturer data

• Release documentation requirements – specific output files that must exist and be current before a release is valid

• Organizational standards – that exist only in tribal knowledge, enforced inconsistently by whoever reviews the design

Custom checks move these from a review activity – dependent on the right person being available and remembering to look – into an automated gate that runs every time.

The Value of Encoding Knowledge into Checks

When a senior engineer writes a custom check, two things happen. The check runs automatically on every design going forward, regardless of who created it. And when that engineer leaves, the knowledge stays. This is the property that matters most at scale: institutional knowledge stops being hostage to headcount.

New engineers on your team automatically get the benefit of checks written by engineers with years of domain experience. The rule doesn't require explanation or review – it just runs.

What to Check and What Not to Check

Custom checks work well for deterministic, rule-based validation: conditions that are always true or always false given a specific design state. They are not a replacement for expert design review, simulation, or judgment-based evaluation.

A good candidate for a custom check is any rule that could be expressed as: "flag this component / net / parameter if condition X is true." A poor candidate is anything that requires contextual understanding, design intent interpretation, or tradeoff evaluation. Those still require human review. Custom checks are the automated floor that catches everything a machine can catch, so that human review time is spent on things only humans can catch.

Approaches That Do Not Scale

• Manual pre-release checklists – work for small teams with infrequent releases. Break when team size grows, release cadence increases, or the person who maintains the checklist is unavailable. Checklists are also invisible to the engineer during design – the feedback comes too late to be cheap to fix.

• Review-only enforcement – relying on design reviewers to catch standard violations means the same mistakes are caught repeatedly by the same people. It consumes expert time on deterministic problems, leaves earlier design stages unprotected, and creates inconsistent enforcement across reviewers.