NCE — Neuro-Cognitive Engine

Ein Multi-Tenant-Speicher- und Reasoning-Substrat für KI-Agenten, mit einer Reihe von darauf aufbauenden Geschäfts-Engines.

Agenten, die ein Geschäft betreiben, müssen sich Dinge merken, und das Gedächtnis muss korrekt sein: auf den richtigen Mandanten beschränkt, einer Quelle zurechenbar und unmöglich leise zu korrumpieren. NCE ist die Schicht, die dies bereitstellt, plus die vertikalen Engines, die es nutzen — procurement, sales, project, economy, inventory und andere.

Erstellt in Python auf Postgres, MongoDB, Redis und MinIO. Verfügbar über MCP (JSON-RPC 2.0) und REST.

Was tatsächlich hier ist

Die Zahlen werden aus dem Baum gezählt, nicht geschätzt. Die Tool-Anzahl wird durch einen Test (tests/test_tool_registry.py) bestätigt, sodass sie nicht von der Realität abweichen kann, ohne den Build zum Scheitern zu bringen.

Die Teile, die einen Blick wert sind

Die Mandantenisolierung wird von der Datenbank erzwungen, nicht durch Konvention. Jede mandantenbezogene Tabelle trägt ENABLE + FORCE ROW LEVEL SECURITY mit einer Richtlinie auf namespace_id. Der Anwendungscode filtert zusätzlich explizit, da eine Superuser-Verbindung FORCE RLS umgeht und ein Test, der dies vergisst, nichts beweist. tests/test_rls_catalog.py schlägt fehl, wenn eine Mandantentabelle hinzugefügt wird, ohne registriert zu sein.

Schreibberechtigung ist standardmäßig verweigert. Engines schreiben nicht die Daten der anderen. nce/config_data/node-ownership.json bildet (node_type, transition) → owning engine ab, und assert_owner verweigert alles, was an der Schreibstelle nicht registriert ist. Der Besitz kann pro Transition sein, nicht nur pro Knoten: Der ORDERED-Status einer Bestellposition gehört zu Procurement, DELIVERED zu Warehouse, INSTALLED zu Field Tech, und dieselbe Wächterfunktion drückt alle drei aus.

Das Audit-Log ist auf Datenbankebene nur zum Anhängen. event_log hat einen WORM-Trigger; UPDATE und DELETE sind widerrufen, nicht nur vermieden.

Autonomie ist begrenzt. Welt-schreibende Tools sind standardmäßig nur mit menschlicher Bestätigung, tragen einen Idempotenzschlüssel und zeichnen im Audit-Log auf. Wert- und Volumengrenzen, eine Whitelist und ein Kill-Switch sind ihnen vorgeschaltet. Das Wiederholen einer Aktion ist ein No-op und kein zweiter Schreibvorgang.

Geld und Kosten verlassen nie das Gebäude. Ein Whitelist-Feldprojektor (project(node, surface)) steuert, was eine externe Oberfläche erreicht. Marge und Kosten stehen auf keiner Whitelist.

Generierter Text ist fundiert. Prosa wird aus bereits im Graphen vorhandenen Fakten zusammengesetzt, wobei jede Behauptung mit dem Knoten verknüpft ist, von dem sie stammt, anstatt freihändig erstellt und später überprüft zu werden.

Daten können gleichzeitig aus zwei Systemen stammen. Ein pro-Namespace-Resolver entscheidet, ob eine bestimmte Funktion von Dynamics 365, von NCE oder von beiden liest, und protokolliert Abweichungen, wenn die beiden nicht übereinstimmen – so kann eine Migration gemessen werden, bevor sie festgelegt wird.

Vertikale Engines

Elf Engines haben Code auf main. Jede besitzt ihre eigenen Tabellen, ihre eigenen Knotentypen und eine dokumentierte Grenze zu den anderen.

procurement · product · agreements · vendors · sales · system_design · project · economy · inventory · dynamics365 · diagnostics

Die Engine-Suite ist auf 17 geplant. Sie wird inkrementell aufgebaut und ist nicht fertig; siehe Status unten.

Wie es gebaut wird

Die Engine-Suite wird nicht in einem Durchgang von Hand geschrieben. Sie wird als eine Abfolge kleiner Einheiten aufgebaut – 229 geplant, jede ein Anliegen, jede auf ihrem eigenen Branch und Commit – und jede Einheit besteht eine unabhängige adversarial Review, bevor sie akzeptiert wird.

Die Review wird von einer anderen Modellinstanz durchgeführt als der, die den Code geschrieben hat, mit der spezifischen Anweisung, es zu versuchen zu brechen und bei Unsicherheit standardmäßig abzulehnen. Das hat sich wiederholt als wichtig erwiesen:

• Eine Änderung der Lagerbewegung wurde mit einer Graphprojektion ausgeliefert, die innerhalb der autoritativen Transaktion geschrieben wurde. Sie führte bei jedem zweiseitigen Verkehr zwischen denselben zwei Standorten zu einem Deadlock, bei 100% der Versuche. Lint bestanden, Typen bestanden, die Testsuite war grün. Die Review fand es und die Lösung war, sowohl die Zeilenschreibvorgänge als auch die Projektion nach einem kanonischen Schlüssel zu ordnen.

• Eine Änderung des Event-Busses hätte Ereignisse als erfolgreich veröffentlicht markiert, während sie stillschweigend fallen gelassen wurden, weil ein Handler protokollierte und zurückkehrte, anstatt zu werfen. Die Review lehnte es zweimal ab, bevor etwas ausgeliefert wurde.

• Ein Test, der eine Dezimalgenauigkeitsregel behauptete, bestand identisch, unabhängig davon, ob die Regel angewendet wurde oder nicht, weil seine einzige Fixture unter beiden Pfaden gleich rundete.

Die wiederkehrende Lektion ist, dass eine grüne Testsuite weniger aussagt, als es scheint. Die Eigenschaften, die fehlschlagen, sind normalerweise diejenigen, für die ein Docstring am zuversichtlichsten argumentiert und die kein Test tatsächlich unterscheidet.

Ausführen

cp .env.example .env          # fill in the values
make local-up                 # Postgres, MongoDB, Redis, MinIO via docker compose
make lint typecheck           # ruff + mypy
pytest -m "not integration"   # unit tests, no database required
pytest -m integration         # requires the stack above

Integrationstests überspringen, anstatt fehlzuschlagen, wenn keine Datenbank erreichbar ist. Ein grüner Exit-Code mit übersprungenen Tests ist kein bestandener Durchlauf – überprüfen Sie die Zählungen.

Dokumentation

Die vollständige Dokumentation ist veröffentlicht unter sindrehaugen.github.io/neuro-cognitive-engine – Architektur, die acht Architekturentscheidungsaufzeichnungen, pro-Engine Admin- und Benutzerhandbücher, die Shared-Core-Referenz und das MCP-Tool-Kochbuch.

Lohnenswert zu beginnen mit:

• Architektur – der Vier-Datenbanken-Stack und wie die Schichten sitzen

• Shared Core – Entitätsauflösung, Besitz, Autonomie-Governance, Redaktion

• Multi-Tenancy – wie FORCE ROW LEVEL SECURITY angewendet wird

• MCP-Tool-Kochbuch – die Tool-Oberfläche mit Gating-Flags

• ADRs – Entscheidungen und ihre Abwägungen

Layout

nce/                    engine core: memory, graph, RLS, autonomy, signing, replay
nce/vertical_modules/   the business engines
nce/migrations/         idempotent SQL, re-applied on boot under an advisory lock
tests/                  391 files; integration tests marked and CI-wired
docs/                   source for the published documentation
go/                     launcher and hardware detection
trimcp-infra/           Terraform for AWS and GCP
deploy/                 compose stacks and container images

Status

In aktiver Entwicklung. Elf von siebzehn Engines haben Code auf main; die zwölfte ist in Arbeit. Das Kernsubstrat – Mandantenisolierung, Besitz, Autonomie-Governance, Audit-Log, Signierung, Wiederholung – ist vollständig und wird von den darüber liegenden Engines verwendet.

Dieses Repository wird veröffentlicht, um die Architektur und den Engineering-Ansatz zu zeigen. Es ist kein verpacktes Produkt und es gibt keine Support-Verpflichtung.

Lizenz

Proprietär. Alle Rechte vorbehalten. Zur Überprüfung veröffentlicht; nicht zur Wiederverwendung lizenziert.

Sindre Løvlie Haugen · github.com/sindrehaugen