daSPE.AI — Connect your organisation
Version checked: 2 November 2026
https://cotrugli.tech/daspe/connect/

WHAT TO CONNECT
One data service, model, application or infrastructure capability. The existing
Co-Tru Agent Market LAB is a starting example: offer, order, deliver, check and
accept, account, return proof. Agents act under their organisation's mandate.

DEPLOYMENT OPTIONS
1. Docker / Kubernetes: Linux/amd64 container, dedicated persistent book,
   restricted application access and one writer per identity.
2. Native Linux: the same server-edge runtime, pinned environment and managed
   service, with dedicated configuration, trust and durable data paths.
3. Hosted: a separate edge for your organisation on an agreed provider.
   Hosting location, capacity, key control and original custody are agreed.
The edge itself needs no GPU.

SERVER PACKAGE
TRU edge 2026.11.03. Docker/Kubernetes and Linux systemd packages
carry the same pinned source manifest. The pack provides SHA256SUMS and RELEASE.json.
Native package: tru-edge-source.tar.gz (offline source and wheels).
Native requirements: Linux x86_64, Python 3.12 and venv; installation uses
deploy/partner-edge/install_linux.py with the assigned configuration and trust.
The installer creates the service; your administrator starts it after review.
Artifacts are delivered through the private organisation connection process.

CONNECTION PACK
Organisation/member/edge identifiers; authorised administrator and wallet
binding; participation rules; exact package and hashes; installation profile;
private mTLS route and certificate steps; independently checked trust; producer
and reader access; retention and backup; service terms, budget and mandate.
Keep the private key local. Send only a certificate request for signing.
An organisation account brings together people, applications, authority, budgets
and obligations. The public form does not create an account or grant access.

NETWORK
Application -> private edge intake.
Authorised reader -> private read interface.
Edge -> assigned mTLS route over outbound HTTPS 443 -> ledger/proof services.
Tunnel and edge share the pod or network namespace. Native intake and reader
have no built-in client authentication/TLS: do not expose them publicly.

FIRST EVENT
Choose a completed model call, delivered message, allocation or data query.
Start with a synthetic original using the same event fields as your application.
POST /v1/audit on private port 4311 accepts application/x-protobuf (OTLP),
not arbitrary JSON. The pack supplies the offline example generator.
Required: assigned neo.provider.id, audit.* event_name, fixed timestamp,
audit.record.id, audit.actor.id, audit.actor.type, audit.action, audit.outcome.
Use audit.target.id and agreed typed fields to associate the job. The example
body is the SHA-256 of a retained original. Keep original and submitted bytes.
The envelope hash and original hash are distinct references.
Submit the saved request from an approved producer. HTTP 200 means written at
the edge; continue business. The rail's three grades of acceptance follow
asynchronously: RECEIVED, SEALED, PROVEN (see THREE GRADES below).
For uncertain delivery, reuse the same identity and exact bytes through your
durable retry path. Follow the package's bounded deduplication rules.
Private TCP reader port 9600 supports STATUS, RECORDS, BLOB and CONFIRM.
Check the book reference, obtain the PROVEN record's proof, verify it with
independent trust, and read it again after restart without submitting another
event.

THREE GRADES OF ACCEPTANCE
Written at the edge: HTTP 200; the record is in your book; the rail has not
seen it. 1 RECEIVED: the rail holds the period's 32-byte commitment in its
open period. 2 SEALED: the cell folded the period into its root and the
ledger sealed that root (two witnesses, Ed25519 and ML-DSA-65). 3 PROVEN: your
edge fetched and verified the proof and the sealed receipt against its own
chain; this is what you verify offline. PROVEN proves existence, form, time
and order, not truth, completeness or business acceptance. None of the grades
is called "final". Typically about 20 minutes to PROVEN, up to about an hour.
The 2026.11.03 software still writes FINAL for PROVEN; a later package uses
the new word and still accepts the old one.

PREPARE YOUR REQUEST
Organisation and technical contact; contribution; Docker/Kubernetes, native or
hosted preference; application interface; expected volume; first service and
data boundaries. Use the form to download a local draft or send the request.
Do not include credentials, private endpoints or original business documents.
The operator confirms identity, authority and package readiness before activation.
Contact: drazen.kapusta@cotrugli.org
Rules: https://cotrugli.tech/demo/chamber-rules/