Ir al contenido

Añadir un escenario (.json)

✅ Estable

El arnés e2e de Venturalítica es dirigido por datos: cada caso de uso vive en un fichero tests/scenarios/<nombre>.json. El código del arnés es el módulo completo tests/scenario/ (mod.rs + runner.rs + assertions.rs + env.rs + fixtures.rs, orquestado por mod.rs); es compartido por todos los escenarios y nunca se modifica al añadir uno nuevo.

Añadir un caso de uso = añadir un .json (y sus recursos) + una función #[test] de una línea que lo nombre. No se escribe ningún pilot_*.rs.


Un fichero de escenario tiene tres secciones de nivel superior:

tests/scenarios/mi-sistema.json (esqueleto)
{
"name": "mi-sistema",
"description": "Descripción del caso de uso y lo que se prueba.",
"resource_dir": "mi-sistema",
"steps": [
{ "do": "git_init" },
{ "do": "uv_init", "deps": ["venturalitica==0.6.11", "mlcroissant>=1.0", "dvc>=3"] },
{ "do": "copy", "from": "sei.yaml", "to": "sei.yaml" },
{ "do": "compile", "expect": { "exit": "ok" } },
{ "do": "run", "expect": { "exit": "fail", "gate": "red" } },
{ "do": "verify", "expect": { "exit": "ok" } }
]
}
CampoTipoDescripción
namestringIdentificador del escenario (coincide con el nombre del .json).
descriptionstringTexto libre que describe el propósito y las invariantes del escenario. Se imprime en la traza.
resource_dirstringSubdirectorio bajo tests/resources/ que contiene los ficheros de fixture del escenario.
stepsarrayLista ordenada de pasos. Todo lo que ocurre en disco es un paso explícito.

El runner entiende los siguientes verbos. Cada paso puede incluir un bloque expect con aserciones.

VerboEfecto
git_initgit init + identidad del repo de fixture.
uv_initEscribe pyproject.toml con las deps indicadas y ejecuta uv sync.
dvc_initdvc init.
copyCopia from (relativo a resource_dir) a to (en el repo temporal).
dvc_adddvc add <path> — versiona el fichero con DVC.
commitgit add -A && git commit -m <message>.
edit_seiSustituye literales en sei.yaml (simulate un cambio versionado).
VerboComando equivalente
compilesei compile — programa de riesgos (sección risk: de sei.yaml) → assessment_plan.oscal.yaml.
runsei run — reproduce el pipeline, ancla y firma la evidencia. El exit refleja el gate de riesgo.
statussei status — gates de frescura + riesgo, sin recomputar.
verifysei verify — verifica la firma del bundle.
reconstructsei reconstruct [--out] — reconstruye el ciclo ISO 23894 por replay de git.
conformancesei conformance --standard <id> [--out] — proyecta el bundle al catálogo del estándar.
approvesei approve --by <by> — aprobación de dirección con trailer Sei-Approved-by.
impactsei impact — evaluación de impacto y mal uso previsible (ISO 42001 §6.1.4).
assesssei assess — el KAG propone riesgos no declarados (backlog del registro vivo).
VerboEfecto
dvc_expdvc exp run [--set-param ...] — explora un candidato de tratamiento como experimento (git-stashed, sin commitear). Acepta expect_metrics para asegurar que el candidato cerraría el gate.

Cada paso puede declarar aserciones en su campo expect. El runner verifica cada una y falla el test si alguna no se cumple.

Ejemplos de expect
{
"do": "run",
"expect": {
"exit": "fail",
"gate": "red",
"classification_tier": "high",
"risks_nonempty": true,
"pipeline_lock_present": true,
"control_count": 10,
"controls": {
"unfair-credit-exclusion": {
"passed": false,
"enforcement_mode": "block",
"severity": "high",
"operator": "lt",
"actual_gt": 0.03,
"frameworks": ["eu/dora@2022#art-6"]
}
},
"gate_failures": ["unfair-credit-exclusion"],
"risk_analysis": {
"risk.unfair-credit-exclusion": {
"inherent_overall": "HIGH",
"requires_treatment": true,
"cycle": "open"
}
}
}
}
Campo expectQué verifica
exit"ok" o "fail" — el exit code del comando.
gate"green" o "red" — el estado del gate de riesgo en el bundle.
classification_tierNivel de clasificación del sistema (p.ej. "high").
risks_nonemptyEl bundle contiene al menos un riesgo.
pipeline_lock_presentpipeline_lock_digest en el bundle empieza por sha256:.
control_countNúmero exacto de controles en control_results.
controlsPor control: passed, enforcement_mode, severity, operator, actual_gt/lt, frameworks.
gate_failuresLista exacta de controles bloqueantes en rojo (sin aceptados).
driftPor sección: el texto de derive esperado en stdout (p.ej. "recomputado (clase B)").
stdout_containsLista de cadenas que deben aparecer en stdout.
risk_analysisPor riesgo: inherent_overall, residual_overall, requires_treatment, cycle.
overall_residualResidual global del bundle: level, evaluation, contributing.
treatment_eventsRecuento y contenido de eventos de tratamiento en el bundle.
sei_artifactsRutas relativas a .sei/ que deben existir, ser JSON válido y tener firma verificable.

Para añadir un nuevo backend MLOps sobre el escenario loan, basta con crear un fichero .json que copie sei_<backend>.yaml como sei.yaml y sustituya el fichero de definición del pipeline. Los recursos (compliance_eval.py, train.py, german_credit.*) son los mismos porque residen en resource_dir: loan; el programa de riesgos vive en la sección risk: del propio sei.yaml.

Las tres variantes de backend del escenario loan (loan.json = DVC, loan_mlflow.json = MLflow, loan_dagster.json = Dagster) son la referencia de este patrón (hoy hay 8 escenarios JSON en total). Consulta Integrar tu pipeline para el detalle de cada backend.


Cada escenario declara su resource_dir. El runner busca los ficheros copiados (copy) en tests/resources/<resource_dir>/. Puedes reutilizar el directorio loan para nuevos backends del mismo escenario, o crear un directorio propio para sistemas distintos.

tests/
scenarios/
mi-sistema.json ← el escenario
resources/
mi-sistema/
sei.yaml ← manifiesto + programa de riesgos (sección risk:)
compliance_eval.py
train.py
data/mi-dataset.csv
data/mi-dataset.croissant.json