Specification

ABCS defines a small, machine-readable model for describing business capabilities independently of any application vendor or implementation technology.

Design principles

• Business first: definitions describe business intent, not application APIs.
• Stable identity: canonical IDs should survive implementation changes.
• Machine-readable: definitions can be validated and discovered programmatically.
• Implementation-neutral: multiple implementations may satisfy one capability.
• Composable: capabilities can participate in processes, policies, and event-driven interactions.
• Open: the specification is designed for independent implementation.

Canonical identifiers

Draft 0.1 uses:

<domain>.<resource>.<operation>

Example:

procurement.purchase-order.get

Identifiers use lower-case kebab-case segments. A compatible definition revision retains the same canonical identifier; incompatible semantic change requires a new identifier or a future ABCS versioning rule.

Definition document

abcs: "0.1"
id: procurement.purchase-order.get
title: Get Purchase Order
domain: procurement
resource: purchase-order
operation: get
summary: Retrieve one purchase order by a supported identifier.
contracts:
  input: schemas/procurement/purchase-order-get-input.json
  output: schemas/procurement/purchase-order.json
relationships:
  related:
    - procurement.purchase-order.search

Conformance

An implementation conforms to an ABCS capability when it declares the canonical capability ID, satisfies the applicable input/output contract, preserves the defined business semantics, and exposes any implementation-specific limitations explicitly.

Relationship to Autonomy

Sirvisetti Autonomy is a reference and commercial implementation of ABCS. ABCS itself is intentionally implementation-independent; an ABCS implementation does not require Autonomy.