PLATAFORMA / PRINCIPIOS

Cuatro invariantes. Toda capability las hereda.

El sustrato no es configurable. Event sourcing, audit gates, idempotencia y reversibilidad son el contrato que todo módulo de la plataforma hereda antes de ganar el derecho a llamarse capability. Esto es lo que hace la plataforma auditable y al operator en control.

Volver a la plataforma Hablar sobre el sustrato

INVARIANTES

El contrato está upstream de toda capability.

Antes de que un módulo tenga permiso para sugerir, decidir o aplicar, debe heredar el sustrato. Esto es lo que separa una plataforma de una colección de scripts.

Output de capa

Event sourcing

Todo cambio de estado es un evento en un log append-only. El estado actual es una proyección de los eventos. La reconstrucción es siempre posible porque la source of truth es la timeline, no el snapshot.

  • Event log append-only
  • Las proyecciones derivan estado
  • Replay reconstruye
Output timeline auditable

Output de capa

Audit log

Toda acción aplicada escribe una fila a ads.audit_log (o su equivalente de dominio). La fila lleva el reason, el snapshot before, el actor, la rules version. Nada pasa en silencio.

  • Reason + snapshot_before por fila
  • Rules version (git SHA) registrada
  • Revisable antes de la siguiente acción
Output trail explainable

Output de capa

Idempotencia

El mismo (rule, natural_key, target_state) nunca duplica. Las idempotency keys protegen de re-runs accidentales, retries de red o double-click del operator. La plataforma fail-safe bajo repetición.

  • Idempotency keys en suggestions
  • Deduplication en la capa de acción
  • Coste de re-run: cero
Output safe bajo retries

Output de capa

Reversibilidad

Rollback en 90 días con un comando. apply_*.py persiste snapshots de pre-estado para que el operator pueda deshacer cualquier decisión. La reversibilidad no es una feature añadida después — es requerida antes de que el apply corra.

  • Snapshot pre-estado por apply
  • Rollback ≤ 90 días, 1 comando
  • Override humano siempre gana
Output operación reversible

SIDE-EFFECT GATE

Las acciones del mundo real requieren aprobación explícita del operator.

La plataforma puede preparar acciones, draftearlas, auditarlas — pero el apply que toca el mundo (escrituras a Amazon, mutaciones DNS, envíos reales, deploys públicos) requiere aprobación explícita del operator en chat. El protocolo no se mueve por velocidad ni conveniencia.

web-builder / ruta de producción
Ruta canónica /es/plataforma/principles/
Estado de la superficie approval contract
Evidence Data, entries de audit_log, razonamiento. El operator ve qué cambiaría antes de que el cambio corra.

requerido

Draft La acción se prepara en forma no-aplicada. El output de dry-run es visible.

requerido

Approval El operator aprueba explícitamente en chat — no en un doc, no por silencio.

requerido

Apply Solo después de approval. La fila de audit_log se escribe antes de que el side effect retorne.

controlado

Readback El estado aplicado se lee de vuelta y se confirma. Los deploys públicos se verifican contra producción, no contra local.

requerido

Gate de decisión operator owns

La plataforma nunca auto-aplica side effects sin el operator. La velocidad del loop nunca override el gate.

SIGUIENTE

Si tu operación necesita el sustrato, no los scripts, la conversación empieza aquí.

Muchas herramientas automatizan. Pocas hacen su automatización auditable, reversible y operable por un humano en el loop. Si esa distinción importa para tu operación, habla con nosotros.

Hablar sobre el sustrato

Sistemas operativos, no slides.

Cuentanos que esta fallando. Te diremos rapido si el problema es arquitectonico, operativo o de ejecucion.

Contactar Ver servicios