Feature · CI Quality Gates

Stop a bad SDC change before it merges

Every time someone changes a constraint, Ṛta automatically checks it in CI. If the change violates your quality rules, the merge is blocked. Same rules, same standard, for every engineer.

In plain words

What does "gate merges on lint-clean constraints" mean?

It means Ṛta can automatically stop a bad or invalid SDC change from being merged into the main codebase.

What is CI? CI = Continuous Integration. Whenever someone submits a code change to GitHub, CI automatically runs checks before that change can be accepted. For Ṛta, those checks include validation, lint, and constraint quality rules.

What does "lint-clean" mean? A linter examines an SDC for constraint-quality problems: malformed syntax, inconsistent style, unsupported constructs, missing patterns, duplicate or conflicting constraints, bad naming, and project-specific policy violations.

Developer changes SDC rule/code ↓ GitHub ↓ CI starts ↓ Run Ṛta validation ↓ ┌───────┴───────┐ PASS FAIL ↓ ↓ Merge allowed Merge blocked

Real-world example

A 20-engineer STA/PD team

Imagine 20 engineers on the same project. Engineer A writes a clock constraint. Engineer B adds another. Engineer C modifies a generated SDC. Engineer D changes a clock. Without CI, one bad constraint can slip in and nobody notices until much later.

✓With CI: every change runs through the same checks. A violation blocks the merge on the spot, with the exact rule codes (SDC-023, SDC-041, SDC-067...) shown to the engineer.
✓The repo becomes the quality gate. The standard isn't a document anymore; it's enforced automatically.
PR #142 - Update DDR timing constraints ✓ SDC syntax ✓ Constraint lint ✓ Clock validation ✓ Coverage ✓ Conflict detection ✓ Readiness ✓ Regression comparison Result: PASS - merge allowed PR #143 - Modify clock constraints ✓ Syntax ✓ Lint ✗ Clock validation - 3 new violations SDC-023 · SDC-041 · SDC-067 Result: FAIL - merge blocked

The important part

"The same standard for everyone"

Before CI, rules are just documentation

"Every generated SDC must satisfy these 50 quality rules" is a sentence in a doc. One engineer follows it, another doesn't. Quality depends on memory and mood.

With Ṛta CI, rules are enforced

Every engineer is evaluated by the same deterministic rules, every time. Trust through deterministic verification, not human assumption.

An important distinction

CI should have different levels of gates, not one "pass everything" wall:

Gate 1 · Lintfast, structural

Is the SDC structurally and stylistically acceptable?

Gate 2 · Validationsemantic

Are the constraints semantically valid?

Gate 3 · Policyproject-specific

Does this comply with your team's policies?

Gate 4 · Regressionchange impact

New violations? Coverage worse? Readiness regressed?

Where it runs

First-class CI, no AI required

Try it

Gate your constraints

CI-ready command
$ rta check your_block.sdc --json --output results.json
$ rta check your_block.sdc --baseline base.json --gate STRICT # regression gate
$ rta lint --check your_block.sdc # fast formatting gate
Try it in the app ↗ All features