What is integrated, and what is only designed
The five projects are separate repositories. Several are described together on the organisation profile, and some of their roadmaps point at each other. This chapter records, as of the pinned revisions, which connections exist in code and which are only ideas.
Connections that exist
| Connection | Kind | Evidence |
|---|---|---|
etf-research-agent derives from simple-agent-template | shared lineage: code copied and adapted, not a dependency | docs/UPSTREAM.md |
| Sophos, ETF Research and Arktos lessons link to template lessons | curriculum prerequisites | their learning paths; inside this book these links stay in the book |
| Tauros links to Arktos | documentation and roadmap only | Tauros ROADMAP Epic 9 |
No runtime integration exists between any two projects. No project calls another's API, shares a database or imports another's code as a library.
Connections that are designed or suggested, but not built
| Idea | Status | What blocks it today |
|---|---|---|
Tauros → Arktos payout adapter (Epic 9.1: an approved, idempotent PayoutInstruction submitted to Arktos through an adapter; Tauros holds no wallet or signing keys) | roadmap, not started | Arktos has no signing or broadcasting capability. Tauros has no payments epic implemented (Epic 6). |
| Settlement as observed events (Epic 9.2, Epic 6) | roadmap | no settlement, reconciliation or chain client in either project |
| Durable approval in a runtime like Sophos | a Sophos challenge | Sophos has no approval; its run status schema would need extending |
| Template-style signed approvals in Arktos | Arktos's first challenge (design safe transaction signing) | future design |
| A platform bringing agents and on-chain workflows together | an organisation-level research direction | not started |
Why the separation is deliberate
"Tauros knows financial intent. Arktos knows cryptographic authority." Keeping them apart means:
- the system that decides whether a payment should happen never holds the key that makes it happen;
- the system that holds keys never interprets business intent. It would receive an already-approved, exact instruction;
- each can be reasoned about, tested and audited alone.
An integration that preserved those properties would need, at least, an exact, content-addressed instruction approved in Tauros, an authenticated channel to the signer, a signer-side policy that verifies the instruction rather than trusting the caller, idempotent submission, and settlement treated as an observed outcome, not assumed at submission. That design is the exercise that closes this part.
How to read claims elsewhere
If a document, talk or summary says the CognoKratos projects "settle payments", "sign transactions" or "integrate Tauros and Arktos", check the date and the revision. At the revisions in this book, none of those is implemented.