SirvisettiABCSDraft 0.2
Business interoperability

Discovery & invocation

ABCS defines the minimum semantics needed for one party or system to discover and invoke canonical business capabilities without knowing how the receiving business implements them.

DiscoverWhat canonical business capabilities are supported?
DescribeWhat does a capability mean and what contracts apply?
InvokeRequest performance of the canonical business capability.

Capability Invocation Envelope

{
  "abcs": "0.2",
  "capability": "procurement.purchase-order.submit",
  "requestId": "01J...",
  "from": { "id": "urn:example:walmart" },
  "to": { "id": "urn:example:walgreens" },
  "payload": { ... }
}

The envelope carries capability identity and canonical business payload. from and to, when present, identify business participants rather than network addresses or authentication principals.

Response Envelope

{
  "abcs": "0.2",
  "capability": "procurement.purchase-order.submit",
  "requestId": "01J...",
  "outcome": "completed",
  "payload": { ... }
}

Canonical outcomes describe the capability invocation, not infrastructure failures. Transport errors, TLS failures, broker availability and similar technical conditions remain implementation concerns.

Optional HTTP binding

Important: HTTP is an example binding, not the ABCS core. The business semantics remain transport-neutral.
GET  /capabilities
GET  /capabilities/{capability}
POST /capabilities

This enables the simple architectural idea “One endpoint. Every business capability.” A business may expose one standard capability surface while retaining complete freedom over internal applications and technology.

Walmart → Walgreens

Walmart
   │
   │ procurement.purchase-order.submit
   │ canonical ABCS Purchase Order
   ▼
Walgreens capability surface
   │
   ├── SAP
   ├── Oracle
   └── custom implementation

The sender needs to understand the canonical business capability and contract, not the receiving company's ERP topology.

Authentication and transport

OAuth, mTLS, JWT, API gateways, messaging, EDI transport, routing, retries, queues and middleware are deliberately outside ABCS. Implementations choose the mechanisms appropriate to their security, reliability and regulatory requirements.

Boundary: ABCS standardizes the business meaning being exchanged. It does not standardize the infrastructure carrying the exchange.

Machine-readable schemas