Decision spike: choose rule expression substrate (CEL over DynamicValue vs extend Cedar)

[rrrodzilla]

Workstream: Foundation · Part of #89

Decision (made)

Build our own minimal CEL evaluator over DynamicValue from scratch (engine: #107 parser, #108 evaluator core, #109 stdlib), verified against the #90 conformance oracle.

Explicitly rejected, with reasons recorded for the audit trail:

• Live upstream dependency on the cel crate — unmaintained (no conformance gate; abandoned 2023 branch); unacceptable supply-chain posture for a federal product.
• Vendoring the cel crate — declined; we don't want to inherit its design or gaps or spend effort vetting a snapshot. Building exactly what we need is cleaner and fully owned.
• Cedar for the rules engine — hard no. Cedar stays scoped to authorization; it produces no values and we will not overload it.

Remaining scope

• Write a short ADR capturing the above rationale (why from-scratch, supply-chain / FIPS / airgap reasoning, corpus-as-oracle verification plan).

Acceptance

• Committed ADR; this issue then closes. Decision is already in effect — engine issues Engine: schema-forge-cel crate — CEL lexer + parser → AST #107–Engine: CEL standard function library (string/math/list/map/conversions/timestamp/duration) #109 are unblocked.

---

Dependencies: Resolved by decision. Records context for the type decisions #98/#102 (now made inside an owned engine). Soft.