arclangProduction gate
arclang gate answers one question: can this architecture dossier go to a design review? It returns PASS or FAIL, lists each blocker with the check that raised it, and exits with a non-zero code on FAIL. The verdict is deterministic and computed offline: the same model always gives the same answer.
$ arclang gate examples/automotive/emergency-braking/complete_emergency_braking_simple.arc --standard iso26262
Production-readiness gate (ISO26262) — examples/automotive/emergency-braking/complete_emergency_braking_simple.arc
Requirements: 7 total, 7 satisfied, 7 verified
Constraints: 1 declared, 1 hold
PRODUCTION GATE: PASS ✓What the gate checks
| Check | Blocker when |
|---|---|
requirements.presence |
The model has no requirement |
requirements.satisfaction |
A requirement is satisfied by no architecture element (no satisfies trace) |
requirements.verification |
A requirement has no test_case that verifies it, or one of its cases fails: a constraint an analysis asserts does not hold, or a test says verdict: "fail" |
verification.dangling |
A test case verifies a requirement that does not exist |
safety.hara |
Elements declare an integrity level but the model has no hazard, or a hazard lacks its classification |
safety.asil |
A hazard's declared ASIL contradicts the ISO 26262 table for its severity, exposure and controllability |
safety.dal |
With --standard do178c: a hazard's declared DAL contradicts its failure condition |
safety.mitigation |
A hazard has no mitigating requirement, or names one that does not exist |
timing.latency |
A latency is not a time |
timing.budget |
The latencies of a functional chain exceed its latency_budget, or a function of the chain declares none |
icd.completeness |
A physical exchange lacks its carrying link, frequency or message type, or a link declares no protocol |
constraints.violated |
A constraint evaluates to false |
metamodel.types |
A typed attribute holds a value of the wrong type |
The gate also raises warnings that do not fail it: a latency written without a unit (timing.units), a functional chain with no budget, and the methodology advisories of arclang check --lint.
A failing dossier
This model compiles. It is not ready: the chain overruns its budget, the hazard's ASIL is understated, and one requirement is neither satisfied nor verified.
operational_analysis "Driving" {
actor "Driver" { id: "ACT-DRIVER" }
}
system_analysis "Braking" {
requirement "REQ-001" { description: "Brake within 100 ms of detection" safety_level: "ASIL-D" }
requirement "REQ-002" { description: "Warn the driver before braking" safety_level: "ASIL-B" }
function "Detect obstacle" { id: "SF-DET" latency: 60 ms }
function "Command braking" { id: "SF-BRK" latency: 55 ms }
functional_chain "Detection to braking" {
involves: ["SF-DET", "SF-BRK"]
latency_budget: 100 ms
}
}
logical_architecture "Components" {
component "Brake controller" { id: "LC-BRAKE" safety_level: "ASIL-D" }
}
trace "LC-BRAKE" satisfies "REQ-001"
test_case "TC-001" { verifies: ["REQ-001"] method: "test" }
safety_analysis {
hazard "Late braking" {
severity: "S3"
exposure: "E4"
controllability: "C3"
asil: "ASIL-B"
mitigated_by: ["REQ-001"]
}
}$ arclang gate not_ready.arc
Production-readiness gate (ISO26262) — not_ready.arc
Requirements: 2 total, 1 satisfied, 1 verified
✗ 4 blocker(s):
[requirements.satisfaction] requirement 'REQ-002' is satisfied by no architecture element (no satisfies trace)
[requirements.verification] requirement 'REQ-002' has no verification case (test_case verifies: [...])
[safety.asil] hazard 'Late braking': declared ASIL 'ASIL-B' contradicts ISO 26262 table (S3 E4 C3 => ASIL-D)
[timing.budget] functional_chain 'Detection to braking': sum of function latencies 115.0 ms exceeds the 100.0 ms budget
⚠ 1 warning(s):
[methodology] logical component 'Brake controller' performs no functions — Arcadia expects logical components to realize behavior
PRODUCTION GATE: FAIL ✗ (4 blockers)
Error: Compilation error: production gate failed with 4 blocker(s)Each line names the check, the element and the reason. Nothing here is a matter of opinion: the sum of two latencies, a table lookup, and the presence of a trace.
Standards
--standard selects how hazards are read.
iso26262(default): each hazard needsseverity(S1 to S3),exposure(E1 to E4) andcontrollability(C1 to C3). The gate computes the ASIL with the table of ISO 26262-3 and compares it with the declaredasil.do178c: each hazard needs a failure condition (catastrophic,hazardous,major,minororno_effect), given asconditionorseverity. The gate derives the DAL and compares it with the declareddal.iec61508: the requirement, verification, timing, interface and constraint checks apply. In this version hazards are read with the same severity, exposure and controllability fields as ISO 26262.
operational_analysis "Flight" {
actor "Pilot" { id: "ACT-PILOT" }
}
system_analysis "Pitch control" {
requirement "REQ-FCS-001" { description: "Pitch command shall be computed every 10 ms" safety_level: "DAL-A" }
}
logical_architecture "Components" {
component "Flight control computer" { id: "LC-FCC" safety_level: "DAL-A" }
}
trace "LC-FCC" satisfies "REQ-FCS-001"
test_case "TC-FCS-001" { verifies: ["REQ-FCS-001"] method: "analysis" }
safety_analysis {
hazard "Loss of pitch control" {
condition: "catastrophic"
dal: "DAL-A"
mitigated_by: ["REQ-FCS-001"]
}
}$ arclang gate avionics.arc --standard do178c
Production-readiness gate (DO178C) — avionics.arc
Requirements: 1 total, 1 satisfied, 1 verified
⚠ 1 warning(s):
[methodology] logical component 'Flight control computer' performs no functions — Arcadia expects logical components to realize behavior
PRODUCTION GATE: PASS ✓Rules
Everything check and the gate report is a rule of the catalog: an identifier such as trace.requirement or metamodel.type, a severity, what it means and how to answer it. arclang check --json names the rule of every finding, the element concerned and, when one can be named, the edit that answers it; the playground's Problems view opens that edit.
$ arclang check --json examples/automotive/emergency-braking/complete_emergency_braking_simple.arc
{
"errors": [],
"file": "examples/automotive/emergency-braking/complete_emergency_braking_simple.arc",
"findings": [],
"metrics": {
"components": 20,
"functions": 17,
"requirements": 7,
"traces": 15
},
"realization": [
{
"name": "Obstacle detection range",
"requirement": "REQ-AEB-001",
"stages": [
{
"stage": "simulation",
"state": "n/a"
},
{
"stage": "sil",
"state": "n/a"
},
{
"stage": "pil",
"state": "n/a"
},
{
"stage": "hdl",
"state": "n/a"
},
{
"stage": "soc",
"state": "n/a"
},
{
"stage": "board",
"state": "n/a"
},
{
"stage": "twin",
"state": "n/a"
}
]
},
{
"name": "Sensor fusion latency",
"requirement": "REQ-AEB-002",
"stages": [
{
"stage": "simulation",
"state": "n/a"
},
{
"stage": "sil",
"state": "n/a"
},
{
"stage": "pil",
"state": "n/a"
},
{
"stage": "hdl",
"state": "n/a"
},
{
"stage": "soc",
"state": "n/a"
},
{
"stage": "board",
"state": "n/a"
},
{
"stage": "twin",
"state": "n/a"
}
]
},
{
"name": "Collision risk assessment",
"requirement": "REQ-AEB-003",
"stages": [
{
"stage": "simulation",
"state": "n/a"
},
{
"stage": "sil",
"state": "n/a"
},
{
"stage": "pil",
"state": "n/a"
},
{
"stage": "hdl",
"state": "n/a"
},
{
"stage": "soc",
"state": "n/a"
},
{
"stage": "board",
"state": "n/a"
},
{
"stage": "twin",
"state": "n/a"
}
]
},
{
"name": "Emergency braking activation",
"requirement": "REQ-AEB-004",
"stages": [
{
"stage": "simulation",
"state": "n/a"
},
{
"stage": "sil",
"state": "n/a"
},
{
"stage": "pil",
"state": "n/a"
},
{
"stage": "hdl",
"state": "n/a"
},
{
"stage": "soc",
"state": "n/a"
},
{
"stage": "board",
"state": "n/a"
},
{
"stage": "twin",
"state": "n/a"
}
]
},
{
"name": "Driver warning",
"requirement": "REQ-AEB-005",
"stages": [
{
"stage": "simulation",
"state": "n/a"
},
{
"stage": "sil",
"state": "n/a"
},
{
"stage": "pil",
"state": "n/a"
},
{
"stage": "hdl",
"state": "n/a"
},
{
"stage": "soc",
"state": "n/a"
},
{
"stage": "board",
"state": "n/a"
},
{
"stage": "twin",
"state": "n/a"
}
]
},
{
"name": "Driver override",
"requirement": "REQ-AEB-006",
"stages": [
{
"stage": "simulation",
"state": "n/a"
},
{
"stage": "sil",
"state": "n/a"
},
{
"stage": "pil",
"state": "n/a"
},
{
"stage": "hdl",
"state": "n/a"
},
{
"stage": "soc",
"state": "n/a"
},
{
"stage": "board",
"state": "n/a"
},
{
"stage": "twin",
"state": "n/a"
}
]
},
{
"name": "Health monitoring",
"requirement": "REQ-AEB-007",
"stages": [
{
"stage": "simulation",
"state": "n/a"
},
{
"stage": "sil",
"state": "n/a"
},
{
"stage": "pil",
"state": "n/a"
},
{
"stage": "hdl",
"state": "n/a"
},
{
"stage": "soc",
"state": "n/a"
},
{
"stage": "board",
"state": "n/a"
},
{
"stage": "twin",
"state": "n/a"
}
]
}
],
"success": true
}What the gate does not do
The gate checks that the dossier is complete and consistent. It does not judge whether a requirement is well written, whether a trace makes sense, or whether a hazard analysis found the right hazards. It is evidence for a review, not a replacement for it, and it is not a certification.
For the question the compiler cannot answer, "is this trace plausible?", arclang review asks an external judgment model and returns probabilities. That command is optional, sends the names and descriptions of the traced elements to an external service, and never influences check or the gate. --dry-run prints what would be sent and sends nothing.
Qualification
A tool used in a safety process may need qualification. The repository holds a support kit in docs/qualification: tool confidence level analysis for ISO 26262-8 clause 11, tool qualification level for DO-330, an inventory of functions and malfunctions, and an evidence matrix into the test suite. Releases are built from tags, with checksums and build provenance attestations, so a qualified environment can pin and verify a version.