APEX

Code zu einer anonymen Paper-Einreichung. Das Repository trennt den APEX-Verteidiger, die Normalisierung von Benchmark-Daten, vertrauenswürdige Fähigkeitsmanifeste und Integrationen von Vergleichsmethoden, sodass jede Schicht unabhängig inspiziert werden kann.

Installation

python -m venv .venv
source .venv/bin/activate
pip install -e '.[test]'
export PYTHONPATH="$PWD/src:$PWD"

Modellgestützte Komponenten lesen OPENAI_API_KEY und die optionale OPENAI_BASE_URL aus der Umgebung. Kopiere .env.example nur als Referenz; der Code liest keine lokalen Credential-Dateien.

Repository-Übersicht

Pfad	Verantwortlichkeit
src/apex/defender/	APEX-Task-Verträge, typisierte Bindings, Receipts, Proof-Checks, PLANT, WRAP und Continuation-Handling
src/apex/core/	Gemeinsames Protokoll, Ergebnistypen, Aggregation und anbieterneutrale Modellgrenze
benchmark/adapter/	Schreibgeschützte Konvertierung von Benchmark-Releases in eine einheitliche BenchmarkCase-Schnittstelle
benchmark/registry/	Vertrauenswürdige Fähigkeitsregistrierung und benchmarkspezifische Manifeste
baseline/<name>/	Eine Implementierung oder Runtime-Integration pro Vergleichsmethode
tests/	Repository-Invarianten und schnelle Unit-Checks

Siehe STRUCTURE.md für den Komponentenfluss und die Erweiterungspunkte.

Laden von Benchmark-Fällen

Kompakte eingefrorene Fallbeschreibungen für alle sechs Benchmarks sind unter benchmark/data/ enthalten. Vollständige Upstream-Repositories und Runtime-Sandboxes werden nicht mitgeliefert. Die Übergabe von None wählt die paketierten Daten aus; ein expliziter data_root kann diese weiterhin überschreiben.

from benchmark.adapter import adapter_for

adapter = adapter_for("scr", None)
attack_cases = list(adapter.cases("attack"))

Der Adapter besitzt Fallbezeichner, Split-Labels, Suite-Labels, Eligibility und die Payload, die der Benchmark-Runtime präsentiert wird. Er verändert keine Benchmark-Inhalte und registriert keine Tool-Autorität.

Laden vertrauenswürdiger Manifeste

from benchmark.registry import module_for

registry = module_for("mcptox")
environment_plan = registry.load("12306-mcp")

Fähigkeitsmanifeste werden getrennt von Dataset-Adaptern gehalten, da Benchmark-Text nicht vertrauenswürdige Episodeneingabe ist, während ein Manifest die operator-eigene Ausführungsgrenze beschreibt, die vor der Episode verfügbar ist.

Jede benchmark/registry/data/<benchmark>/manifest.json ist ein finales Registry-Artefakt, das apex-benchmark-registry-v2 verwendet. Ein Bundle speichert deduplizierte capability_units, wiederverwendbare Umgebungen und explizite Fallbindungen. Somit dupliziert ein Benchmark mit Hunderten von Fällen ein identisches Tool-Manifest nicht hunderte Male. Jede Unit behält das exakte Input/Output-Schema, effect, observation, effect_return, die Receipt-Rolle und typisierte Annotationen. Jede Umgebung zeichnet separat Quellen, Skills und agent_visible_surface auf.

Die exakten auditierten Quelleneingaben aus der Experiment-Implementierung werden unter benchmark/registry/source/ gehalten. Der Build-Schritt normalisiert und dedupliziert diese bestehenden Registrierungen; er leitet keine neuen Fähigkeitssemantiken aus Benchmark-Prompts ab. Regeneriere alle finalen Artefakte mit:

pip install -e '.[registry]'
python scripts/build_registry_manifests.py
python scripts/audit_registry_coverage.py

Um paketierte Fallbeschreibungen aus lokalen Upstream-Checkouts zu aktualisieren, führe aus:

python scripts/import_benchmark_data.py \
  --research-root <research-checkout> \
  --scr-root <SCR_Bench-checkout>

Der SCR-Importer verifiziert den gepinnten Commit, bevor er seinen kompakten Fall/Skill-Exposure-Index ableitet.

APEX-Ausführungsfluss

1. TaskContractor kompiliert die vertrauenswürdige Benutzeranfrage in einen Task-Vertrag.
2. Die Benchmark-Registry liefert die saubere Fähigkeitsoberfläche.
3. Die Engine löst typisierte Werte auf und zeichnet Beobachtungen als Receipts auf.
4. PLANT prüft die Provenienz auf Task-Ebene und die Commitment-Struktur.
5. WRAP prüft den vollständigen vorgeschlagenen Effekt gegen den Vertrag und die Receipts.
6. Die Engine gibt Allow-, Deny-, Repair- oder Replan-Continuation-Informationen zurück.

Die deterministischen Checks bleiben unabhängig vom Zielmodell. Modellgestützte Rollen reichen typisierte Kandidaten ein, die dieselbe Validierungsgrenze passieren müssen.

Baselines

baseline/registry.py definiert die 13 Vergleichsmethoden. Jede Methode hat einen dedizierten Ordner, der nach der Methode benannt ist, und einen implementation.py-Einstiegspunkt. Abhängigkeiten mit eigener Runtime werden lazy importiert, sodass der APEX-Kern und die Datenadapter getestet werden können, ohne alle Benchmark-Umgebungen zu installieren.

Verifikation

python -m compileall -q src benchmark baseline tests
pytest

Führe vor der Veröffentlichung außerdem die Anonymitätsprüfungen in ANONYMITY.md aus. Es sollten keine Credentials, Ergebnisdateien, maschinenspezifischen Pfade, Git-Remotes oder Autorenmetadaten zur Einreichung hinzugefügt werden.