Capabilities

Problem

Modern software delivery is buckling under the scale, complexity, and sprawl of the systems we’ve stitched together. We have more APIs, services, data pipelines, and integrations than ever before—but building and connecting systems feels harder, not easier. As organizations push to adopt AI, automate with agents, and leverage years of API investments, our traditional interface designs are hitting their limits. result is a growing sense of strain and fragmentation.

Solution

This is where capabilities enter the conversation. Capabilities are open-source, declarative, standards-based integrations aligned with business outcomes within specific domains. They provide the building blocks needed to deliver and automate integrations across countless internal, partner, and third-party systems. Capabilities help rebalance how we think about and execute integrations across the sprawling ecosystems we depend on.

Thinking

Capabilities start with a mindset shift. Capability thinking moves our focus from APIs, endpoints, and resources to the higher-level business functions that actually matter. Instead of designing around tables or CRUD operations, we design around outcomes. Capabilities become the primary building blocks of a platform—not low-level resources, but clear expressions of what the business can do.

A capability is both human-readable and machine-executable. It explains itself. It carries semantic meaning. It can be composed, automated, reused, governed, and observed. In a world of AI agents, event-driven systems, and interconnected ecosystems, capabilities become the logical unit of work and interaction.

Characteristics

A capability is not just a label. It is a strongly typed, governed, standardized set of artifacts. Mature capabilities have qualities that make them predictable, reusable, and understandable across teams, tools, and domains.

• Business-aligned, with intuitive metadata, clear boundaries, and domain language
• Human- and machine-readable, discoverable, and semantically meaningful
• Composable and reusable, interoperable with other capabilities
• Declarative, event-driven, automated, and predictable
• Governed, policy-driven, secure, role-aware, and monitored
• Executable, shareable, versioned, and lifecycle-aware
• Integrated across APIs, data connections, file systems, and protocols
• Collaborative, bringing product, engineering, and domain experts together
• Insightful, observable, and traceable everywhere they run

Properties

These are some of the properties currently being explored to help shape what a capability might be, exploring what is needed across conversations with different companies, as well as beginning to define what capabilities we will need to operate Naftiko. Taking a schema-first and declarative approach to shaping what we are capable of as we are developing the framework and engine to run them, and the fabric to bring it together.

• naftiko - A place to track administrative items required.
  • schema - A reference to the schema for a capability.
• info - A place to put all the metadata and info required.
  • name - A plain language name for a capability.
  • description - A paragraph description of what a capability does.
  • icon - A URL for an image to represent what a cpability does.
  • tags - Keywords and phrases that describe what a capability does.
  • jsonLd - A JSON-LD reference for capability semantics.
  • pinned - Determines whether a capability is pinned or not.
  • featured - Determines whether a capability is featured or not.
• useCase - A reference to a use case object for a capability.
• stakeholders - All of the people involved with a capability.
• capabilities - References to other child capabilities.
• events - References to CloudEvents objects for capability.
• change - The place where all changes are being logged.
  • state - Defining the state of a cpability.
  • schemaVersion - The version of the capability schema used.
  • capabilityVersion - The version of the capability itself.
  • updated - When the capability was last updated.
  • created - When the capability was created.
• source - Information about capability source control.
  • httpUrl - The HTTP url to the capability Git repository.
  • sshUrl - The SSH url to the capability Git repository.
  • dockertHub - The HTTP url to the capability Docker image.
• support - Any information regarding the support of a capability.
  • issues - A url to where issues can be found for capability.
  • discussions - A url to where discussions can be found for capability.
  • slack - A url to Slack account or thread for a capability.
• license - The licensing applied to a capability.
  • data - The license for the data.
  • code - The license for the code.
  • api - The license for the API.
• standards - References to any standards being used to support capability.
• services - Referneces to any services being used to support capability.
• observability - Any resources regarding the observability of a capability.
  • visibility - Whether a capability is public or private.

These are all just proposed properties for a capability based upon the handful of capabilities we have mocked up from the variety of conversations we are having with companies, and will continue to change and evolve based upon feedback and road map priorities.

Examples

These are some of the current capabilities being iterated upon which are being driven by conversations with different companies, and used to inform the schema and this documentation for what a capability is.

• API Reusability - Being capable of reusing APIs.
• Manage Events - Being capable of managing conference, meetings, and other events.

Links

Some other references regarding what a capability is and can be, based upon ecosystem conversations.

• Naftiko Discussions - A dedicated conversation on discussion forum about what a capability can be, engaging with the community.
• Capoability Schema - A current draft JSON Schema and examples to define what a capability can be in a governed way.
• What is an API Capability - This is a story in an ongoing series to drive a conversation about what a capability is.