Draft 0.2 · Business Semantics Foundation

Specification

ABCS defines canonical business meaning independently of application vendors and implementation technology. Draft 0.2 establishes the core model, initial business-domain map, canonical Business Object model, and minimal discovery/invocation semantics.

Status: Draft / pre-1.0. Definitions may evolve before ABCS 1.0. ABCS is an open specification; it is not represented as a widely adopted industry standard.

1. Normative scope

Capability is the universal executable primitive. Domains classify capabilities into enduring areas of business responsibility. Business Objects define the canonical business information capabilities act upon, consume or produce.

Would this capability still make business sense if humans performed the work manually and all implementation technology disappeared?

If not, it is outside ABCS. Technology disciplines such as integration infrastructure, automation infrastructure, middleware and generic IT operations are not ABCS business domains.

2. Initial business domains

Draft 0.2 establishes the initial namespaces procurement, finance, sales, hr, service, logistics, manufacturing, and projects. The catalogs are intentionally non-exhaustive. Procurement is the first deep reference domain.

3. Canonical identifiers

Capability:      <domain>.<business-subject>.<operation>
Business Object: <domain>.<business-object>

procurement.purchase-order.submit
finance.payment.approve
hr.payroll-run.schedule
procurement.purchase-order

Segments use lower-case kebab-case. Canonical identifiers must preserve established business meaning across compatible revisions.

4. Capability definition

abcs: "0.2"
id: procurement.purchase-order.approve
title: Approve Purchase Order
domain: procurement
kind: command
summary: Record an authorized approval of a purchase order.
objects:
  - object: procurement.purchase-order
    role: primary
input:
  schema: schemas/capabilities/procurement/purchase-order-approve-input.schema.json
output:
  schema: schemas/objects/procurement/purchase-order.schema.json
preconditions:
  approvalState: pending
effects:
  approvalState: approved

Capabilities may reference zero or more Business Objects. ABCS does not require a fake object merely to satisfy a schema, although canonical business capabilities will commonly operate on business information.

5. Business Objects

A Business Object is a supporting canonical semantic contract, not an execution primitive. Definitions may specify business keys, fields, relationships, state dimensions, related capabilities, schema versions and provenance. Vendor-native fields and implementation routing are excluded.

Read the Business Object model →

6. Parties and roles

Party is a reusable business-participant concept. Supplier, Customer, Buyer, Seller, Payer, Payee and Carrier are contextual business roles. Domain-specific objects can preserve these views while referencing a shared Party identity.

7. Supporting semantics

Processes, Policies, Events, Roles and Relationships support capability meaning but are not peer executable primitives. If a process must be externally performed, expose a Capability whose identity describes the business action rather than the implementation mechanism.

8. Business scheduling

hr.payroll-run.schedule and finance.payment-run.schedule are valid because scheduling those business runs has independent business meaning. Scheduling a cron job, container job, middleware task or generic batch executable is outside ABCS.

9. Discovery and invocation

ABCS defines transport-neutral Discover, Describe and Invoke semantics and a small Capability Invocation Envelope. An optional HTTP binding may use GET /capabilities, GET /capabilities/{id} and POST /capabilities. HTTP is a convention, not the core specification.

Read Discovery & Invocation →

10. Compatibility

Adding optional canonical information is generally compatible. Removing required information, changing a canonical field's business meaning, changing defined business effects, or silently redefining an established identifier is breaking. Specification version, capability-definition version and Business Object schema version are distinct concerns.

11. Conformance

An implementation conforms to an ABCS capability when it declares the canonical identifier, preserves the defined business semantics, satisfies the applicable canonical contracts, and clearly exposes limitations that affect those semantics.

12. Relationship to Sirvisetti Autonomy

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

Outside ABCS: middleware, transports, OAuth/mTLS/JWT, message brokers, EDI transport, workflow engines, schedulers, databases, agent frameworks, ERP APIs, adapters, retries, routing and other implementation machinery.

The versioned source specification is available at specification/0.2.