Witness Evidence

Offene Evidenz-Ebene für agentische Systeme

Ihre Agenten können handeln. Witness bewahrt, was entschieden wurde, welche Evidenz angehängt wurde und was der nächste Agent erben darf.

KI-Agenten können handeln. Witness macht ihre Arbeit nachvollziehbar.

Agenten werden zu einer Software-Arbeitskraft. Ihre akzeptierte Wahrheit steckt noch zu oft in einem Chat-Protokoll fest: Ein Planer wählt eine Richtung, ein Builder meldet „fertig“, ein Validator kommt später, und das nächste Modell muss rekonstruieren, warum jemand dem Ergebnis vertraut hat.

Witness Evidence richtet sich an Ingenieure für Agentenplattformen und KI-Infrastruktur, deren Agenten, Modelle und Spuren schneller wachsen als ihre Fähigkeit, den akzeptierten Projektzustand zu bewahren. Es zeichnet identitätsgebundene Entscheidungen, angehängte Evidenz, Ergebnisse, Lebenszyklusänderungen und begrenzten Projektkontext über MCP auf.

Delegieren Sie die Ausführung, ohne die Wahrheit zu delegieren.

Führen Sie die echte lokale Demo des v0.1.0-Kerns aus · Sehen Sie, was heute läuft · Erkunden Sie die Funktions-Roadmap · Prüfen Sie den Beweisstatus

Related MCP server: Clockchain Developer Tools MCP Server

Wo Witness passt

MCP connects agents to tools.
A2A connects agents to agents.
Traces show what ran.
Durable runtimes keep workflows alive.
Witness preserves what was decided, which evidence was attached, which status transitions followed, and what the next agent may inherit.

Witness ersetzt keine Agenten-Laufzeiten, kein Tracing, keine Orchestrierung, kein Git und keine Observability. Es sitzt über den Ausführungsdetails als dauerhafte Evidenzgrenze: der Ort, an dem ein Team die Entscheidung, auf die es reagiert hat, das erzielte Ergebnis, eine Evidenzreferenz, die Identität, die jeden Statusübergang durchgeführt hat, und den Kontext, den ein späterer Agent wiederherstellen darf, aufzeichnet.

Das Fehlermuster

Ohne eine gemeinsame Evidenzebene wird ein Multi-Agenten-System zu einem Haufen selbstbewusster Transkripte:

Planner:   “Build the release.”
Builder:   “Done.”
Validator: “Which bytes? Which requirements? Why this design?”
Next run:  “I have no context from the previous chat.”
Owner:     reconstructs everything by hand.

Das dauerhafte Objekt sollte nicht das Gespräch sein. Es sollte der bezeugte Projektzustand sein.

Läuft heute

Version 0.1.0 führt einen lokalen Open-Source-Evidenzkern aus:

• 10 MCP-Tools für Projekte, Entscheidungen, Erkenntnisse, Ergebnisse, Aufzeichnungen, Lebenszyklus, begrenzten Kontext und FTS5-Suche;

• signierte Agenten-Identitätshüllen, die an das genaue Tool, die Anforderungslast, den Mandanten, das Profil, die Laufzeitgenerierung und die Nonce gebunden sind;

• rollenbasierter Standard-Verweigerungszugriff und idempotente Mutationen;

• Datenschutz-Schwärzung vor der Persistierung;

• SQLite-Persistenz mit transaktionalem Append-only-Betriebsprüfprotokoll;

• ein echter lokaler Ablauf mit getrennten Builder- und Validator-Identitäten;

• reproduzierbare Apache-2.0-Release-Artefakte und ein gestufter Fresh-Install-Doctor.

In der enthaltenen Demo verschiebt eine separate synthetische Validator-Identität das Ergebnis auf verified. Der Übergang zeichnet diesen Akteur und seinen Grund auf. Version 0.1.0 erzwingt keine Builder/Validator-Trennung, legt die based_on-Evidenzreferenz des Ergebnisses nicht über die öffentliche Lese-Projektion offen, ruft das referenzierte Artefakt nicht ab und entscheidet nicht automatisch über die Korrektheit. Dies ist keine automatische Evidenzverifizierung.

Sehen Sie das System in Bewegung

sequenceDiagram
    actor Owner
    participant Planner
    participant Builder
    participant Validator
    participant Witness
    participant NextAgent as Next agent / model

    Owner->>Planner: Ship a validated release
    Planner->>Witness: Record decision + acceptance rule
    Planner->>Builder: Build exact candidate
    Builder->>Witness: Record outcome + evidence reference
    Validator->>Witness: Read decision and outcome
    Validator->>Witness: Accept or dispute the result
    NextAgent->>Witness: Restore bounded project context
    Witness-->>NextAgent: Decision + outcome + acceptance state

Das Repository enthält einen echten lokalen MCP-Ablauf. Er erstellt eine temporäre Datenbank, verwendet separate signierte synthetische Builder- und Validator-Identitäten, schreibt eine Entscheidung und ein Ergebnis, verschiebt das Ergebnis von recorded auf verified und stellt den Projektkontext wieder her.

[1/3] Decision recorded: require independent validation
[2/3] Outcome verified by a distinct validator identity
[3/3] Project context restored from the database
WITNESS_DEMO_PASS decisions=1 outcomes=1 outcome_status=verified distinct_validator=true context_restored=true

Evidenzklasse: echter lokaler Produktablauf. Die Demo führt den öffentlichen MCP-Server und die Persistenzschicht mit synthetischen Anmeldeinformationen aus. Es ist kein Cloud-Screenshot, keine simulierte Antwort und kein Beweis für eine externe Integration.

Führen Sie die echte Demo aus

git clone https://github.com/MaximilianoColoma/witness.git
cd witness
uv sync --locked
uv run python examples/coordinated_autonomy_demo.py

Erwartete letzte Zeile:

WITNESS_DEMO_PASS decisions=1 outcomes=1 outcome_status=verified distinct_validator=true context_restored=true

Was dies ermöglicht

Rechenschaftspflichtige Builder

Ein Builder kann Arbeit produzieren, und eine andere Identität kann den späteren Überprüfungsübergang durchführen, wie die Demo zeigt. Teams müssen jede erforderliche Builder/Validator-Trennung in ihrer eigenen Richtlinie durchsetzen, bis Witness diese Invariante hinzufügt.

Modellunabhängige Kontinuität

Ersetzen Sie das Modell, starten Sie den Prozess neu oder setzen Sie nächste Woche fort. Ein späterer Agent kann begrenzte Projektobjekte abrufen, anstatt ein altes Transkript rückzuentwickeln.

Evidenzbasierte Gates

Entscheidungen, Ergebnisse, Belege und Statusübergänge werden abfragbare Eingaben für CI, Release-Governance, Incident-Review und menschliche Genehmigung.

Speicher mit Grenzen

Witness ist kein Transkript-Dump und kein generischer RAG-Speicher. Es persistiert deklarierte Projektobjekte, schwärzt unterstützte personenbezogene Daten vor der Persistierung, begrenzt Lesezugriffe und verweigert nicht deklarierte Autorität.

Audit, das gewöhnliche Produktaufrufe nicht beiläufig umschreiben können

Mutationen des öffentlichen Kerns und Audit-Ereignisse werden gemeinsam oder gar nicht committet. Kanonische Trigger schützen die Operationshistorie vor Aktualisierung und Löschung über den normalen Anwendungspfad.

Nächste Entwicklungen

Modellübergreifende Projektkontinuität

Die nächste Entwicklerfähigkeit ist ein portabler Kontinuitätsvertrag: Claude, Codex, GPT, lokale Modelle und spezialisierte Agenten sollten in der Lage sein, denselben begrenzten Witness-Projektzustand zu verwenden und die Arbeit ohne Zugriff auf den ursprünglichen Chat fortzusetzen.

Dies ist geplant, aber noch nicht extern bewiesen. Der Beweis erfordert, dass ein anderes Agententeam die aktuelle Entscheidung, die angehängte Evidenz und den Akzeptanzzustand rekonstruiert; Rekonstruktionszeit und Fehlerfälle müssen gemessen werden. Siehe EVIDENCE.md.

In v0.1.0 werden keine First-Party-Adapter für Claude, Codex, OpenAI Agents SDK, LangGraph oder Temporal ausgeliefert. Heute können diese Systeme Witness nur über benutzerdefinierte MCP/Client-Verdrahtung erreichen, die vom Integrator erstellt wird. Dokumentierte Referenzadapter sind Roadmap-Arbeit, keine aktuelle Funktionalität.

Nordstern

Witness strebt danach, die offene Evidenz- und Lerninfrastruktur zu werden, durch die eine Agentenorganisation bewahrt, was sie über Agenten, Modelle, Läufe und Systeme hinweg entschieden, bewiesen und gelernt hat.

Dieser Nordstern umfasst portable Verifizierung und verifizierte Lernrückführung: Akzeptierte Ergebnisse können spätere Arbeiten informieren, ohne dass unverifizierter Text stillschweigend zur Richtlinie wird. Es ist kein automatisches modellübergreifendes Lernen in v0.1.0.

Zwei-Produkt-Architektur

Mission ist ein separates Produkt. Spindle ist die geplante Lernfunktion innerhalb von Witness.

Mission koordiniert Agentenarbeit. Witness bewahrt Evidenz und ist darauf ausgelegt, verifiziertes Lernen zu verstärken.

flowchart LR
    H["Human<br/>goal and direction"] --> M["Mission<br/>coordinates"]
    M --> G["Specialist agents<br/>work"]
    G --> E

    subgraph W["Witness"]
        E["Decision · Outcome · Evidence"] --> S["Spindle<br/>planned learning function"]
        S --> L["Patterns · Rules · Guards"]
    end

    L -. "future governed return" .-> M

Der Evidence Core läuft heute. Die vollständige Spindle-Lernschleife ist geplant. Ihre zukünftige Aufgabe innerhalb von Witness besteht darin, Ergebnisse im verified-Lebenszyklusstatus von Witness zu übernehmen und sie nach zusätzlichen Eignungs- und Überprüfungs-Gates in verwaltete Lernkandidaten, wiederverwendbare Muster, Regeln und Schutzmaßnahmen für spätere Mission-Läufe umzuwandeln. Der Status zeichnet einen Akzeptanzübergang auf; er beweist nicht von selbst, dass Witness die zugrunde liegende Evidenz abgerufen oder unabhängig validiert hat. Version 0.1.0 generiert diese Artefakte nicht und führt sie nicht automatisch zurück.

Traumfunktionen

Dies sind aktivierte Muster, keine gebündelte Orchestrierung heute:

• modellübergreifende Kontinuität ohne Transkriptzugriff;

• portabler Beweis, den ein externer Validator prüfen kann, ohne der Erzählung des Builders zu vertrauen;

• verifizierte Lernrückführung durch Spindle, die geplante interne Witness-Lernfunktion;

• eigentümerlesbare Autonomie mit einer dauerhaften Entscheidungskette;

• Incident-Speicher, der akzeptierte Grundursache und Prävention in spätere Missionen überträgt.

Jeder Token sollte das System wertvoller verlassen als zuvor. Das ist die Produktrichtung, keine aktuelle Effizienz- oder Wirtschaftlichkeitsbehauptung.

Mission und Witness sind die beiden Hauptprodukte. Mission koordiniert Arbeit; Witness besitzt die Evidenzgrenze und die geplante Spindle-Lernfunktion. In v0.1.0 wird keine automatische Lernrückführung von Witness zu Mission ausgeliefert.

Jetzt gebaut – und noch nicht

Der Dienst wird von diesem Repository nicht bereitgestellt. Veröffentlichung und grüne CI beweisen keinen Produktionsbetrieb, keine Skalierung, keine Einsparungen und keine Benutzerwirkung.

Öffentliche MCP-Oberfläche

Kanonische Verträge befinden sich unter spec/. FTS5 ist lokale Textsuche, keine semantische oder Vektorsuche.

Installieren und verifizieren

Erfordert Python 3.11+ und uv.

./install.sh --manifest --json
./install.sh --target "$HOME/.local/share/witness" --non-interactive --json
uv sync --locked
uv run python -m pytest -q -p no:cacheprovider tests repair-tests
uv build

Der gestufte Installer bereinigt geerbte Python-Umgebungsvariablen, führt eine gesperrte Installation durch, schreibt begrenzte lokale Konfiguration und Speicherung und führt einen echten MCP-Erstlauf-Doctor aus.

Benennung und technische Identität

Witness Evidence ist der öffentlich sichtbare Qualifier; technische Bezeichner bleiben unverändert. Das Repository MaximilianoColoma/witness, das Paket witness-public, das Python-Modul witness_public, die MCP-Toolnamen, Verträge und veröffentlichten v0.1.0-Artefakte behalten ihre bestehenden technischen Bezeichner. Kurz gesagt: Die Geschichte ist klarer; die Leitung bleibt, wo sie ist.

Ein nicht verwandtes etabliertes Projekt verwendet ebenfalls den Namen Witness. Siehe TRADEMARKS.md für den Hinweis zur Verwechslungsgefahr.

Projektzentrum

• Funktions-Roadmap: ROADMAP.md

• Evidenz- und Beweisstatus: EVIDENCE.md

• Governance und Release-Befugnis: GOVERNANCE.md

• Beiträge und DCO: CONTRIBUTING.md

• Sicherheitsmeldung: SECURITY.md

• Support-Grenzen: SUPPORT.md

• Benennung und Verwechslungsschutz: TRADEMARKS.md

Lizenz

Lizenziert unter der Apache License 2.0. Siehe NOTICE. Apache-2.0 erlaubt Nutzung, Modifikation, Weiterverbreitung und kommerzielle Nutzung; es gewährt keine Erlaubnis, einen offiziellen Projektstatus oder eine Markenunterstützung zu implizieren.