Deklarative Absicht → deterministischer Ausführungsvertrag → Agent / Harness

Decretum

Decretum verwandelt strukturierte Absicht in einen deterministischen Ausführungsvertrag für Agenten und Harnesses.

Decretum ist ein domänenneutraler Declarative Execution Compiler. Er kombiniert Schemas, Recipes, Profile, Provider-/Integrations-Registries, Discovery, Validierung, Policy und deterministische Auflösung, um einen portablen Execution Contract zu erzeugen.

Security Research ist Decretums Referenzdomäne, nicht seine architektonische Grenze. Dasselbe Compiler-Modell kann Software Engineering, Infrastruktur-Automatisierung, Data Engineering, Incident Response, wissenschaftliche Experimente und andere reproduzierbare technische Arbeit beschreiben.

Architektur

Decretum ist keine Runtime. Es definiert, was ausgeführt werden kann, und erzeugt einen portablen Ausführungsvertrag. Es führt keine Arbeit aus, verwaltet keine Agenten-/Forscher-Interaktion, sammelt keine Evidenz, pflegt keine Findings und generiert keine Berichte.

Nach der Kompilierung stoppt Decretum. Der Vertrag wird an einen externen Harness oder eine Agenten-Runtime übergeben.

Wenn die Ausführung später eine neue Fähigkeit oder geänderte Anforderung benötigt, kehrt die Anfrage zu Decretum zurück für Validierung, Auflösung und Neukompilierung.

Das Modell

Schema       = was existiert / semantische Grenzen
Recipe       = was getan werden soll
Profile      = Ausführungsmerkmale und Präferenzen
Registry     = verfügbare Implementierungen
Resolver     = deterministische Fähigkeitsbindung
Compiler     = portable Vertragserzeugung
Harness      = tatsächliche Ausführung und Interaktion
Store        = persistenter Ausführungs-/Forschungsspeicher

Die wichtige Trennung ist:

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

Domänen-Packs

Der Compiler-Kern ist domänenneutral. Domänenspezifische Semantik lebt in Registries und Schemas statt in Compiler-Verzweigungen.

Beispiele:

• Security Research — Malware, Netzwerk, Forensik, Detection und Cloud-Untersuchung
• Software Engineering — Quellcode-Änderungen, Abhängigkeiten, Tests, Builds und Container
• Infrastruktur — VM-, Container-, Netzwerk- und Deployment-Anforderungen
• Data Engineering — Datensätze, Transformationen, Validierung und Artefakte
• Wissenschaftliche/technische Experimente — Instrumente, Beobachtungen, Analyse und Evidenz

Ein Domänen-Pack steuert Fähigkeiten, Schemas, Recipes, Profile und Provider-Metadaten bei. Er ändert nicht die Kern-Resolver-/Compiler-Semantik.

Warum strukturierte Verträge statt breiter Markdown-Spezifikationen?

Markdown ist hervorragend zur Erklärung. Es ist keine deterministische Ausführungsschnittstelle.

Decretum trennt:

menschliche Absicht
    |
    v
strukturiertes Schema + Recipe + Profile
    |
    v
validierte Auflösung
    |
    v
portabler Ausführungsvertrag
    |
    v
Agenten-/Harness-Ausführung

Dies gibt Agenten eine maschinenlesbare Grenze, während Implementierungsentscheidungen außerhalb des Recipes bleiben.

Beispiel: Software Engineering

Eine Software-Aufgabe kann denselben Compiler verwenden:

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

Dieselbe Absicht kann gegen einen anderen Präferenzsatz kompiliert werden:

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

Das Recipe beschreibt Absicht. Das Profile drückt Präferenzen aus. Die Provider-Registry bestimmt, was tatsächlich verfügbar ist.

Security-Research-Referenzbeispiel

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

Das Recipe enthält keinen Lima/Docker-Lebenszyklus, keine MCP-Implementierung, keine Agenten-Prompts und keinen runtime-spezifischen Code.

End-to-End-Workflow

1. Strukturierte Absicht definieren.
2. Kanonische Fähigkeiten referenzieren.
3. Profile/Präferenzen auswählen.
4. Das Recipe validieren.
5. Verfügbare Ausführungsflächen entdecken.
6. Fähigkeit → Provider → Integration → Harness auflösen.
7. Bereitschaft und Policy prüfen.
8. Den Execution Contract kompilieren.
9. Den Vertrag an den externen Harness übergeben.
10. Der Harness führt aus, interagiert und persistiert seinen Zustand.
11. Wenn sich Anforderungen ändern, zu Decretum zurückkehren und einen neuen Vertrag kompilieren.

Decretum führt die Schritte 9–10 nicht aus.

Fähigkeits-Evolution

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

Discovery kann eine Fähigkeit vorschlagen, aber sie kann kanonische Semantik nicht stillschweigend verändern.

Schnellstart

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

Nichts im validate/resolve/compile-Pfad von Decretum führt die Arbeit aus.

Auflösungskette

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

Architekturgrenze

Decretum wird bewusst nicht zu: