Building a Fail-Closed Investment Risk Gate with Yuer DSL

Source: Dev.to

Problem Statement (Engineering, Not Finance)

Most AI systems fail in investment contexts before any model runs.

Common failure modes

• incomplete information silently tolerated
• uncertainty replaced by narrative confidence
• AI producing directional language (“looks good”, “probably safe”)
• humans treating AI output as implicit approval

These are system design failures, not modeling failures.
So we start one step earlier.

What This System Actually Does

The system answers exactly one question:

Is this investment scenario structurally eligible to enter a formal evaluation phase?

It does not answer:

• should we invest?
• is this asset attractive?
• what is the expected return?

If eligibility cannot be established safely, the system refuses.
This is a risk gate, not a decision engine.

Minimal Yuer DSL Risk‑Gate Request

Below is the minimal executable request profile used for pre‑evaluation gating.
This is one application scenario of Yuer DSL, not the DSL itself.

protocol: yuerdsl
version: INVEST_PRE_REQUEST_V1
intent: risk_quant_pre_gate

scope:
  domain: investment
  stage: pre-evaluation
  authority: runtime_only

responsibility:
  decision_owner: ""
  acknowledgement: true

subject:
  asset_type: equity
  market:
    region: ""
    sector: ""

information_status:
  financials:
    status: partial
  governance:
    status: unknown
  risk_disclosure:
    status: insufficient

risk_boundary:
  max_acceptable_loss:
    percentage_of_capital: 15

uncertainty_declaration:
  known_unknowns:
    - "Market demand volatility"
    - "Regulatory exposure"
  unknown_unknowns_acknowledged: true

constraints:
  prohibited_outputs:
    - investment_recommendation
    - buy_sell_hold_signal
    - return_estimation

This request cannot produce a decision by design.

Fail‑Closed Enforcement (Validator Logic)

Fail‑closed behavior is enforced in code, not policy text.
Below is a simplified runtime gate validator:

def pre_eval_gate(request: dict):
    # Responsibility anchor is mandatory
    if not request.get("responsibility", {}).get("acknowledgement"):
        return block("NO_RESPONSIBILITY_ANCHOR")

    # Information completeness check
    info = request.get("information_status", {})
    for key, field in info.items():
        if field.get("status") in ("missing", "unknown", "insufficient"):
            return block(f"INSUFFICIENT_{key.upper()}")

    # Uncertainty must be explicit
    uncertainty = request.get("uncertainty_declaration", {})
    if not uncertainty.get("known_unknowns"):
        return block("UNCERTAINTY_NOT_DECLARED")

    if not uncertainty.get("unknown_unknowns_acknowledged"):
        return block("UNCERTAINTY_DENIAL")

    return allow("ELIGIBLE_FOR_EVALUATION")

def block(reason):
    return {"status": "BLOCK", "reason": reason}

def allow(reason):
    return {"status": "ALLOW", "reason": reason}

Key properties

• no scoring
• no ranking
• no fallback logic

If the structure is unsafe → the system stops.

Allowed Runtime Output (Strictly Limited)

The runtime may return only:

evaluation_gate:
  status: ALLOW | BLOCK
  reason_code: ""

• ALLOW → evaluation may begin
• BLOCK → evaluation is forbidden

Neither implies investment quality or correctness.

Why This System Refuses to Be “Helpful”

Many AI tools optimize for always producing an answer.
In high‑responsibility domains, that is a liability.

This gate is intentionally:

• conservative
• rejection‑heavy
• uncomfortable to use

Because a system that refuses early is safer than one that explains late.

Responsibility Boundary (Critical)

The design explicitly prevents:

• AI becoming a decision proxy
• Humans offloading responsibility to language output

Decision authority remains human‑only.
The system only decides whether thinking is allowed to continue.

Who This Is For

Useful for

• professional investors
• internal risk & compliance teams
• founders making irreversible capital decisions
• architects building high‑responsibility AI systems

Not suitable for

• trading signal generation
• advisory agents
• demo‑driven AI workflows

One‑Sentence Summary

The system does not help you decide what to do; it prevents you from deciding when you should not.

Final Note

Yuer DSL is not defined by this example.
This is a single application pattern used to anchor risk‑quantification behavior in EDCA OS–aligned systems.

The principle remains simple: language may describe conditions, but only a fail‑closed runtime may allow evaluation to proceed.