Introduction
c-earchin translates EARS requirement files into Chelis Deep witness
definitions plus provenance spans. It is an external-notation bridge: you write
requirements in EARS, the structured-English requirement syntax, and c-earchin
lowers them into Chelis Deep so that chelis prove can run them as properties.
EARS (Easy Approach to Requirements Syntax) constrains requirement prose to a
small set of templates built around the keyword shall. Each template names a
system, a response, and an optional trigger, state, condition, or feature. That
structure is regular enough to classify mechanically, which is what makes the
translation possible.
What the bridge produces
Section titled “What the bridge produces”For each translation, c-earchin writes two files:
- A
.dpDeep file. It contains a fixed vocabulary of pure-boolean predicates followed by one callable witness definition per requirement. A resolved witness carries canonical Chelis property metadata (chelis_role: "property"and theproperty_*fields), sochelis provediscovers it by metadata scan without any new Deep tag. - A
.spans.jsonprovenance manifest. Every emitted Deep node records the EARS file, requirement id, requirement text, and byte and line span it came from, down to the individual clauses of the requirement.
The pipeline is a straight line:
EARS source -> parser -> classifier -> vocabulary lookup -> lowerer -> emitterThe Deep file uses only existing Chelis tags. Requirement intent is attached
through c_earchin_* metadata, while the canonical chelis_role and
property_* metadata make each witness discoverable.
Provenance is the point
Section titled “Provenance is the point”A requirement that translates is not just runnable. It stays traceable. When a
witness fails under chelis prove, the span manifest resolves the failing Deep
node back to the exact EARS requirement line that produced it:
property failure: req_FIN_003 --> references/finance_options/options_rules.ears:3:1 FIN-003 | WHILE the exchange is open, the portfolio delta shall be at most the limit.A stakeholder reading the EARS file and an engineer reading the proof output are looking at the same requirement, identified the same way.
What this book covers
Section titled “What this book covers”- Getting started and the command line: how to install the bridge and run a translation end to end.
- The EARS patterns: the requirement templates the classifier recognizes, each with a faithful example.
- The Kiro dialect: ingesting Kiro-style
requirements.mdmarkdown directly. - Provenance: how each Deep node traces back to its requirement line.
- Verification scope: what is checked and what is recorded but not checked.