Overview¶

The Naftiko Fleet rests on a small set of opinionated concepts. Understanding them once makes every component (Shipyard, Ikanos, Polychro, Crafter, Warden, Skipper) feel familiar — they all operate on the same artifacts.

Concept	One-line summary	Read more
Spec-Driven Integration (SDI)	The methodology — make the specification the single source of truth for any integration.	SDI
Capability	The artifact — a self-contained YAML document declaring what is consumed and what is exposed.	Capability schema
Capability-Driven AI Integration	The design pattern — start from the AI surface, then wire it to APIs (or mocks).	Capability-driven AI
Use Cases	The catalog — concrete scenarios that map directly to capability features.	Use Cases
Capability Engine	The runtime — Ikanos reads the spec at startup and serves it as MCP/REST/Skill.	Ikanos
Specification Linter	The safety net — deterministic, AI-embeddable validation of specs generated by agent loops.	Polychro
Ship and fleet	The deployment model — a ship hosts many capabilities; a fleet (lowercase) coordinates many ships.	Capability-driven AI

Fleet vs fleet

Capitalised Fleet = the Naftiko Fleet platform. Lowercase fleet = a runtime group of capabilities and ships. The two are related — Skipper orchestrates the latter on behalf of the former — but they're not the same thing.

The mental model in one diagram¶

┌─────────────────────────────────────────────────────────────┐
│                       Capability                            │
│                                                             │
│   ┌────────────┐    aggregates    ┌────────────────────┐    │
│   │  consumes  │ ←── reused by ── │     exposes        │    │
│   │            │                  │                    │    │
│   │  HTTP API  │                  │  MCP / REST /      │    │
│   │  (vendor)  │ ───────────────► │  Skill / Control   │    │
│   │            │   steps + maps   │  (your surface)    │    │
│   └────────────┘                  └────────────────────┘    │
│                                                             │
│                One YAML spec, many surfaces                 │
└─────────────────────────────────────────────────────────────┘

Every capability is built from four kinds of blocks:

consumes — what HTTP APIs the capability uses internally.
exposes — the protocol-specific surfaces the capability serves (REST, MCP, Skill, Control).
aggregates — reusable domain functions referenced from multiple exposes.
binds — external bindings for secrets and configuration.

Everything else (steps, mappings, semantics, hints) is wiring between those four pieces.