The Language of Control: The Software Orchestrator's Vocabulary

Compare two requests to an AI assistant.

The second request is not longer because it is more polite — it is more precise because it uses vocabulary that names the exact constraint. Vocabulary is the structure you impose on a task before an assistant ever starts reasoning about it. A team that shares precise terms for its architecture can direct AI-accelerated work with a handful of words; a team without that vocabulary has to hope the assistant infers the same constraints the vague prompt failed to state.

This is the second post in The Software Orchestrator Framework — Phase 1: Foundation. Part 1 covered the principles; this post covers the vocabulary that makes those principles operational across four domains: UI, backend/infrastructure, DevOps workflows, and software design itself.

Domain A — UI / Frontend

• Design Tokens — the named, single-source values (color.primary, space.md) that stand in for hardcoded hex codes and pixel values, so "the same" visually is enforced by shared reference, not convention.
• Atomic Design — organizing UI into atoms → molecules → organisms → templates → pages, so a request can be scoped to the smallest correct unit ("modify the atom," not "modify the page").
• Accessibility Contracts — the explicit, testable requirements (ARIA roles, contrast ratios, keyboard navigation) a component must satisfy, stated as a contract rather than left to be inferred from a generic training-data pattern.

Domain B — Backend / Infrastructure

• Ephemeral Sandboxing — running untrusted or exploratory code (including AI-generated code) in a disposable, isolated environment that leaves no persistent trace if it misbehaves.
• Graceful Degradation — a system that continues operating in a reduced but honest state when a dependency fails, rather than crashing outright or silently pretending everything is fine.
• Compute Primitives — the named building blocks (function, container, VM, edge worker) a task is scoped to, so "run this" has an unambiguous execution boundary.
• Storage Classes — the named tiers (hot, warm, cold, object, block) that make a storage decision explicit rather than an implicit default.
• Data Architecture Patterns — named shapes (event sourcing, CQRS, star schema) that let a request reference a known structure instead of re-deriving one from scratch each time.

Domain C — DevOps / Workflows (the Core)

This is where orchestration lives day to day, and where three concrete artifacts turn Phase 1's principles into repository reality.

• GitOps — the repository is the single source of truth for desired state; deployment is a reconciliation against that state, not a manual action against production.
• Shift-Left — move validation (tests, security scans, review) as early in the process as possible, so a violation is caught at the commit, not in production.
• Policy-as-Code — rules (security, compliance, architecture) expressed as executable checks, not prose someone might read.
• Observability — the system emits enough signal (logs, metrics, traces) that its actual behavior is knowable, not just its intended behavior.

The Three Orchestration Artifacts

Three concrete artifacts are what make the Phase 1 principles enforceable, not aspirational:

1. The Auto-Feedback Loop — an automated check that runs on every change and reports pass/fail immediately. This is what enforces Fail Fast and Idempotency in practice: a violation is caught the moment it happens, by a machine, every time.
2. The Platform Playbook — the documented, scoped procedure for a recurring task, written so both a human and an AI assistant can follow it without re-deriving the approach. This is what enforces Bounded Context and Least Astonishment: the correct scope and the expected shape of the work are written down, not assumed.
3. The AI Regression Log — a record of AI-introduced failures that have been converted into permanent tests or guardrails. This is what enforces the Self-Improving Repository: the same mistake becomes structurally harder to repeat.

Domain D — Software Design

• Cyclomatic Complexity — a measurable count of the independent paths through a function; a named metric for "this is getting too tangled to reason about," instead of a vague feeling.
• Contract Testing — verifying that a component honors its interface's stated behavior, independent of any particular caller — the automated proof that abstraction (Phase 1) actually holds.
• Test Pyramid — the proportioned shape of a test suite (many fast unit tests, fewer integration tests, few end-to-end tests), naming where verification should live so speed and coverage stay balanced.

Mapping Vocabulary to Principles

Vocabulary is not decoration — every term above exists because it makes a Phase 1 principle checkable, requestable, or enforceable.

What's Next: The Mindset

Principles (Phase 1A) name what must hold. Vocabulary (this post) names the concrete terms that make those principles requestable and enforceable. Phase 2: The Mindset is next — the engineering judgment an orchestrator applies day to day, using this foundation as the ground to stand on.

For the full method, see The DevOps Engineer's Guide to Effective AI Usage.