Intention déclarative → contrat d'exécution déterministe → agent / harness

Decretum

Decretum transforme une intention structurée en un contrat d'exécution déterministe pour les agents et les harnesses.

Decretum est un compilateur d'exécution déclaratif agnostique au domaine. Il combine des schémas, des recettes, des profils, des registres de fournisseurs/intégrations, la découverte, la validation, la politique et la résolution déterministe pour produire un contrat d'exécution portable.

La recherche en sécurité est le domaine de référence de Decretum, pas sa frontière architecturale. Le même modèle de compilateur peut décrire l'ingénierie logicielle, l'automatisation d'infrastructure, l'ingénierie de données, la réponse aux incidents, les expériences scientifiques et d'autres travaux techniques reproductibles.

Architecture

Decretum n'est pas un runtime. Il définit ce qui peut être exécuté et produit un contrat d'exécution portable. Il n'exécute pas le travail, ne gère pas l'interaction agent/chercheur, ne collecte pas de preuves, ne conserve pas de résultats et ne génère pas de rapports.

Après la compilation, Decretum s'arrête. Le contrat est transmis à un harness externe ou à un runtime d'agent.

Si l'exécution nécessite ultérieurement une nouvelle capacité ou un besoin modifié, la demande revient à Decretum pour validation, résolution et recompilation.

Le modèle

Schema       = what exists / semantic boundaries
Recipe       = what should be done
Profile      = execution characteristics and preferences
Registry     = available implementations
Resolver     = deterministic capability binding
Compiler     = portable contract generation
Harness      = actual execution and interaction
Store        = persistent execution/research memory

La séparation importante est la suivante :

                    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

Packs de domaine

Le cœur du compilateur est agnostique au domaine. Les sémantiques spécifiques au domaine résident dans les registres et les schémas plutôt que dans des branches du compilateur.

Exemples :

• Recherche en sécurité — malware, réseau, forensique, détection et investigation cloud
• Ingénierie logicielle — modifications de code source, dépendances, tests, builds et conteneurs
• Infrastructure — exigences de VM, conteneur, réseau et déploiement
• Ingénierie de données — jeux de données, transformations, validation et artefacts
• Expériences scientifiques/techniques — instruments, observations, analyse et preuves

Un pack de domaine apporte des capacités, des schémas, des recettes, des profils et des métadonnées de fournisseur. Il ne modifie pas la sémantique du résolveur/compilateur de base.

Pourquoi des contrats structurés plutôt que de larges spécifications en markdown ?

Le markdown est excellent pour l'explication. Ce n'est pas une interface d'exécution déterministe.

Decretum sépare :

human intent
    |
    v
structured schema + recipe + profile
    |
    v
validated resolution
    |
    v
portable execution contract
    |
    v
agent / harness execution

Cela donne aux agents une frontière lisible par machine tout en gardant les choix d'implémentation en dehors de la recette.

Exemple : ingénierie logicielle

Une tâche logicielle peut utiliser le même compilateur :

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

La même intention peut être compilée avec un autre ensemble de préférences :

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

La recette décrit l'intention. Le profil exprime les préférences. Le registre de fournisseurs détermine ce qui est réellement disponible.

Exemple de référence en recherche de sécurité

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 recette ne contient pas de cycle de vie Lima/Docker, d'implémentation MCP, de prompts d'agent ni de code spécifique au runtime.

Flux de travail de bout en bout

1. Définir une intention structurée.
2. Référencer des capacités canoniques.
3. Sélectionner des profils/préférences.
4. Valider la recette.
5. Découvrir les surfaces d'exécution disponibles.
6. Résoudre capacité → fournisseur → intégration → harness.
7. Vérifier l'état de préparation et la politique.
8. Compiler le contrat d'exécution.
9. Transmettre le contrat au harness externe.
10. Le harness exécute, interagit et persiste son état.
11. Si les exigences changent, revenir à Decretum et compiler un nouveau contrat.

Decretum n'effectue pas les étapes 9 à 10.

Évolution des capacités

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

La découverte peut proposer une capacité, mais elle ne peut pas muter silencieusement la sémantique canonique.

Démarrage rapide

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

Rien dans le chemin validate/resolve/compile de Decretum n'exécute le travail.

Chaîne de résolution