From 611311c6a4c4f04fabf9c881e90b912242047e71 Mon Sep 17 00:00:00 2001 From: Laszlo Puskas Date: Fri, 17 Jul 2026 11:22:08 +0300 Subject: [PATCH 1/5] docs(analitics): clarify c1 status semantics and module layout in readme Signed-off-by: Laszlo Puskas --- analitics/README.md | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/analitics/README.md b/analitics/README.md index 416ce28d..03310ea1 100644 --- a/analitics/README.md +++ b/analitics/README.md @@ -74,14 +74,17 @@ analitics/ │ ├── echo-client/ # Responder/sink helper │ └── rate-client/ # Traffic generator ├── tests/ -│ ├── c1_evidence_test.go -│ └── c1_evidence_report.go +│ ├── suite_test.go # Ginkgo bootstrap +│ ├── c1_evidence_test.go # C1 use-case specs + behavioral assertions +│ ├── c1_evidence_report.go # JSON report model + upsert helpers +│ └── c1_evidence_report_test.go # unit tests for the report helpers ├── templates/ │ └── dashboard.html.tmpl ├── scripts/ │ ├── evidence-lib.sh │ ├── render-dashboard.sh │ └── render-evidence-report.sh +├── bin/ # generated (gitignored): downloaded slimctl ├── reports/ # generated (gitignored) └── published/ # generated (gitignored) ├── index.html @@ -98,12 +101,14 @@ analitics/ ## Status evaluation (C1) -C1 use-case status is derived from `reports/c1-evidence.json` -(produced by Ginkgo tests in `tests/c1_evidence_test.go`): +C1 use-case status is read from the `status` field of each case in +`reports/c1-evidence.json` (produced by Ginkgo tests in `tests/c1_evidence_test.go`): -- `verified` — assertion-based test passed for the mode -- `failed` — test failed or case reports non-zero errors -- `unknown` — no case entry for the mode +- `verified` — the mode's behavioral assertions passed; the test records this case as `verified` +- `failed` — the case is recorded with a `failed` status +- `unknown` — no case entry exists for the mode (e.g. the report is missing or the spec did not run) + +The render step reads these values as-is; it does not re-run or re-evaluate the tests. C2/C3 rows use static status until their test evidence is wired into the build flow. @@ -116,7 +121,8 @@ CSIT test reports site under **`docs/agentic-evidence/`** on the `gh-pages` bran ## Prerequisites -- Go 1.22+ +- Go 1.24+ (matches `go.mod`) - `task` in the shell +- `jq` and `bash` on `PATH` (used by the render scripts) - Native SLIM bindings for CGO (`task -t analitics/Taskfile.yml deps:slim-bindings-setup`) - `slimctl` on `PATH`, or install via `task -t analitics/Taskfile.yml deps:slimctl-download` From 0b58f8e86a3e3b3e11bdc2675431663dbb8180c3 Mon Sep 17 00:00:00 2001 From: Laszlo Puskas Date: Fri, 17 Jul 2026 16:24:14 +0300 Subject: [PATCH 2/5] docs(analitics): clarify c1 status semantics and module layout in readme Signed-off-by: Laszlo Puskas --- analitics/templates/dashboard.html.tmpl | 131 +++++++++--------------- 1 file changed, 51 insertions(+), 80 deletions(-) diff --git a/analitics/templates/dashboard.html.tmpl b/analitics/templates/dashboard.html.tmpl index 7f8556a5..6dd374d8 100644 --- a/analitics/templates/dashboard.html.tmpl +++ b/analitics/templates/dashboard.html.tmpl @@ -65,10 +65,38 @@

SLIM evidence by agentic system class

-

SLIM is the messaging layer for agent systems. This page maps CSIT test evidence to the agentic-system taxonomy: each class section lists related use cases, and each use case links to test-derived evidence.

+

SLIM is the messaging layer for agent systems. This page maps CSIT test evidence to the agentic-system taxonomy: each class section lists related use cases, and each use case links to test-derived evidence where it is available.

Last updated: {{GENERATED_AT}} · Contract: C1 evidence v1 · Discussion #195

+ +
+

The agentic-system taxonomy

+

Agentic systems are grouped into three classes by who controls message flow and agent coordination — not by model vendor, language, or agent count.

+ + + + + + + + + + + + + + + + + + + + + +
ClassDefinition
C1 · CentralizedA single authority — runtime, broker, or control plane — owns routing and invocation. Agents connect through it rather than negotiating peers or paths themselves.
C2 · DecentralizedNo single global brain, but coordination is scripted: a workflow manager or declared route graph defines who talks to whom and in what order.
C3 · DistributedAgents and dataplanes act as peers across hosts and clusters. Paths are established through control-plane links and policy, not a fixed workflow script.
+
+

C1 · Centralized

@@ -91,8 +119,8 @@ -
Agent A calls B and waits for a reply
-
Named endpoints with synchronous round-trip on one node
+
Agent calls another and waits for a reply
+
Synchronous round-trip between named endpoints on a single SLIM node
request-reply {{C1_RR_STATUS_SPAN}}
{{C1_RR_ROWS}} C1 evidence case(s)
@@ -107,8 +135,8 @@ -
Agent fires event; consumer handles async
-
One-way delivery through a single SLIM authority with sink observation
+
Agent emits an event; a consumer handles it asynchronously
+
One-way delivery through a single SLIM node, observed at the sink
fire-and-forget {{C1_FF_STATUS_SPAN}}
{{C1_FF_ROWS}} C1 evidence case(s)
@@ -123,8 +151,8 @@ -
Publish into mesh without paired responder
-
Ingress/write path without a bound responder process
+
Publish into the mesh without a paired responder
+
Write/ingress path with no bound responder process
write {{C1_W_STATUS_SPAN}}
{{C1_W_ROWS}} C1 evidence case(s)
@@ -153,59 +181,35 @@

C2 · Decentralized

Workflow or route graph coordinates agents

- Partial + Evidence pending
-

No single global brain, but coordination is scripted: a workflow manager or declared route graph defines who talks to whom and in what order.

+

No single global brain, but coordination is scripted: a workflow manager or declared route graph defines who talks to whom and in what order. Agents follow the graph; autonomy is bounded by it.

+

The use cases below define the target scenarios. Test-derived evidence is not yet available.

- - - - - - - - -
Use case SLIM mechanismStatusTest / scenarioEvidence
-
Multi-agent scenario with fixed routes (Alice/Bob)
-
Named multi-hop delivery across SLIM servers
+
Multi-agent flow over fixed, named routes
+
Messages traverse several SLIM servers by name (e.g. one agent waits while another sends through intermediate nodes)
 declarative routesPartialTopology test
integrations/agntcy-slim		 - -
-
Multi-step app driven by workflow manager
-
SLIM under external workflow steps
+
Multi-step application driven by a workflow manager
+
An external workflow engine sequences the steps while SLIM carries messages between them
 workflow + SLIMPlannedagntcy-apps campaigns
integrations/agntcy-apps		 -
    -
  • Narrative only — evidence TBD
    • -
-
- -
-

Test evidence: topology routing (planned integration)

-

Multi-node · integrations/agntcy-slim topology Ginkgo suite

-

Will link topology test reports when wired into the analitics publish flow.

-
Rerun (dev):
task integrations:slim:test:topology
-
@@ -213,75 +217,42 @@

C3 · Distributed

Peers across clusters; control plane establishes links

- Verified + Evidence pending
-

Dataplanes operate as peers across hosts or clusters. Paths are established via control-plane links and policy, not a fixed workflow script.

+

Agents and dataplanes act as peers across hosts, clusters, or org boundaries with no standing workflow script. Paths are established through control-plane links and policy, and the emphasis is on mesh membership and durability.

+

The use cases below define the target scenarios. Test-derived evidence is not yet available.

- - - - - - - - - - - -
Use case SLIM mechanismStatusTest / scenarioEvidence
-
Downstream cluster joins controller mesh
-
Node Connected, link APPLIED B → A
+
Downstream cluster joins the controller mesh
+
A dataplane on one cluster registers with the controller on another and the cross-cluster link is applied
 controller linkVerifiedMulticluster controller link
kind-slim-multicluster		 - -
-
Autonomous peers across hosts (no fixed WFSM)
-
Federation + optional routes
+
Autonomous peers across hosts
+
Peers exchange messages across hosts or clusters without a fixed workflow, via federation and optional routes
 federationRefineMulticluster / peer-to-peer config -
    -
  • Evidence contract TBD
    • -
-
- -
-

Test evidence: multicluster controller link

-

kind-slim-multi-host + integrations/kind-slim-multicluster

- 
cluster A: controller + root node
-cluster B: downstream node
-Link B → A: APPLIED · node B: Connected
-
Rerun:
CSIT_KIND_SLIM_MULTICLUSTER=1 go test ./integrations/kind-slim-multicluster/... -ginkgo.label-filter=kind-slim-multicluster
-