Referencia de la API¶
Superficie pública mínima de Nikodym RiskLib. Generada automáticamente desde los docstrings del código (mkdocstrings). Las APIs marcadas como experimentales pueden cambiar antes de la 1.0.
run¶
Punto de entrada único de ejecución: recibe un NikodymConfig y devuelve un Study.
run ¶
Ejecuta una corrida completa de extremo a extremo y devuelve el Study.
Superficie pública única de ejecución (CT-4): ensambla el AuditSink y el
ModelInventory (assemble_run), corre el Study, y —solo en éxito y solo si
governance.publish_to_inventory— publica la ModelCard en el inventario.
Semántica de fallo (D-UI-2, decidida). Study.run() es el primitivo fail-loud:
ante un fallo marca status="failed", conserva el lineage y re-levanta. Esta función es
el envoltorio de producto: captura el NikodymError y devuelve el Study parcial
en vez de propagarlo. El fallo no se silencia (vive en study.run_context.status, en el
audit-trail y en el lineage) pero tampoco explota. Por eso, el consumidor por código debe
chequear study.run_context.status ("done" vs "failed") antes de usar
study.results.
Study¶
Contenedor de una corrida: RunContext (estado + lineage), ArtifactStore namespaced y
persistencia atómica a directorio.
Study ¶
Estado del experimento y orquestador de la corrida (SDD-01 §4/§7).
Un Study recién construido arranca en status="created" y serializa sin valores ficticios
(DoD F0). :meth:run lo transiciona a running → done/failed y congela el lineage.
El config es inmutable: su identidad se ancla al config_hash.
set_audit_sink ¶
Inyecta el AuditSink (ya compuesto por api/runner) y lo propaga al ArtifactStore.
Debe llamarse antes de :meth:run. core no compone FanOutSink ni resuelve el
inventario (CT-4): toma un sink ya resuelto.
lineage_bundle ¶
Devuelve el :class:LineageBundle congelado en :meth:run; levanta si no se corrió.
run ¶
Ejecuta el pipeline y devuelve self (encadenable).
El argumento steps tiene prioridad sobre config.run.steps. fail_fast=False no se
soporta en v1: se emite un warning ruidoso (no un no-op silencioso) y se procede como
True. Una excepción en un paso (con fail_fast=True) deja status="failed" pero
conserva el lineage (evidencia de trazabilidad, SR 11-7), emite run_end con el error
y se re-levanta; el Study parcial sigue siendo guardable.
run_step ¶
Ejecuta un paso aislado y devuelve su resultado; no altera run_context.status.
Emite sólo los eventos del paso (no run_start/run_end) y exige sus prerequisitos
presentes. En F0 NikodymConfig no expone secciones de dominio, así que la resolución
levanta ConfigError (la orquestación de dominios llega en T2).
save ¶
Serializa el Study a un directorio de forma atómica (escribe-a-temporal-y-renombra).
Layout: config.yaml + run_metadata.json + lineage.json (si hay lineage) +
artifacts/<domain>/<key>.joblib. Al sobrescribir, el directorio previo se aparta a
un respaldo lateral antes de colocar el nuevo y se restaura si el swap falla. En el
doble-fallo (falla el swap y también la restauración), el estudio previo queda preservado
en el respaldo lateral .old.* y path podría quedar transitoriamente sin directorio
válido; se prioriza no perder datos. El azar (seed_manager) no se guarda: se reconstruye
en :meth:load. Devuelve el Path del directorio final.
load
classmethod
¶
Recarga un Study desde un directorio; reconstruye el azar y verifica el config_hash.
trust=False (default) rechaza un Study con artefactos pickle (vector de ejecución
de código). Un config_hash que no coincide con el del lineage levanta
:class:~nikodym.core.exceptions.ReproducibilityError; una divergencia de versiones de
librerías sólo advierte. El SeedManager se reconstruye desde config.repro.seed.
Nota: el chequeo de config_hash detecta divergencia accidental entre config.yaml
y el lineage, no manipulación maliciosa (el hash de referencia vive en el mismo directorio
editable). La integridad fuerte recae en trust=True + control del origen del directorio.
NikodymConfig¶
Config declarativo raíz — el config es el experimento. Agrupa las secciones de datos, binning, selección, modelo, scorecard, calibración y demás dominios.
NikodymConfig ¶
Bases: NikodymBaseConfig
Config raíz declarativo: agrega las secciones transversales del experimento.
NikodymConfig() construye sin argumentos con todos los valores por defecto (DoD F0). Las
secciones de dominio (binning, model, provisioning, ...) se añaden de forma aditiva por capa;
en F0 solo viven las transversales (schema_version, name, repro, run,
data, markov, eda, binning, selection, model, scorecard,
calibration, tuning, ml, explain, survival, forward, stress,
provisioning_cmf, provisioning_ifrs9, performance, stability, validation,
report).