Trying to displace SAP CPI on its home turf is a losing game. So Naftiko isn’t going to. Naftiko’s job is to make the CPI investment those enterprises already made safely usable by copilots and agents — without rewriting a single iflow.

This post walks through what that actually looks like as a Naftiko capability, with three real examples.

The pattern

SAP CPI iflows already expose REST or SOAP endpoints. A Naftiko capability consumes those endpoints and exposes them as MCP tools, Agent Skills, or governed REST — while reshaping the upstream SAP payload so the agent never sees raw SAP complexity. Field names get cleaned up. Verbose $.d.results envelopes get unwrapped. Multiple iflows get composed into single agent-task-shaped tools.

The whole capability lives in a single YAML file in Git. The Naftiko Engine reads it at runtime as a Docker container. There is no codegen, no rebuild of CPI, no second iPaaS to maintain.

Example 1: Wrap a single CPI iflow as an MCP tool

Common iflow: “Get open sales orders for a customer.” Already deployed on the CPI tenant. We want a copilot to be able to call it.

naftiko: "1.0.0-alpha1"

capability:
  name: sales-orders
  description: "Read open sales orders from SAP via existing CPI iflow"

  consumes:
    - namespace: cpi
      type: http
      baseUri: "https://my-tenant.it-cpi020.cfapps.eu10-002.hana.ondemand.com/http"
      auth:
        type: oauth2-client-credentials
        tokenUrl: "https://my-tenant.authentication.eu10.hana.ondemand.com/oauth/token"
        clientId: "${CPI_CLIENT_ID}"
        clientSecret: "${CPI_CLIENT_SECRET}"
      resources:
        - name: orders
          path: "/SalesOrders/v1/open"
          operations:
            - name: list-open-orders
              method: GET
              queryParameters:
                - name: customerId
                  type: string
                  required: true

  exposes:
    - type: mcp
      port: 3001
      namespace: sap-sales
      description: "SAP sales order tools"
      tools:
        - name: list-open-sales-orders
          description: "List open sales orders for a given customer"
          call: cpi.list-open-orders
          inputParameters:
            - name: customerId
              type: string
              description: "SAP customer ID (KUNNR)"
              mapping: "queryParameters.customerId"
          outputParameters:
            - type: array
              mapping: "$.d.results"
              items:
                type: object
                properties:
                  - name: orderId
                    type: string
                    mapping: "$.SalesOrderId"
                  - name: customerName
                    type: string
                    mapping: "$.SoldToParty"
                  - name: amount
                    type: number
                    mapping: "$.NetAmount"
                  - name: currency
                    type: string
                    mapping: "$.CurrencyCode"
                  - name: status
                    type: string
                    mapping: "$.OverallStatus"

What this gives you that CPI alone does not:

• The whole integration lives in Git as one file
• It exposes an MCP tool that Claude, Copilot, or Cursor can call directly
• The verbose SAP envelope and field names are reshaped into clean agent-friendly outputs
• Auth, upstream contract, and exposed contract are all visible in one inspectable place
• Spectral can lint it (naming, identity propagation, required fields) before it ships

Example 2: Compose multiple CPI iflows into one capability

This is where Naftiko starts doing things CPI cannot easily do — composing across iflows into a single agent-task-shaped tool. An agent should not have to call three CPI endpoints to answer “what is the health of customer X?” It should call one tool. Three sources, one composed result.

naftiko: "1.0.0-alpha1"

capability:
  name: customer-360
  description: "Composed customer health view from SAP CPI"

  consumes:
    - namespace: cpi
      type: http
      baseUri: "https://my-tenant.it-cpi020.cfapps.eu10-002.hana.ondemand.com/http"
      auth:
        type: oauth2-client-credentials
        tokenUrl: "${CPI_TOKEN_URL}"
        clientId: "${CPI_CLIENT_ID}"
        clientSecret: "${CPI_CLIENT_SECRET}"
      resources:
        - name: customer
          path: "/Customers/v1/{customerId}"
          operations:
            - name: get-customer
              method: GET
        - name: orders
          path: "/SalesOrders/v1/open"
          operations:
            - name: list-open-orders
              method: GET
        - name: invoices
          path: "/Invoices/v1/overdue"
          operations:
            - name: list-overdue-invoices
              method: GET

  exposes:
    - type: mcp
      port: 3001
      namespace: sap-customer
      tools:
        - name: get-customer-health
          description: "Composed customer health summary including profile, open orders, and overdue invoices"
          inputParameters:
            - name: customerId
              type: string
              required: true
          steps:
            - call: cpi.get-customer
              with: { pathParameters.customerId: "${input.customerId}" }
              as: profile
            - call: cpi.list-open-orders
              with: { queryParameters.customerId: "${input.customerId}" }
              as: openOrders
            - call: cpi.list-overdue-invoices
              with: { queryParameters.customerId: "${input.customerId}" }
              as: overdueInvoices
          outputParameters:
            - type: object
              properties:
                - name: customerName
                  type: string
                  mapping: "${profile.d.SoldToParty}"
                - name: openOrderCount
                  type: integer
                  mapping: "${openOrders.d.results | length}"
                - name: openOrderValue
                  type: number
                  mapping: "${openOrders.d.results | sum(NetAmount)}"
                - name: overdueInvoiceCount
                  type: integer
                  mapping: "${overdueInvoices.d.results | length}"
                - name: overdueInvoiceValue
                  type: number
                  mapping: "${overdueInvoices.d.results | sum(Amount)}"
                - name: riskFlag
                  type: string
                  mapping: "${overdueInvoices.d.results | length > 0 ? 'at-risk' : 'healthy'}"

The agent calls one tool. Underneath, Naftiko orchestrates three CPI calls and composes them into a single small typed object. The model never sees three SAP envelopes. Token cost drops, accuracy goes up, and a security reviewer audits one capability instead of three loose tool wirings.

Example 3: Expose the same capability as MCP, Skill, and REST

Same underlying CPI integration, three surfaces, one declaration. CPI cannot do this without three separate iflows.

naftiko: "1.0.0-alpha1"

capability:
  name: invoice-lookup
  description: "Look up SAP invoices via CPI — exposed as MCP, Skill, and REST"

  consumes:
    - namespace: cpi
      type: http
      baseUri: "https://my-tenant.it-cpi020.cfapps.eu10-002.hana.ondemand.com/http"
      auth:
        type: oauth2-client-credentials
        tokenUrl: "${CPI_TOKEN_URL}"
        clientId: "${CPI_CLIENT_ID}"
        clientSecret: "${CPI_CLIENT_SECRET}"
      resources:
        - name: invoices
          path: "/Invoices/v1/{invoiceId}"
          operations:
            - name: get-invoice
              method: GET

  exposes:
    - type: mcp
      port: 3001
      namespace: sap-finance
      tools:
        - name: get-invoice
          call: cpi.get-invoice

    - type: skill
      port: 3002
      namespace: sap-finance-skill
      skills:
        - name: lookup-invoice
          call: cpi.get-invoice

    - type: rest
      port: 8080
      basePath: "/api/finance"
      endpoints:
        - method: GET
          path: "/invoices/{invoiceId}"
          call: cpi.get-invoice

One spec, one CPI upstream, three exposed surfaces — MCP for Claude and Copilot, Agent Skill for agent runtimes, REST for traditional callers. Same governed contract, same lint rules, same audit trail.

What this looks like in practice

The Naftiko Engine runs as a Docker container that reads these YAML files at startup. Drop them in a directory, run docker run, and you have:

• An MCP server on :3001 that any MCP client can connect to
• Optionally a Skill server on :3002
• Optionally a REST server on :8080
• All of them backed by your existing SAP CPI iflows
• All of them governed by Spectral rules in CI and the VS Code extension
• All of them inspectable in Git

Why this is the right wedge

The temptation, when you build an AI-native integration framework, is to position it against incumbent iPaaS platforms as a replacement. That is the wrong move with SAP CPI specifically. SAP customers have years of accumulated iflow investment, certified connectors, support contracts, and operational muscle memory. They are not going to throw it out because somebody wrote a blog post about MCP.

But they also know — every CTO and platform leader I talk to inside an SAP shop knows — that CPI was not designed for the agent era. There is no first-class concept of MCP servers, Agent Skills, or right-sized context outputs. There is no way to declaratively reshape a payload for a context window. There is no spec you can git diff, no Spectral lint, no IDE-level governance.

Naftiko fills exactly that gap, and it does so without asking the SAP customer to give anything up. You keep your iflows. You keep your CPI runtime. You keep your support contract. You drop a Naftiko capability YAML in front of the iflows you want agents to use, and you ship an MCP server your copilot can call this afternoon.

That is the positioning sentence:

Naftiko is not an iPaaS replacement for SAP Cloud Integration. It is the open, spec-driven, AI-native capability layer that makes your existing SAP integrations safely consumable by copilots and agents — without rebuilding what you already have.

What ships with this approach

Everything you need to do this is in the Naftiko Framework Alpha 1 (Apache 2.0), shipping now:

• Declarative capability spec with consumes and exposes blocks
• HTTP source adapter with OAuth2, basic, and bearer auth
• MCP, Skill, and REST exposure types from a single capability
• outputParameters for reshaping upstream payloads into clean typed outputs
• Spectral ruleset for design-time governance
• VS Code extension for live linting
• Docker container for the engine — docker run and you are running

Try it

If you run SAP CPI and you are trying to figure out how to safely give your copilots and agents access to the integrations you already built, this is the ten-minute version of the answer. Pull the Docker image, point a Naftiko capability at one of your CPI endpoints, and ship an MCP server today.

• GitHub: github.com/naftiko/framework
• Wiki: github.com/naftiko/framework/wiki
• Fleet Community Edition: github.com/naftiko/fleet

Wrap, don’t replace.

We started with 15 companies and doubled the count until reaching 250 companies, which has grown to roughly 292. We began doing this to understand what potential customers were investing in, but quickly realized that the data combined with the Naftiko perspective could translate signals into compelling industry and enterprise insights. Gathered each quarter, these signals help keep us grounded in the realities on the ground within mainstream enterprises, while also opening doors to new potential design partners.

Browsing the Data

The data available on the Naftiko Signals website is available to browse, offering a high-level view of what we are seeing across 49 industries and 292 companies. The analysis should grab the attention of API, platform, integration, and engineering leadership within enterprises, but also executive leadership. When we started this work, we intended to keep our findings behind a lead generation wall, but decided to showcase the top industries and companies publicly to provide a taste of the insights available at each level of the Naftiko sales funnel – working to get people interested in becoming design partners.

Professional Services: The Top-Scoring Industry

When it came to the scoring we used to evaluate enterprise investments, the professional services industry rated the highest in investment across the areas that matter when it comes to successfully integrating artificial intelligence into the enterprise.

It wasn’t what we expected when we began sifting through all of the noise associated with artificial intelligence at the beginning of Q1 2026, but we learned a lot evaluating how professional services companies were hiring, and the stories they were telling about why artificial intelligence matters to their operations and their customers.

EY: The Top-Scoring Company

The top-scoring company across all 292 companies we looked at was EY. They have all of the complexity we look for as part of the Naftiko ideal customer profile, but they are also clearly making the investments in data pipelines, cloud, APIs, and other areas that have the greatest impact on the business outcomes that matter to EY and their customers.

Looking through the areas, services, tools, and standards employed across EY job postings, you can learn a lot about what EY has been investing in for some time, but also specifically how they are responding to this particular AI moment – which is different than what you hear in the mainstream buzz.

Accenture: Validating the Pattern

We won’t showcase all of the professional services companies profiled as part of Signals, but it is worth highlighting the runner-up for the top performer – Accenture. EY is definitely more complex, but Accenture validates a lot of what we believe goes into successful AI integrations, echoing EY on what matters when it comes to AI.

It was really interesting to look through the capabilities we were able to derive from the signals gathered across Accenture and EY, and the other professional services companies. This helped us move past just the services and tools, and understand more about how they are being applied in service of business outcomes.

Q1 2026: Wrapped

We have finalized our data for Signals Q1 2026. There are always more ways we can polish the data and refine the insights gathered. But the best way to do this is through validating directly with the companies who are being showcased as part of this work, and through expanding the work across additional companies. We are satisfied with the Q1 results, have learned a lot along the way, and look forward to sharing and talking with companies we have included in this work.

Design Partners

We aren’t shy about the reasons we are investing in Naftiko Signals. We need design partners to help us improve the data and insights, but we also need you to help define how the Naftiko Framework and Naftiko Fleet can be applied to strengthen the investments we have identified across the companies and industries showcased as part of Naftiko Signals.

Naftiko Signals is at the center of our go-to-market function, and we are actively sharing industry and company links to impact reports, radar, navigation, and capabilities that we hope will entice companies to join us in developing the Naftiko Framework to meet their needs when it comes to defining their integrations at scale, and the Naftiko Fleet to help them move in the direction they desire.

What’s Next

We are looking for feedback on Naftiko Signals – at the highest levels, as well as at the industry and company levels. What is missing? What is incorrect? What would make it more applicable in your day? It is a lot of data. We get it. We have been working hard to make it more actionable and usable, but we need your help to understand what would be most helpful for you on the ground within your enterprise.

Now that we have Q1 wrapped up, we have begun pulling data for Q2, but we are also looking to see how we can refine the radar, navigation, and capabilities by role within specific industries and enterprises. We want to find out how we can produce exactly the capabilities you need in your work, and make it so that you can easily fire up the Naftiko Framework using the capabilities that matter to you the most. We encourage you to share what the Naftiko Fleet will need when it comes to helping you define and equip your enterprise fleet with what it will need to succeed in 2026 and beyond.

So we went and looked at what enterprises are actually spending money on. Not what their CMOs are saying. What their engineering orgs are hiring for, contributing to, and buying. The answer is more interesting than the hype cycle gives it credit for.

How we measured

Naftiko Signals profiles 253 enterprise companies by reading the engineering signals that cost real money: job postings, open source contributions, SaaS portfolios, standards participation, and tooling choices. Marketing is cheap. Headcount is not. A company that has been hiring for a capability for eighteen months is telling you something a press release cannot.

We bucket those signals into 44 areas of technology spanning the full stack — AI, cloud, data, APIs, integrations, security, governance, observability, platform engineering, and the rest. Then we count: out of 253 enterprises, how many show meaningful investment in each area?

The top of the list

Read that list again. AI is tied for first — with Active Directory. And one rank below both of them, holding 86% of the enterprise market, is EDI. The protocol your grandfather used to send purchase orders.

This is the story the hype cycle refuses to tell.

What it actually means

1. AI is real, but it is not alone at the top. Yes, 86% of enterprises are investing in AI, ML, and Deep Learning. That part of the narrative is true. What is missing from the narrative is that the same enterprises are investing — at the exact same intensity — in identity infrastructure, B2B document exchange, and operational tooling. The boring stuff did not go away. It got more important, because every AI initiative eventually has to authenticate against Active Directory and exchange data with a partner over EDI.

2. The unglamorous layers are load-bearing. Active Directory at #2 and EDI at #3 are not legacy footnotes. They are the substrate every shiny initiative runs on top of. When 86% of large enterprises are still actively investing in EDI in 2026, that is not technical debt — it is the operating reality of how business actually moves between organizations. Anyone selling an “agent-to-agent commerce” vision that does not have an EDI story is selling a slide deck.

3. “Data” is the silent winner. “Data” as a category sits at 86%, alongside Deep Learning and Machine Learning. Enterprises figured out a long time ago that AI without data infrastructure is a demo, not a system. The investment in pipelines, governance, and storage matches the investment in models — because it has to.

What the hype cycle gets wrong

The dominant story of 2026 is that AI is reshaping everything and the rest of the stack is along for the ride. The signals say something more honest: AI is being layered on top of a stack that enterprises are still actively maintaining and growing. The directory service is not going away. The EDI gateway is not going away. The operational tooling is not going away. They are getting more investment, not less, because the AI layer increases the demands on all of them.

If you are building for enterprises, this matters. A product that assumes the legacy substrate is dissolving will lose to a product that assumes it is thickening. Because the data says it is thickening.

Why this is visible at all

The reason any of this is visible is that we stopped relying on what enterprises say and started reading what they do. Job postings are a leading indicator of investment. OSS contributions are a leading indicator of internal capability. SaaS portfolios are a leading indicator of architectural strategy. Standards participation is a leading indicator of interoperability commitment. None of these are secret. They are just unaggregated.

Signals aggregates them. Every company we profile is an open YAML file in a Git repository. Every signal definition is open. Every ranking is reproducible. If you disagree with how we classified a company, you can submit a PR.

What to do with this

If you are an operator inside an enterprise: use this list as a reality check on your own roadmap. If your AI strategy assumes EDI and AD are someone else’s problem, the other 86% of enterprises disagree with you.

If you are building software for enterprises: the boring categories at the top of this list are where the buyers are. The fastest path to relevance is connecting the new layer (AI, agents, MCP) to the substrate (identity, EDI, data, ops) — not pretending the substrate is gone.

If you are trying to make sense of the market: stop reading press releases. Read the signals. They are open.

The hype cycle tells you what enterprises want you to think they are doing. The signals tell you what they are actually paying people to build. Those are not the same list — and the gap between them is where the real opportunities live.

Today we are launching the alpha of Naftiko Framework and Naftiko Fleet. This is one of four posts going up to set the table for what that actually means and how to put Naftiko to work. This one is about Fleet — the layer that takes one running framework instance and turns it into a governed, discoverable, scaffolded inventory of capabilities. The other three cover the underlying capability specification, the framework engine and CLI that runs it, and a Hello World you can stand up in under a minute.

A framework gives you the ability to build one capability. A fleet gives you the ability to govern hundreds. That’s the gap Naftiko Fleet is designed to close.

The Naftiko Framework is an open-source engine that turns a YAML specification into a running integration. It’s powerful on its own. But the moment you have more than a handful of capabilities — and in any enterprise that moment comes fast — you need tooling around the framework. You need validation in your editor. You need scaffolding so teams start from a consistent baseline. You need a catalog so people can find what already exists before they build something new. You need governance that works at the fleet level, not just the file level.

That’s what Naftiko Fleet delivers. It launches alongside the framework’s v1.0 Alpha 1 release as a free Community Edition with two integrations already shipping and a roadmap that extends into Kubernetes-native operations, Backstage cataloging, and Docker Desktop tooling.

What Ships in the Community Edition

The Community Edition bundles the open-source Naftiko Framework with two free fleet-level tools: a VS Code extension and Backstage templates. Together, they cover the two most immediate needs when you start building capabilities at scale — editing them correctly and creating them consistently.

VS Code Extension: Validation Where You Write

The Naftiko extension for VS Code does two things, and it does them well. It validates the structure of your capability YAML files against the Naftiko JSON Schema, and it validates the rules against the Naftiko Spectral ruleset. Both run inline in the editor with diagnostics displayed in the Problems panel, giving you immediate feedback as you write.

This matters more than it might sound. A capability file is a declarative specification — every field, every namespace, every operation has to conform to the schema or the engine won’t interpret it correctly. Getting that feedback at edit time rather than at runtime eliminates an entire class of errors before they ever reach a Docker container.

The extension works with any file named .naftiko.yaml or .naftiko.yml. There’s a three-second delay on validation to keep things responsive, and you can force validation manually through a palette command. It’s also compatible with Cursor, Windsurf, and Kiro — so it meets teams where they already work.

The extension isn’t in the VS Code Marketplace yet. You install it manually by downloading the VSIX file from the Fleet GitHub releases and loading it through the Extensions panel. It’s a temporary friction that will disappear as the project matures, but the tooling itself is already production-quality for editing and linting.

Backstage Templates: Scaffolding With Git Bootstrapping

The second piece of the Community Edition is a set of Naftiko templates for Backstage, the CNCF’s developer portal. These templates let you scaffold a new capability through Backstage’s familiar create flow — name the capability, choose which adapter types to expose, point it at a GitHub repository, and Backstage handles the rest. It creates the repo, populates it with the capability skeleton, and registers the new service component in the Backstage catalog.

This is how you get consistency across a team of ten or a hundred developers building capabilities. Everyone starts from the same validated template. Every capability gets a Git repo, a catalog entry, and the right file structure from day one. No copy-paste from a wiki. No “I’ll set up the repo later.” The scaffolding is the workflow.

The Backstage integration runs locally via Docker Compose with a pre-configured image that includes PostgreSQL and the Naftiko templates out of the box. You need a GitHub token with repo permissions, and you’re running in minutes. It’s designed to be the starting point — something you can evaluate locally before integrating into your organization’s existing Backstage instance.

Why Fleet, Not Just Framework

The distinction between framework and fleet is architectural, not just branding. The framework is the engine — it interprets a capability spec and runs it. Fleet is the governed layer that sits above the engine and addresses what happens when you have many capabilities to manage.

Think of it this way: the framework solves the problem of “how do I turn this API into a capability.” Fleet solves the problem of “how do I manage all our capabilities as a coherent inventory.” Those are fundamentally different challenges, and they require different tooling.

The framework is open source under Apache 2.0 and always will be. Fleet is the product built on top of it, starting with a free Community Edition and expanding to Standard and Enterprise editions that add premium features for larger organizations. The framework gives you the engine; Fleet gives you the fleet management.

What’s Coming in Q2

The Alpha 1 release delivers the foundation — editing and scaffolding. The second alpha, targeted for May 11th, extends Fleet across all three integration points and adds a fourth.

VS Code gains the ability to set the Capability JSON Schema in the header of capability YAML files, an Agent Plugin that installs alongside the extension with the Naftiko Skills preset, and verified compatibility with Cursor, Windsurf, and Kiro.

Backstage gets an upgrade to Backstage 1.49.0 and BUI, the ability to scaffold capabilities from existing APIs with proper lineage, registration of exposed REST, MCP, and SKILL endpoints into the catalog with lineage tracking, and documentation for customizing an existing Backstage instance to add Naftiko support.

Kubernetes enters the picture with a Naftiko Operator and Capability CRD built with Kustomize, and Argo CD integration for continuous deployment. This is the piece that turns Fleet from a developer tool into an operational platform — capabilities managed as Kubernetes-native resources with declarative lifecycle management.

Core developer experience expands with CNOE for IDP building and enterprise-grade CNCF stacks, plus an MVP of Naftiko Shipyard to help developers and agents learn and create capabilities.

The Bigger Picture

Fleet is positioned at the intersection of two trends that are reshaping enterprise software: the explosion of API integrations driven by SaaS and microservices growth, and the emergence of AI agents that need governed, discoverable capabilities to be effective.

The VS Code extension ensures that every capability file is valid before it runs. The Backstage templates ensure that every capability starts from a governed baseline. The upcoming Kubernetes operator ensures that capabilities run as first-class workloads with proper lifecycle management. Each layer adds governance without adding friction.

For enterprise teams managing hundreds of API integrations, Fleet offers a path from unmanaged sprawl to a governed capability inventory — without requiring a wholesale platform migration. You start with the VS Code extension to validate the capabilities you’re already building. You add Backstage templates when you want consistency across teams. You deploy the Kubernetes operator when you’re ready for production-grade operations.

That incremental adoption model is what makes Fleet practical. You don’t have to buy in all at once. You start where you are, and the fleet grows with you.

Fleet Community Edition is available now at github.com/naftiko/fleet.

Today we are launching the alpha of Naftiko Framework and Naftiko Fleet. This is one of four posts going up to set the table for what that actually means and how to put Naftiko to work. This one is the fastest way in — a Hello World capability you can run in under a minute. The other three cover the underlying capability specification, the framework engine and CLI that runs it, and the Fleet tooling that turns one capability into a governed inventory.

The fastest way to understand any framework is to run it. Not read about it. Not browse the specification. Not watch a demo. Run it yourself and see what happens. The Naftiko Framework Hello World capability is the smallest possible proof that Spec-Driven Integration works — and it takes under a minute from a cold start.

One YAML file. One Docker command. A running API endpoint.

What You Need

Docker. That’s it. If you have Docker Desktop running on your machine, you have everything you need. No Java installation. No build tools. No package managers. No language runtimes to configure. The Naftiko engine ships as a container image on Docker Hub, and it’s public — no authentication required to pull it.

docker pull naftiko/framework:1.0.0-alpha1

That gives you the v1.0 Alpha 1 engine. It’s a JVM-based runtime that reads a capability YAML file and starts serving immediately. The image is small, the startup time is measured in milliseconds, and the resource footprint is minimal.

The Capability File

Here’s the entire Hello World capability:

naftiko: "1.0.0-alpha1"
capability:
  exposes:
    - type: "rest"
      port: 8081
      namespace: "tutorial"
      resources:
        - path: "/hello"
          name: "hello"
          label: "My first resource"
          description: "A simple Hello, World! API endpoint"
          operations:
            - method: "GET"
              outputParameters:
                - type: "string"
                  const: "Hello, World!"

Fifteen lines. No imports, no dependencies, no boilerplate. The file declares exactly one thing: expose a REST endpoint at /hello that responds to GET requests with a constant string. The naftiko: "1.0.0-alpha1" header tells the engine which schema version to use. The exposes block defines what the capability makes available to the outside world. The resources block defines the endpoint. The operations block defines the HTTP method and what it returns.

That’s the entire integration. The specification is the implementation.

Running It

Save that YAML file and mount it into the Docker container:

docker run -p 8081:8081 \
  -v /path/to/hello-world.capability.yaml:/app/hello-world.capability.yaml \
  naftiko/framework:1.0.0-alpha1 /app/hello-world.capability.yaml

The engine reads the file, spins up a Jetty HTTP server on port 8081, and starts serving. You’ll see the startup log confirm it:

Reading configuration from: /app/hello-world.capability.yaml
Starting the Jetty [HTTP/1.1] server on port 8081
Capability started successfully.

Now hit the endpoint:

curl http://localhost:8081/hello

{
  "value": "Hello, World!"
}

That’s it. You have a running capability.

What Just Happened

Something important happened in those fifteen lines and one Docker command, and it’s easy to miss because it looks simple.

You didn’t write any application code. You didn’t configure a web server. You didn’t set up routing, request handling, response serialization, or any of the infrastructure that normally sits between your intent and a working endpoint. You declared what you wanted — a REST endpoint that returns a string — and the engine handled everything else.

This is what Spec-Driven Integration means in practice. The specification isn’t documentation that describes code you still need to write. The specification is the executable artifact. The Naftiko engine interprets it directly at runtime. There’s no code generation step, no compilation, no build pipeline. What you declare is what you get.

The Hello World capability only uses the exposes side of the framework. It’s a capability that produces but doesn’t consume. In a real integration, you’d also have a consumes block that declares the external APIs you’re calling — think of it as the difference between a ship loading containers at dock versus one that’s also receiving cargo from incoming vessels. The consume side brings data in from external APIs; the expose side serves it out through your capability’s interface. The engine sits in the middle, handling the orchestration.

Where to Go From Here

The Hello World is Step 1 in the Naftiko tutorial. Each subsequent step adds a layer of capability:

Step 2 — Forwarding. Add a consumes block that points to an external API like Notion, and forward requests through your capability. Your capability becomes a proxy with a clean namespace.

Step 3 — Encapsulating Headers. Move authentication tokens and version headers into the consumes configuration so consumers of your capability don’t need to manage them. Pass secrets as environment variables to the Docker container.

Step 4 — Filtering Responses. Use outputParameters with JSONPath mappings to return only the fields you need. Shape the response for your specific use case instead of passing through everything the upstream API returns.

Step 5 — Multi-Step Orchestration. Chain API calls using steps, where the output of one call feeds the input of the next. A single capability endpoint can orchestrate multiple upstream operations and return a composed result.

Step 6 — MCP Exposure. Switch the expose type from rest to mcp and your capability becomes an MCP tool that AI agents can discover and invoke. Same consume logic, different exposure protocol.

Each step builds on the same foundation: a YAML file interpreted by the engine. No new languages to learn. No framework APIs to memorize. Just more fields in the specification.

Why Hello World Matters

Every framework has a Hello World. Most of them are trivial by design — they exist to verify your toolchain works. The Naftiko Hello World is different because the gap between it and a production capability is not a gap in language or architecture. It’s a gap in YAML fields.

Going from Hello World to a real integration that consumes the GitHub API, filters the response, and exposes it as an MCP tool doesn’t require learning a programming language, adopting a framework’s opinion about project structure, or setting up a build system. It requires adding a consumes block and some outputParameters. The same engine. The same Docker command. The same deployment model.

That’s the point of running Hello World first. Not to prove that the framework can return a string. But to prove that the distance between a toy example and a real integration is measured in specification lines, not in architectural complexity.

Pull the image. Write the YAML. Run the container. Your first capability is live.

Today we are launching the alpha of Naftiko Framework and Naftiko Fleet. This is one of four posts going up to set the table for what that actually means and how to put Naftiko to work. This one is about the foundation everything else rests on — the capability specification itself. The other three cover the framework that runs it, the smallest possible Hello World you can stand up in under a minute, and the Fleet tooling that turns one capability into a governed inventory.

If you’ve spent any time in the API space, you know that the hardest part of integration isn’t the API itself. It’s everything around it. The authentication wiring. The data transformation. The mapping between what an upstream API gives you and what your downstream consumer actually needs. The documentation that gets written once and never updated. The glue code that three people understand and nobody wants to touch.

That’s the problem the Naftiko Capability Specification is designed to solve.

What Is a Capability?

At its core, a capability is a modular, composable integration unit. It declares two things: what it consumes and what it exposes. On the consume side, you’re connecting to existing HTTP APIs — your upstream services, your SaaS providers, your internal microservices. On the expose side, you’re presenting a clean interface that other systems can use — whether that’s a REST API, an MCP server for AI agents, or a skill server for structured discovery.

The specification captures the integration intent, not the implementation details. You write a YAML file that says: here’s what I need from these APIs, here’s how I want to shape and combine that data, and here’s how I want to present it. The Naftiko engine reads that file and handles everything else.

No custom code. No build pipeline. No language runtime. Just a specification and an engine.

The Consume/Expose Duality

This is the architectural idea that makes the whole thing work. Every capability has a consume side and an expose side, and the specification makes the relationship between them explicit and inspectable.

On the consume side, you declare your upstream APIs with their base URIs, authentication, namespaces, resources, and operations. Each consumed source gets a unique namespace, which becomes the routing key that connects it to the expose layer. You’re not just documenting these APIs — you’re declaring a contract with them that the engine can execute.

On the expose side, you choose how to present the capability. A REST expose gives you traditional HTTP endpoints. An MCP expose turns your capability into a set of tools, resources, and prompt templates that AI agents can discover and invoke. A skill expose groups tools into named skills for structured agent discovery. You can expose the same capability multiple ways simultaneously — REST for your existing consumers, MCP for your AI agents, all from the same YAML file.

The bridge between consume and expose is where the real work happens. Each exposed operation references consumed operations through a call field using the format namespace.operationId. You can inject parameters, map outputs with JSONPath expressions, and shape the response to exactly what your consumer needs. For more complex scenarios, you can orchestrate multiple consumed operations into ordered steps, passing data between them, and return a single composed result.

Why YAML and Not Code?

I’ve spent fifteen years watching the API industry cycle through frameworks, SDKs, and integration platforms. The pattern is always the same: you start with a clean abstraction, then the edge cases pile up, and before long you’re writing as much integration code as application code. The abstraction becomes another dependency to manage rather than a simplification.

The Naftiko approach is different because the specification is the integration. There’s no code generation step that introduces drift. There’s no SDK that locks you into a language. The YAML file is a complete, self-contained description of what the integration does, and the engine interprets it directly at runtime.

This matters for governance. When your integration is a YAML file, you can lint it, validate it against a schema, diff it in a pull request, and review it without understanding any particular programming language. You can see exactly what data is being consumed, how it’s being transformed, and what’s being exposed. The specification becomes an inspectable artifact that everyone — developers, architects, security teams, and yes, AI agents — can reason about.

The AI Native Angle

Here’s where things get particularly interesting. The specification was designed from the ground up with AI integration in mind. When you expose a capability as an MCP server, you’re not bolting AI support onto an existing integration framework. You’re declaring tools with names, descriptions, and typed input parameters that become the tool’s JSON Schema. You’re writing descriptions that help agents discover and understand what the capability does. You’re shaping output parameters so agents get exactly the context they need — no more, no less.

The specification supports MCP resources for data that agents can read, and MCP prompt templates for reusable, parameterized message templates. It supports both Streamable HTTP transport for remote MCP clients and stdio transport for local IDE and agent integration. All of this is declared in the same YAML file alongside the consume and REST expose configuration.

This is what context engineering looks like when it’s done at the specification level. You’re not writing custom code to filter and reshape API responses for each AI consumer. You’re declaring the right-sized context once, and the engine handles the rest.

Standing on the Shoulders of Specifications

One thing I appreciate about the Naftiko Specification is that it doesn’t pretend the last decade of API specification work didn’t happen. It explicitly acknowledges its debt to OpenAPI, Arazzo, and OpenCollections, and it positions itself in relation to them clearly.

OpenAPI tells you the shape of an API. Arazzo describes the sequence of API calls in a workflow. OpenCollections gives you runnable, shareable collections. Naftiko combines elements of all three into a single specification focused on integration intent — what goes in, what comes out, and how it all connects. The analogy the team uses is that OpenAPI is the parts list, Arazzo is the assembly sequence, OpenCollections is the step-by-step guide you can run, and Naftiko is the product blueprint.

That’s not a replacement story. It’s a composition story. And it’s the right framing for where the industry is headed.

Spec-Driven Integration

The specification is the centerpiece of what Naftiko calls Spec-Driven Integration — the idea that the specification should be the primary integration artifact, not a byproduct. You author the spec, validate it for completeness and consistency, execute it directly against the engine, and refine it based on production feedback. The spec is always the source of truth.

This resonates with everything I’ve been saying about API governance for years. The organizations that treat their API contracts as living, inspectable artifacts are the ones that scale without drowning in technical debt. The ones that treat integration as a code problem end up with sprawl, duplication, and drift. Naftiko is making a bet that the specification approach can work for integration the same way OpenAPI made it work for API documentation and tooling.

What This Means for Enterprise Teams

If you’re running a large enterprise with dozens or hundreds of API integrations, the capability specification gives you a path to consolidation that doesn’t require rewriting everything. You can wrap existing APIs as capabilities, expose them through consistent interfaces, and gradually build a governed layer of composable integration units. Each capability is self-contained, versioned, and deployable as a Docker container.

For teams building AI-powered applications, the MCP and skill expose types mean you can make your enterprise APIs available to AI agents without building custom integration code for each one. You declare what the agent should be able to do, connect it to the APIs it needs, and the engine handles the protocol translation and data shaping.

The Naftiko Capability Specification reached v1.0 Alpha 1 on April 1st, 2026, and it’s moving fast. But the core architectural idea — declare your integration intent in a single, inspectable specification and let the engine handle the rest — feels like the right direction for where API integration needs to go. I’ll be watching this closely and writing more as the ecosystem develops.

Today we are launching the alpha of Naftiko Framework and Naftiko Fleet. This is one of four posts going up to set the table for what that actually means and how to put Naftiko to work. This one is about the framework — the engine, the CLI, and the Docker-native runtime that takes a capability spec from YAML to a live integration. The other three cover the underlying capability specification itself, a Hello World you can run in under a minute, and the Fleet tooling that turns a single framework instance into a governed fleet.

Naftiko Capability Specification is a declarative YAML format that captures integration intent. But a specification without tooling is just a document. And what brings the specification to life is the Naftiko Framework: an open-source runtime engine, a CLI, and a Docker-native deployment model that turns a capability file into a running integration. No code generation. No build pipeline. No language runtime to manage. Just a YAML file and a Docker container.

That’s not an incremental improvement on how we do integration. That’s a fundamentally different operating model.

The Engine: Your Specification Is Your Integration

The core of the Naftiko Framework is the engine — a Java-based runtime that reads your capability YAML file at startup and immediately begins serving. You declare what APIs you consume, how you want to transform and compose the data, and what interfaces you want to expose. The engine handles the HTTP consumption, data format conversion, authentication, orchestration, and protocol serving.

This is the key architectural decision that separates Naftiko from code generation approaches. Code generators take a specification and produce source code that you then have to build, test, deploy, and maintain. Every time the spec changes, you regenerate, which introduces drift between what the specification says and what the code actually does. The Naftiko engine eliminates that gap entirely. The specification is interpreted directly at runtime. What you declare is what you get.

The engine supports consuming any HTTP-based API with built-in authentication — bearer tokens, API keys, basic auth, digest auth. It converts between data formats including JSON, XML, YAML, CSV, Avro, and Protobuf. It orchestrates multi-step operations where the output of one API call feeds the input of the next. And it exposes the result through REST endpoints, MCP servers for AI agents, or skill servers for structured agent discovery.

All of that from a YAML file.

Docker Native from Day One

The framework ships as a ready-to-run Docker container. This is a deliberate design choice, not a deployment convenience. When your integration is a YAML file interpreted by a containerized engine, deployment becomes trivial. You mount your capability file into the container, map the ports, pass your secrets as environment variables, and you’re running.

docker run -p 8081:8081 \
  -v /path/to/capability.yaml:/app/capability.yaml \
  -e GITHUB_TOKEN=ghp_xxx \
  naftiko/framework:1.0.0-alpha1 /app/capability.yaml

That’s it. No Maven builds. No Gradle configurations. No dependency hell. No CI pipeline that takes twenty minutes to produce an artifact. Your capability file is the artifact.

For production, you deploy to Kubernetes with multiple replicas behind a load balancer. The engine’s overhead is minimal — your performance is bounded by the upstream APIs you’re consuming, not by the integration layer. Scale horizontally by adding instances. The engine is stateless; the specification is the only configuration.

The CLI: Create, Validate, Ship

Alongside the engine, the framework provides a CLI tool that handles the developer experience around capability files. Two commands cover most of what you need day to day.

naftiko create capability walks you through creating a valid capability file interactively. It asks questions, generates the YAML, and drops it in your current directory. You’re starting from a valid file rather than staring at a blank editor trying to remember the schema.

naftiko validate checks your capability file against the Naftiko schema and tells you exactly what’s wrong. This is the kind of fast feedback loop that makes spec-driven development practical. You edit the YAML, validate it, fix the errors, and validate again. The iteration cycle is measured in seconds, not minutes.

The CLI currently runs on macOS (Apple Silicon), Linux, and Windows. It’s early — the team has plans for a control port, a web app, and a Docker Desktop extension — but the foundation is solid and the validate command alone saves significant time.

What You Can Build Today

I’ve been tracking the use cases that the framework supports, and the range is broader than you might expect from a first alpha release.

AI Integration. Declare your upstream APIs in the consume layer, expose them as MCP tools in the expose layer, and AI agents can discover and invoke your capabilities without custom glue code. The framework supports both Streamable HTTP transport for remote MCP clients and stdio transport for local IDE integration. You can expose MCP resources for data that agents can read and prompt templates for reusable message patterns.

Context Engineering. Shape your API responses to deliver exactly the context an AI task needs. Use typed output parameters and JSONPath mapping to filter out irrelevant fields, normalize data structures, and return task-ready payloads. This is what right-sizing AI context looks like when it’s done declaratively.

API Composition. Register multiple consumed APIs with unique namespaces, orchestrate cross-source calls using ordered steps, and return a single composed result. A capability can call the Notion API and the GitHub API in sequence, pass data between them, and expose a unified response that neither API provides on its own.

Microservices Rationalization. If you’re drowning in microservice endpoints, create a simpler capability layer on top. Aggregate multiple services under one exposed namespace, standardize authentication and parameter handling at the capability level, and give your consumers consistent contracts instead of fragmented service interfaces.

API Elevation. Wrap a legacy or poorly designed API as a capability to make it easier to discover, reuse, and consume. Remap HTTP methods to expose proper semantics — turn read-only POST queries into cacheable GETs. Convert XML or CSV payloads to JSON. Add meaningful descriptions for agent discovery. The underlying API doesn’t change; the capability provides a better interface on top.

The Spec-Driven Integration Methodology

The framework implements what Naftiko calls Spec-Driven Integration — a methodology where the specification is the primary integration artifact, not a byproduct. This isn’t just a technical preference. It’s a governance model.

When the specification is the source of truth, you can lint it with tools like Spectral, validate it against a JSON Schema, review it in pull requests without understanding Java or any other language, and track changes through version control. Your integration is inspectable, diffable, and auditable. Try doing that with a thousand lines of custom integration code spread across multiple services.

The workflow is straightforward: specify the integration in YAML, validate it with the CLI, execute it with the engine, and refine based on production feedback. The specification remains the living artifact throughout. There’s no translation layer where intent gets lost.

Where the Framework Is Headed

The roadmap tells an interesting story about where this is going. The first alpha landed on April 1st, 2026, with MCP resources and prompts, skill exposure, lookup steps, consumer authentication, and reusable source capabilities — alongside the free Fleet Community Edition with a VS Code extension and Backstage templates. The second alpha in May adds A2A server adapters for agent-to-agent orchestration, MCP authentication and gateway integration, webhook support, conditional and parallel steps, OpenAPI-to-Naftiko import tooling, a Control API accessible via CLI, and starter capability templates. The first beta in June focuses on a stable specification, resilience patterns, MCP server-side code mode, reference bridge capabilities, and enhanced governance and authorization. General availability is targeted for September.

The trajectory is clear: start with the core consume/expose engine, layer on AI-native protocols, add enterprise-grade reliability and security, and reach production readiness by fall. That’s an aggressive timeline, but the architectural foundation — a spec-interpreted engine with no code generation — means they’re not fighting the complexity that slows down most framework projects.

Why This Matters

I’ve been covering APIs since 2010. I’ve seen every integration pattern, every middleware platform, every attempt to make API consumption easier. Most of them added complexity rather than removing it. Most of them required you to learn their framework before you could do the integration work you actually needed to do.

The Naftiko Framework is the first approach I’ve seen that genuinely reduces the surface area of integration to its essential elements: what do you consume, what do you expose, and how do you connect them. Everything else is handled by the engine. Your YAML file is small enough to read in a sitting, precise enough to execute without interpretation, and portable enough to deploy anywhere Docker runs.

If you’re an enterprise team managing dozens of API integrations, a developer building AI-powered applications, or an architect trying to rationalize microservice sprawl, the Naftiko Framework is worth your attention. Pull the Docker image, write a Hello World capability, and see what happens when your integration is a specification rather than a codebase.

But there’s a problem that none of these transformation narratives address directly: the integration layer underneath all of it is still held together with duct tape.

What the Signals Tell Us

Naftiko’s signal-based analysis of 10 professional services companies – spanning 2,561 technology areas, 435 services, 260 tools, and 239 standards – paints a picture that is both impressive and revealing.

The strengths are where you’d expect them. Services investment leads at 1,762, followed by Data at 905 and Cloud at 896. Security and Operations round out the top five. These firms have deep technology footprints. They are not under-invested in the raw materials of AI transformation.

But look at where the gaps are, and the structural challenge comes into focus.

Specifications scored 50. In an industry that is trying to shift from bespoke projects to reusable platform models, the investment in the standards that make reuse possible – OpenAPI, AsyncAPI, JSON Schema – is barely registering. You cannot build a governed, discoverable capability inventory on top of undocumented, unspecified APIs.

Context Engineering scored 0. Zero. The very discipline of delivering the right context to AI systems – the thing that determines whether copilots and agents produce useful outputs or hallucinated garbage – has no measurable investment signal across the entire industry.

Domain Specialization scored 13. Despite every firm talking about industry-specific AI solutions, the actual investment in domain-specialized infrastructure is negligible.

SaaS scored 28. Privacy & Data Rights scored 34. AI FinOps scored 43. The economic and governance layers that would make AI-native operations sustainable at scale are all in the bottom five.

The Operating Model Problem

The research coming out of the professional services world right now tells a compelling story about structural reinvention. Accenture is moving from siloed business units to integrated, outcome-focused teams. EY is weaving AI into its core service lines – using machine learning to automate audit procedures, accelerate tax compliance workflows, and deliver real-time advisory insights across its global practice. Both firms are redistributing technology ownership from central IT into business teams. Work is being redesigned around the assumption that AI handles execution while humans focus on orchestration and judgment.

These are the right instincts. But they run headlong into a practical reality: if your 14,000+ internal APIs are undocumented, ungoverned, and invisible to the AI systems that are supposed to orchestrate them, your reinvention stalls at the integration layer.

Consider what Accenture achieved in finance – freeing up 20% of idle cash with machine learning, saving 57,000 hours annually with AI-generated narratives, tripling receivables automation. Or look at EY, which has invested over $1.4 billion in AI and has been rolling AI-driven automation into audit, tax, and consulting engagements – reducing cycle times and enabling teams to focus on higher-value judgment work. These are genuine, measurable outcomes. But each one required custom integration work against specific systems, specific data models, specific APIs. They are victories of craftsmanship, not of a repeatable capability architecture.

The question isn’t whether Accenture or EY can build impressive AI-powered solutions one at a time. They clearly can. The question is whether their operating models can scale that approach across thousands of use cases without the integration layer collapsing under its own weight.

Adoption vs. Outcomes – and the Infrastructure Between Them

One of the sharpest critiques in the current discourse is the distinction between measuring AI adoption and measuring AI outcomes. Making AI a promotion requirement, as Accenture has done, drives compliance. But as several observers have pointed out, adoption of a technology doesn’t necessarily lead to value creation from that technology.

What’s missing from this debate is the infrastructure gap that sits between adoption and outcomes. An AI agent cannot automate a workflow that has never been defined. It cannot generate reliable insights without access to high-quality data. It cannot scale expertise if that expertise is not captured in a structured way. These are real constraints, and they are precisely what shows up as zeros and single-digit scores in our signal analysis.

When firms like Accenture and EY talk about shifting from projects to platforms, from bespoke delivery to reusable assets, they are describing a world that requires:

• Discoverable APIs – not just documented, but findable and evaluable by both humans and AI systems.
• Governed integration patterns – not shadow MCP servers and ad-hoc agent connections, but policy-driven, auditable capability boundaries.
• Specification-first infrastructure – where what a service consumes, exposes, and governs is declared explicitly, not reverse-engineered from production traffic.
• Context engineering – delivering right-sized context to AI rather than dumping raw API complexity into ever-growing tool lists.

This is the capability layer. Not another tool or platform, but the structural pattern that turns existing technology investments into something AI can actually work with at scale.

The Pyramid Is Flattening – Into What?

The disruption of the traditional consulting pyramid is one of the most discussed consequences of AI in professional services. When AI automates many junior-level tasks, the economics of scaling human effort as a growth mechanism break down.

But the firms that navigate this transition successfully won’t be the ones that simply cut headcount. They’ll be the ones that replace the pyramid’s function – structured knowledge transfer from senior to junior staff through supervised project work – with something better: a governed inventory of capabilities that encode institutional knowledge in a form that both humans and AI systems can discover, compose, and build on.

This is fundamentally a specification and governance problem, not a hiring problem. And it’s exactly where the professional services industry is currently under-invested.

What Comes Next

The professional services industry is at an inflection point. The firms leading the conversation about AI-native operating models are asking the right strategic questions. But the signal data suggests a meaningful gap between the ambition and the infrastructure needed to realize it.

The firms that close that gap – that invest in specifications, context engineering, governed integration, and capability architecture – will be the ones that actually deliver on the promise of platform-based, AI-native service delivery. The ones that don’t will continue to achieve impressive results one project at a time, but they won’t compound.

The professional services industry’s aggregate technology score of 11,425 reflects serious investment. The question is whether that investment is structured in a way that AI can actually leverage – or whether it remains an archipelago of capabilities that no agent can navigate.

The Healthcare Integration Challenge

Naftiko is focused on standardizing and governing software integrations, and there are few sectors where this matters more than in healthcare. We want to explore how Naftiko can help enable the work at the European Health Data Space (EHDS), an EU initiative aimed at creating a unified framework for secure, cross-border access to patient health data, facilitating both personal care (primary use) and research and innovation (secondary use). By leveraging the Naftiko Capabilities specification and the Naftiko Framework, healthcare providers can transform legacy data, and then govern the integration of that data across systems and borders.

European hospitals run on HL7 v2. These pipe-delimited messages flow between EMR systems, national patient registries, and lab systems across the continent. The data is rich, the volume is massive, and the format is deeply embedded. Nobody is ripping it out. But the world is moving toward OpenEHR, a structured, archetype-based clinical data model that enables interoperability, FHIR bridging, and the kind of standardized data access the EHDS demands.

The question is not whether to modernize. The question is how to do it without losing what already works.

What Naftiko Capabilities Do

Naftiko aligns integrations with business outcomes using declarative, open-source, machine-readable and human-readable capabilities expressed as YAML. A Naftiko Capability consumes your existing data and APIs and produces what you need for AI integration. In this healthcare scenario, we use Naftiko Capabilities to consume classic HL7 v2 patient data and transform it into standardized, interoperable OpenEHR compositions.

Each capability declares three things:

• What it consumes – the existing HL7 v2 gateway and its message segments
• What it produces – the OpenEHR COMPOSITION posted to the clinical repository
• What it exposes – an MCP tool that an AI agent can discover and invoke

No custom code. No middleware. Just a YAML file that the Naftiko Framework executes in a Docker container.

Patient Admit: ADT^A01 to OpenEHR Encounter

The most fundamental hospital event is a patient admission. An ADT^A01 message fires when a patient is admitted, carrying identity, location, attending physician, and admitting diagnosis. Here is the Naftiko Capability that transforms it.

The Capability

naftiko: "1.0.0-alpha1"

info:
  label: HL7 v2 Pipe ADT^A01 Patient Admit to OpenEHR
  description: >-
    Transforms raw pipe-delimited HL7 v2 ADT^A01 Patient Admit messages into
    OpenEHR-compatible COMPOSITION resources. Consumes a hospital HL7 v2
    MLLP gateway that returns native pipe-separated HL7 v2 messages (not JSON)
    and produces an OpenEHR encounter composition with admin_entry for admission
    details and problem_diagnosis for admitting diagnosis.
  tags:
    - hl7v2
    - openehr
    - adt-a01
    - patient-admit
    - healthcare

capability:
  consumes:
    - namespace: hl7-gateway
      type: http
      baseUri: "https://hl7-gateway.hospital.example.eu/api/v1"
      description: >-
        Hospital HL7 v2 message gateway. Returns raw pipe-delimited
        HL7 v2 ADT^A01 Patient Admit messages as text/plain from the
        integration engine.
      authentication:
        type: bearer
        token: "{{HL7_GATEWAY_TOKEN}}"
      resources:
        - name: adt-events
          path: "/adt/events"
          operations:
            - name: get-admit-event
              method: GET

    - namespace: openehr-repo
      type: http
      baseUri: "https://ehrbase.hospital.example.eu/rest/openehr/v1"
      description: >-
        OpenEHR clinical data repository (EHRbase). Receives transformed
        COMPOSITION resources conforming to openEHR-EHR-COMPOSITION.encounter.v1.
      authentication:
        type: bearer
        token: "{{EHRBASE_TOKEN}}"
      resources:
        - name: compositions
          path: "/ehr/{{ehrId}}/composition"
          operations:
            - name: create-composition
              method: POST

  exposes:
    - type: mcp
      port: 3010
      namespace: hl7-openehr-tools
      description: >-
        MCP tools for transforming HL7 v2 ADT^A01 Patient Admit messages
        into OpenEHR encounter compositions.
      tools:
        - name: transform-adt-a01
          description: >-
            Fetches an ADT^A01 Patient Admit message from the HL7 gateway,
            transforms it into an OpenEHR encounter composition with admission
            details and diagnosis, and posts it to the OpenEHR repository.
          inputParameters:
            - name: messageId
              type: string
              required: true
              description: "HL7 message control ID (MSH-10)"
            - name: ehrId
              type: string
              required: true
              description: "Target OpenEHR EHR identifier"
          steps:
            - name: fetch-admit
              type: call
              call: hl7-gateway.get-admit-event
              with:
                messageId: hl7-openehr-tools.messageId
            - name: post-composition
              type: call
              call: openehr-repo.create-composition
              with:
                ehrId: hl7-openehr-tools.ehrId

Read it top to bottom: consume the HL7 gateway, consume the OpenEHR repository, expose an MCP tool that orchestrates the two. The steps section fetches the HL7 message, then posts the transformed composition. That is the entire integration.

What Gets Consumed: The HL7 v2 Message

This is what comes off the wire. A real ADT^A01 from a European hospital, with the patient’s national identifier, ward assignment, attending physician, and admitting diagnosis coded in ICD-10:

MSH|^~\&|EMR_SYSTEM|CENTRAL_HOSPITAL|NATIONAL_REGISTRY|HEALTH_AUTHORITY|20240315082300||ADT^A01^ADT_A01|MSG00001|P|2.5|||AL|NE||UTF-8
EVN|A01|20240315082300|||^Lindqvist^Anna^^^Dr.
PID|1||7812150423^^^NATIONAL_ID&2.16.840.1.113883.4.1&ISO~10045^^^EMR&LOCAL||Mueller^Erik^Johan||19781215|M|||Hauptstrasse 12^^Berlin^^10115^DE^H||+4930123456|||M
PD1|||City Medical Center^^12345|^Weber^Maria^^^Dr.
PV1|1|I|WARD-23^Room-4^Bed-2|E|||^Lindqvist^Anna^^^Dr.|^Bergman^Lars^^^Dr.||MED|||||||^Lindqvist^Anna^^^Dr.|INP|V201500123456||||||||||||||||||||||A|||20240315082300
DG1|1||J18.9^Pneumonia, unspecified^ICD10|Pneumonia|20240315|A

Every field matters. PID-3 carries the patient’s national identifier (7812150423) with the appropriate OID namespace. PV1-3 encodes the ward, room, and bed (WARD-23^Room-4^Bed-2). DG1-3 carries the ICD-10 diagnosis code (J18.9 – unspecified pneumonia). This is the reality of healthcare data in production.

What Gets Produced: The OpenEHR Composition

The Naftiko Capability transforms that pipe-delimited message into a structured OpenEHR composition that any EHDS-compliant system can consume:

{
  "_type": "COMPOSITION",
  "archetype_node_id": "openEHR-EHR-COMPOSITION.encounter.v1",
  "name": { "value": "Inpatient Admission" },
  "language": {
    "terminology_id": { "value": "ISO_639-1" },
    "code_string": "en"
  },
  "territory": {
    "terminology_id": { "value": "ISO_3166-1" },
    "code_string": "DE"
  },
  "composer": {
    "_type": "PARTY_IDENTIFIED",
    "name": "Dr. Anna Lindqvist",
    "external_ref": {
      "id": { "_type": "GENERIC_ID", "value": "PROV-2321000016-A123", "scheme": "PROVIDER-ID" },
      "namespace": "2.16.840.1.113883.4.1",
      "type": "PERSON"
    }
  },
  "context": {
    "start_time": { "value": "2024-03-15T08:23:00+01:00" },
    "setting": {
      "value": "emergency care",
      "defining_code": {
        "terminology_id": { "value": "openehr" },
        "code_string": "227"
      }
    }
  },
  "content": [
    {
      "_type": "ADMIN_ENTRY",
      "archetype_node_id": "openEHR-EHR-ADMIN_ENTRY.admission.v0",
      "name": { "value": "Admission" },
      "subject": {
        "_type": "PARTY_IDENTIFIED",
        "external_ref": {
          "id": { "_type": "HIER_OBJECT_ID", "value": "7812150423" },
          "namespace": "2.16.840.1.113883.4.1",
          "type": "PERSON"
        }
      },
      "data": {
        "_type": "ITEM_TREE",
        "items": [
          {
            "_type": "ELEMENT",
            "name": { "value": "Date/time of admission" },
            "value": { "_type": "DV_DATE_TIME", "value": "2024-03-15T08:23:00+01:00" }
          },
          {
            "_type": "ELEMENT",
            "name": { "value": "Admission type" },
            "value": {
              "_type": "DV_CODED_TEXT",
              "value": "Emergency",
              "defining_code": {
                "terminology_id": { "value": "openehr" },
                "code_string": "EMERGENCY"
              }
            }
          },
          {
            "_type": "ELEMENT",
            "name": { "value": "Ward" },
            "value": { "_type": "DV_TEXT", "value": "WARD-23" }
          },
          {
            "_type": "ELEMENT",
            "name": { "value": "Room" },
            "value": { "_type": "DV_TEXT", "value": "Room-4" }
          },
          {
            "_type": "ELEMENT",
            "name": { "value": "Bed" },
            "value": { "_type": "DV_TEXT", "value": "Bed-2" }
          }
        ]
      }
    },
    {
      "_type": "EVALUATION",
      "archetype_node_id": "openEHR-EHR-EVALUATION.problem_diagnosis.v1",
      "name": { "value": "Admitting Diagnosis" },
      "data": {
        "_type": "ITEM_TREE",
        "items": [
          {
            "_type": "ELEMENT",
            "name": { "value": "Problem/Diagnosis name" },
            "value": {
              "_type": "DV_CODED_TEXT",
              "value": "Pneumonia, unspecified",
              "defining_code": {
                "terminology_id": { "value": "ICD-10" },
                "code_string": "J18.9"
              }
            }
          }
        ]
      }
    }
  ]
}

The patient’s national identifier is preserved with its correct OID namespace. The provider ID on the attending doctor maps to PARTY_IDENTIFIED. The ICD-10 diagnosis code binds to the proper terminology. The ward, room, and bed from PV1-3 land in discrete, queryable elements. This is not a lossy conversion – it is a structured, governed transformation that retains clinical fidelity.

Patient Discharge: ADT^A03 to OpenEHR Discharge Summary

The discharge is the other bookend. An ADT^A03 fires when a patient leaves the hospital, carrying the final diagnosis, discharge disposition, and critically, the discharge instructions that follow the patient home.

The Capability

naftiko: "1.0.0-alpha1"

info:
  label: HL7 v2 Pipe ADT^A03 Patient Discharge to OpenEHR
  description: >-
    Transforms raw pipe-delimited HL7 v2 ADT^A03 Patient Discharge messages into
    OpenEHR-compatible discharge summary compositions with admin_entry for discharge
    details, problem_diagnosis for final diagnosis, and clinical_synopsis for
    discharge instructions.
  tags:
    - hl7v2
    - openehr
    - adt-a03
    - patient-discharge
    - healthcare

capability:
  consumes:
    - namespace: hl7-gateway
      type: http
      baseUri: "https://hl7-gateway.hospital.example.eu/api/v1"
      description: >-
        Hospital HL7 v2 message gateway. Returns raw pipe-delimited
        HL7 v2 ADT^A03 Patient Discharge messages as text/plain.
      authentication:
        type: bearer
        token: "{{HL7_GATEWAY_TOKEN}}"
      resources:
        - name: discharge-events
          path: "/adt/discharges"
          operations:
            - name: get-discharge-event
              method: GET

    - namespace: openehr-repo
      type: http
      baseUri: "https://ehrbase.hospital.example.eu/rest/openehr/v1"
      description: >-
        OpenEHR clinical data repository (EHRbase). Receives transformed
        discharge summary compositions.
      authentication:
        type: bearer
        token: "{{EHRBASE_TOKEN}}"
      resources:
        - name: compositions
          path: "/ehr/{{ehrId}}/composition"
          operations:
            - name: create-composition
              method: POST

  exposes:
    - type: mcp
      port: 3011
      namespace: hl7-discharge-tools
      description: >-
        MCP tools for transforming HL7 v2 ADT^A03 Patient Discharge messages
        into OpenEHR discharge summary compositions.
      tools:
        - name: transform-adt-a03
          description: >-
            Fetches an ADT^A03 Patient Discharge message, transforms it into an
            OpenEHR discharge summary with discharge details, final diagnosis,
            and clinical synopsis, then posts it to the OpenEHR repository.
          inputParameters:
            - name: messageId
              type: string
              required: true
              description: "HL7 message control ID (MSH-10)"
            - name: ehrId
              type: string
              required: true
              description: "Target OpenEHR EHR identifier"
          steps:
            - name: fetch-discharge
              type: call
              call: hl7-gateway.get-discharge-event
              with:
                messageId: hl7-discharge-tools.messageId
            - name: post-composition
              type: call
              call: openehr-repo.create-composition
              with:
                ehrId: hl7-discharge-tools.ehrId

Same pattern: consume, transform, expose. The difference is what gets produced on the other side.

What Gets Consumed: The HL7 v2 Discharge Message

Seven days after admission, the patient is discharged. The ADT^A03 carries the full stay timeline, the final diagnosis (now confirmed, type F instead of admitting type A), and the discharge instructions in the PV2 segment:

MSH|^~\&|EMR_SYSTEM|CENTRAL_HOSPITAL|NATIONAL_REGISTRY|HEALTH_AUTHORITY|20240322143000||ADT^A03^ADT_A03|MSG00042|P|2.5|||AL|NE||UTF-8
EVN|A03|20240322143000|||^Lindqvist^Anna^^^Dr.
PID|1||7812150423^^^NATIONAL_ID&2.16.840.1.113883.4.1&ISO~10045^^^EMR&LOCAL||Mueller^Erik^Johan||19781215|M|||Hauptstrasse 12^^Berlin^^10115^DE^H||+4930123456|||M
PV1|1|I|WARD-23^Room-4^Bed-2|E|||^Lindqvist^Anna^^^Dr.|^Bergman^Lars^^^Dr.||MED|||||||^Lindqvist^Anna^^^Dr.|INP|V201500123456||||||||||||||||01||||||A|||20240315082300|||20240322143000
PV2||||||||||||||||||||Continue antibiotics (Amoxicillin 500mg x3) for 7 days. Follow-up at primary care within 2 weeks. Contact emergency department if shortness of breath or fever above 39C.
DG1|1||J18.9^Pneumonia, unspecified^ICD10|Pneumonia|20240315|F

PV1-36 carries the discharge disposition (01 – discharged to home). PV1-44 and PV1-45 bracket the stay: admitted March 15, discharged March 22. The PV2 segment carries the actual discharge instructions – medication continuation, follow-up appointment, and emergency criteria.

What Gets Produced: The OpenEHR Discharge Summary

The output is a proper discharge summary composition with three content blocks: the administrative discharge record, the confirmed final diagnosis, and the clinical synopsis preserving the discharge instructions:

{
  "_type": "COMPOSITION",
  "archetype_node_id": "openEHR-EHR-COMPOSITION.discharge_summary.v1",
  "name": { "value": "Discharge Summary" },
  "language": {
    "terminology_id": { "value": "ISO_639-1" },
    "code_string": "en"
  },
  "territory": {
    "terminology_id": { "value": "ISO_3166-1" },
    "code_string": "DE"
  },
  "context": {
    "start_time": { "value": "2024-03-15T08:23:00+01:00" },
    "end_time": { "value": "2024-03-22T14:30:00+01:00" },
    "setting": {
      "value": "hospital",
      "defining_code": {
        "terminology_id": { "value": "openehr" },
        "code_string": "225"
      }
    }
  },
  "content": [
    {
      "_type": "ADMIN_ENTRY",
      "archetype_node_id": "openEHR-EHR-ADMIN_ENTRY.discharge.v0",
      "name": { "value": "Discharge" },
      "data": {
        "_type": "ITEM_TREE",
        "items": [
          {
            "_type": "ELEMENT",
            "name": { "value": "Date/time of admission" },
            "value": { "_type": "DV_DATE_TIME", "value": "2024-03-15T08:23:00+01:00" }
          },
          {
            "_type": "ELEMENT",
            "name": { "value": "Date/time of discharge" },
            "value": { "_type": "DV_DATE_TIME", "value": "2024-03-22T14:30:00+01:00" }
          },
          {
            "_type": "ELEMENT",
            "name": { "value": "Discharge disposition" },
            "value": {
              "_type": "DV_CODED_TEXT",
              "value": "Discharged to home",
              "defining_code": {
                "terminology_id": { "value": "local" },
                "code_string": "01"
              }
            }
          }
        ]
      }
    },
    {
      "_type": "EVALUATION",
      "archetype_node_id": "openEHR-EHR-EVALUATION.problem_diagnosis.v1",
      "name": { "value": "Final Diagnosis" },
      "data": {
        "_type": "ITEM_TREE",
        "items": [
          {
            "_type": "ELEMENT",
            "name": { "value": "Problem/Diagnosis name" },
            "value": {
              "_type": "DV_CODED_TEXT",
              "value": "Pneumonia, unspecified",
              "defining_code": {
                "terminology_id": { "value": "ICD-10" },
                "code_string": "J18.9"
              }
            }
          },
          {
            "_type": "ELEMENT",
            "name": { "value": "Diagnostic certainty" },
            "value": {
              "_type": "DV_CODED_TEXT",
              "value": "Confirmed",
              "defining_code": {
                "terminology_id": { "value": "local" },
                "code_string": "at0076"
              }
            }
          }
        ]
      }
    },
    {
      "_type": "EVALUATION",
      "archetype_node_id": "openEHR-EHR-EVALUATION.clinical_synopsis.v1",
      "name": { "value": "Discharge Instructions" },
      "data": {
        "_type": "ITEM_TREE",
        "items": [
          {
            "_type": "ELEMENT",
            "name": { "value": "Synopsis" },
            "value": {
              "_type": "DV_TEXT",
              "value": "Continue antibiotics (Amoxicillin 500mg x3) for 7 days. Follow-up at primary care within 2 weeks. Contact emergency department if shortness of breath or fever above 39C."
            }
          }
        ]
      }
    }
  ]
}

The discharge instructions land in a proper clinical_synopsis.v1 archetype. They are no longer buried in a PV2 segment that only HL7-literate systems can parse. Any OpenEHR-connected application, any FHIR bridge, any AI agent with access to the patient’s EHR can now surface these instructions.

From Individual Capabilities to Governed Integration

These capabilities can be executed using the open-source Naftiko Framework in a Docker container. You can aggregate capabilities, introduce multiple steps, and compose different scenarios that produce the standardized and interoperable primary and secondary use outcomes any healthcare provider should be able to deliver in 2026.

The pattern scales. ADT^A01 and ADT^A03 are the admission and discharge bookends, but the same approach applies to ORM^O01 lab orders, ORU^R01 lab results, RDE^O11 medication orders, and every other HL7 v2 message type flowing through European hospital systems. Each becomes a governed capability: declared in YAML, versioned, discoverable, and executable.

What Comes Next

Naftiko is just getting started. An alpha version of the framework is available today, and we are looking for design partners to help us ensure the framework and capabilities work across classic healthcare formats like HL7 v2, as well as modern standards like OpenEHR and FHIR. Our goal is to make sure you can consume and transform whatever you need to confidently integrate AI into healthcare operations.

Consuming legacy data and APIs, and producing the HTTP APIs, MCP tools, and Agent Skills needed to integrate AI into healthcare and clinical environments is just the start. In Q2 2026 we are focused on delivering the Naftiko Fleet alongside the Naftiko Framework, taking all of the capabilities developed by our design partners and ensuring they are:

• Discoverable – Easy to find and make visible as part of business and engineering operations.
• Standardized – Following the standards required as part of any industry regulation in place.
• Compliant – Aligning with government regulations that apply to healthcare integrations.
• Governed – Ensuring the technical and business details of integrations are always managed.

The Naftiko Fleet is where we help healthcare providers connect the dots across all of the standardized integrations put in place, making sure existing investments in patient data can be transformed into what is needed for modern desktop, web, mobile, and AI applications. The Naftiko Framework is how you define what a healthcare provider is capable of. The Naftiko Fleet is how you ensure you can move in whatever direction is needed.

Looking for Design Partners

We are actively looking for healthcare design partners who need to modernize and integrate their existing patient data securely and confidently into AI workflows. The Naftiko Framework and Capabilities specification are both released under the Apache 2.0 license, with the Naftiko Fleet leveraging a commercial open-source approach to help fund what is needed to shape the next generation of healthcare that is interoperable and patient-driven across applications and borders.

If you are working with HL7 v2, OpenEHR, FHIR, or any combination of healthcare data standards and want to explore how governed capabilities can accelerate your integration roadmap, we want to hear from you.

That’s why we built Naftiko Signals.

What Signals Does

Signals is an open intelligence platform that tracks technology investment across 311 enterprise companies spanning 49 industries. It’s available at signals.naftiko.io and the entire dataset is open source on GitHub.

For each company, we profile investment across four dimensions:

Areas of Technology. The technical domains a company actively invests in. Not what they talk about at conferences — what they’re actually hiring for, contributing to, and building around. AI, APIs, cloud infrastructure, containers, platform engineering, security, observability, governance. Forty-four signal groups in total, each measuring a specific dimension of enterprise investment.

SaaS Portfolio. The services and platforms a company buys, builds, or integrates. This is one of the most revealing dimensions because it shows where a company trusts the ecosystem versus where they go it alone. An enterprise running fourteen different integration platforms tells a very different story than one that has consolidated around two.

Standards. Participation in open standards and specifications — OpenAPI, AsyncAPI, JSON Schema, MCP, A2A. Standards adoption is a strong signal of interoperability commitment. Companies that invest in standards are building for composability. Companies that don’t are building silos, regardless of what their architecture diagrams say.

Tooling. The developer tools and open-source projects a company adopts or contributes to. Engineering culture is visible in tooling choices. A company contributing to CNCF projects has a fundamentally different engineering culture than one that builds everything internally.

Why 44 Signal Groups

The number of signal groups isn’t arbitrary. We started by mapping the dimensions that matter for understanding enterprise readiness for AI-driven integration — which is Naftiko’s core domain. But it quickly became clear that AI readiness can’t be assessed in isolation. You need to understand the cloud posture, the API maturity, the integration strategy, the data infrastructure, the governance model, and the organizational design before you can say anything meaningful about whether a company is ready for agentic AI.

So the signal groups span the full stack: Artificial Intelligence, Cloud, Open-Source, Languages, Data, Databases, Virtualization, Specifications, Context Engineering, Data Pipelines, Containers, Platform, API, Integrations, Event-Driven, Observability, Governance, Security, Automation, ROI & Business Metrics, Regulatory Posture, AI FinOps, Provider Strategy, Talent & Organizational Design, and more.

Each signal group includes a description of what we measure and how we interpret it. “Measuring the AI investment” doesn’t mean counting press releases. It means evaluating ChatGPT usage patterns, MCP adoption, agentic automation investment, and the depth of organizational understanding.

The Analysis Layers

Raw signals are useful but not sufficient. The interesting part is what happens when you look across companies and industries for patterns.

AI Waves. We identify recurring waves of AI adoption — patterns that emerge as technology matures and spreads. Large Language Models, Coding Assistants, Context Engineering, Retrieval-Augmented Generation, Model Routing, Agent-to-Agent protocols. Each wave has a lifecycle, and companies are at different points on each one. Knowing where a company is on the Context Engineering wave versus the RAG wave tells you something specific about their AI maturity that a generic “AI adoption score” never could.

Roles. Each wave reshapes the talent landscape. We map which roles are growing, which are shrinking, and which entirely new ones are emerging. The appearance of “AI Platform Engineer” and “Context Engineer” in job postings is itself a signal — one that predicts organizational investment more reliably than strategy announcements.

Impact. We assess the downstream impact of each wave on markets, workflows, and the cost/velocity/risk balance inside enterprises. This is where signals become actionable. If you can see that companies in your industry are uniformly investing in context engineering while your organization is still debating whether to adopt coding assistants, that’s a strategic data point.

The Radar

One of the most useful views in Signals is the Naftiko Radar — a visual map of every technology, service, tool, and standard we track, plotted across four adoption rings: Adopting, Optimizing, Evaluating, and Watching.

The Radar gives you a single view of where the industry is now and where it’s heading. It’s updated as our signal data changes, so it reflects the current state of enterprise investment rather than a quarterly snapshot that was already stale when it was published.

Open by Design

This is deliberate and important: Signals is fully open source. The entire platform is a Jekyll site hosted on GitHub Pages. Every data point — companies, industries, signals, services, tools, standards, waves — is a structured YAML file in a Git repository. You can inspect it, fork it, contribute to it, or build on top of it.

We made this choice because intelligence about enterprise technology investment should be as accessible as the open-source projects it tracks. The analyst model of charging six figures for a PDF that’s outdated before the ink dries is broken. The engineering community deserves better signal sources, and the best way to build trust in data is to make it transparent.

Why This Matters for Naftiko

Signals isn’t separate from Naftiko’s core mission — it’s foundational to it. Naftiko builds governed, spec-driven integration capabilities that connect enterprise APIs to AI agents. To do that well, we need to understand what APIs enterprises are actually using, what integration patterns they’ve adopted, what standards they participate in, and where they are on the AI adoption curve.

Signals gives us — and gives every technology leader — that understanding. When we profile a company’s SaaS portfolio and see fourteen integration platforms, that’s not just a data point. That’s a signal about integration complexity, governance gaps, and the opportunity for a capability-driven approach. When we see a company investing heavily in MCP and context engineering, that’s a signal about readiness for the kind of spec-driven integration Naftiko provides.

The signals inform the capabilities. The capabilities reduce the complexity that the signals reveal. That’s the loop.

Get Started

Browse the platform at signals.naftiko.io. Start with the industries view if you want to see how your sector is investing. Start with the company view if you want to benchmark against specific organizations. Start with the radar if you want the broadest view of where enterprise technology is heading.

The data is open. The signals are clear. What you do with them is up to you.