Intento dichiarativo → contratto di esecuzione deterministico → agente / harness

Decretum

Decretum trasforma l'intento strutturato in un contratto di esecuzione deterministico per agenti e harness.

Decretum è un Compilatore di Esecuzione Dichiarativo domain-neutral. Combina schemi, ricette, profili, registri di provider/integrazione, discovery, validazione, policy e risoluzione deterministica per produrre un Contratto di Esecuzione portabile.

La ricerca sulla sicurezza è il dominio di riferimento di Decretum, non il suo confine architetturale. Lo stesso modello di compilatore può descrivere ingegneria del software, automazione dell'infrastruttura, ingegneria dei dati, risposta agli incidenti, esperimenti scientifici e altri lavori tecnici riproducibili.

Architettura

Decretum non è un runtime. Definisce ciò che può essere eseguito e produce un contratto di esecuzione portabile. Non esegue il lavoro, non gestisce l'interazione agente/ricercatore, non raccoglie evidenze, non mantiene risultati né genera report.

Dopo la compilazione, Decretum si ferma. Il contratto viene passato a un harness esterno o a un runtime per agenti.

Se in seguito l'esecuzione necessita di una nuova capacità o di un requisito modificato, la richiesta ritorna a Decretum per validazione, risoluzione e ricompilazione.

Il modello

Schema       = ciò che esiste / confini semantici
Recipe       = ciò che dovrebbe essere fatto
Profile      = caratteristiche e preferenze di esecuzione
Registry     = implementazioni disponibili
Resolver     = binding deterministico delle capacità
Compiler     = generazione di contratti portabili
Harness      = esecuzione e interazione effettive
Store        = memoria persistente di esecuzione/ricerca

La separazione importante è:

                    DECRETUM
          Declarative Execution Compiler
                       |
       +---------------+---------------+
       |               |               |
    Schema           Recipe          Profile
   "what"           "do"            "how"
       |               |               |
       +---------------+---------------+
                       |
                    Resolver
                       |
     capability + provider + integration
       + harness + readiness + policy
                       |
                       v
               Execution Contract
                       |
                       v
              External Harness/Agent
                       |
          +------------+------------+
          |            |            |
       execute      interact      persist
          |            |            |
          +------------+------------+
                       |
                    Store

Domain pack

Il core del compilatore è domain-neutral. Le semantiche specifiche del dominio risiedono nei registri e negli schemi, non nei rami del compilatore.

Esempi:

• Ricerca sulla sicurezza — malware, rete, forense, rilevamento e indagine cloud
• Ingegneria del software — modifiche al codice sorgente, dipendenze, test, build e container
• Infrastruttura — requisiti di VM, container, rete e deployment
• Ingegneria dei dati — dataset, trasformazioni, validazione e artefatti
• Esperimenti scientifici/tecnici — strumenti, osservazioni, analisi ed evidenze

Un domain pack contribuisce con capacità, schemi, ricette, profili e metadati dei provider. Non modifica la semantica del resolver/compilatore core.

Perché contratti strutturati invece di ampie specifiche markdown?

Il markdown è eccellente per la spiegazione. Non è un'interfaccia di esecuzione deterministica.

Decretum separa:

intento umano
    |
    v
schema strutturato + recipe + profile
    |
    v
risoluzione validata
    |
    v
contratto di esecuzione portabile
    |
    v
esecuzione agente / harness

Questo fornisce agli agenti un confine leggibile dalla macchina, mantenendo le scelte implementative al di fuori della ricetta.

Esempio: ingegneria del software

Un'attività software può utilizzare lo stesso compilatore:

apiVersion: decretum.dev/v1
kind: ExecutionRecipe
domain: software_engineering
id: build-user-service
name: Build User Service
version: "1.0"
objective: Build and validate a Python service.

capabilities:
  - source.read
  - source.modify
  - dependency.install
  - test.execute
  - artifact.build
  - container.build

profiles:
  infrastructure: local-dev
  language: python
  testing: pytest
  container: docker
  agent: coding-agent

completion:
  required:
    - tests_pass
    - artifact_built
    - container_built

Lo stesso intento può essere compilato rispetto a un altro insieme di preferenze:

profiles:
  infrastructure: isolated-dev-vm
  testing: pytest
  container: podman
  agent: enterprise-coding-agent

La ricetta descrive l'intento. Il profilo esprime le preferenze. Il registro dei provider determina ciò che è effettivamente disponibile.

Esempio di riferimento per la ricerca sulla sicurezza

id: suspicious-network-investigation
name: Suspicious Network Investigation
version: "1.0"
role: threat_researcher
objective: Determine whether the sample creates unexpected network activity.

capabilities:
  - process.observe
  - network.capture
  - artifact.collect

infrastructure_profile: isolated-linux-vm
instrumentation_profile: linux-network-observation
harness_profile: interactive-research

La ricetta non contiene il ciclo di vita Lima/Docker, l'implementazione MCP, i prompt dell'agente o codice specifico del runtime.

Flusso di lavoro end-to-end

1. Definire l'intento strutturato.
2. Fare riferimento a capacità canoniche.
3. Selezionare profili/preferenze.
4. Validare la ricetta.
5. Scoprire le superfici di esecuzione disponibili.
6. Risolvere capacità → provider → integrazione → harness.
7. Verificare readiness e policy.
8. Compilare il Contratto di Esecuzione.
9. Consegnare il contratto all'harness esterno.
10. L'harness esegue, interagisce e persiste il proprio stato.
11. Se i requisiti cambiano, tornare a Decretum e compilare un nuovo contratto.

Decretum non esegue i passaggi 9–10.

Evoluzione delle capacità

DISCOVER
   |
PROPOSE
   |
SEMANTIC REVIEW
   |
APPROVE
   |
CANONICAL CAPABILITY
   |
PROVIDER IMPLEMENTATIONS

La discovery può proporre una capacità, ma non può mutare silenziosamente la semantica canonica.

Avvio rapido

git clone https://github.com/Opposum0112/Decretum.git
cd Decretum
uv sync
decretum capabilities discover
decretum validate recipes/<recipe>.yaml
decretum resolve recipes/<recipe>.yaml
decretum compile recipes/<recipe>.yaml

Nulla nel percorso validate/resolve/compile di Decretum esegue il lavoro.

Catena di risoluzione

Capability
    |
Provider
    |
Integration
    |
Execution surface
    |
Harness compatibility
    |
Host/provider readiness
    |
Policy compatibility
    |
READY / BLOCKED

Confine architetturale

Decretum deliberatamente non diventa: