03 / CAPABILITY HARNESS

Give general-purpose AI the business context, tools, and boundaries to do real work.

A prompt can express one request. An operable business AI capability also needs business context, a task method, approved tools, coordination when necessary, evaluation, governance, and a usable path into daily work.

Explore the seven-responsibility Harness ↓

THE CAPABILITY LAYER

A business AI capability is a system of responsibilities, not one prompt.

The Harness separates five operating layers from two cross-cutting assurance layers. Every responsibility must be considered, but the implementation depth depends on the real task, risk, platform, and approved scope.

Logical cross-section · not a sequence, maturity model, product stack, or requirement for seven new systems.

Seven-responsibility Capability Harness cross-section with five operating layers sharing one capability spine and Evaluation and Governance spanning them as cross-cutting assurance layers.

BUSINESS AI CAPABILITY SPINE

L1OPERATING LAYERContext

PURPOSE: Enterprise terms, rules, policies, examples, knowledge, and applicability boundaries.
DESIGN QUESTION: What business knowledge is in scope, sourced, fresh, and permitted?
REPRESENTATIVE DESIGN ASSETS: Glossary
policy boundary
examples
business ontology
knowledge boundary
Possible design assets · not a promise to build each item

L2OPERATING LAYERInstructions

PURPOSE: Roles, SOPs, judgment principles, Skills, Prompts, and completion criteria.
DESIGN QUESTION: What method, judgment principles, and completion criteria guide the task?
REPRESENTATIVE DESIGN ASSETS: SOP
Skill candidate
system/project instructions
prompt template
done criteria
Possible design assets · not a promise to build each item

L3OPERATING LAYERTools

PURPOSE: Approved files, CLI, API, MCP, databases, and business systems.
DESIGN QUESTION: Which read and write actions are explicitly authorized?
REPRESENTATIVE DESIGN ASSETS: Approved file
CLI
API
MCP
connector
database adapter
Possible design assets · not a promise to build each item

L4OPERATING LAYEROrchestration

PURPOSE: Steps, state, triggers, human approvals, retries, exceptions, and recovery when the task requires them.
DESIGN QUESTION: Does the work require persistent state, multiple roles, approval, recovery, or monitoring?
REPRESENTATIVE DESIGN ASSETS: Workflow specification when authorized
state model
approval points
retry and recovery rules
Possible design assets · not a promise to build each item

L5CROSS-CUTTING ASSURANCEEvaluation

PURPOSE: Golden cases, criteria, regression checks, and acceptance thresholds.
DESIGN QUESTION: What representative cases, dimensions, threshold, and acceptance authority determine release?
REPRESENTATIVE DESIGN ASSETS: Golden cases
scorecard
regression suite
release threshold
acceptance owner
Possible design assets · not a promise to build each item

L6CROSS-CUTTING ASSURANCEGovernance

PURPOSE: Permissions, logs, data boundaries, versions, escalation, rollback, and responsibility.
DESIGN QUESTION: Who may access, approve, audit, stop, recover, and own the capability?
REPRESENTATIVE DESIGN ASSETS: Permission matrix
logs
escalation
data boundary
fallback
versioning
Possible design assets · not a promise to build each item

L7OPERATING LAYERExperience

PURPOSE: User entry points, interaction, feedback, guidance, training, and support.
DESIGN QUESTION: How will users enter, understand, correct, and receive support for the capability?
REPRESENTATIVE DESIGN ASSETS: Entry point
interaction pattern
feedback path
user guide
training
support
Possible design assets · not a promise to build each item

VISIBLE SEMANTIC EQUIVALENT

L1
OPERATING LAYER
Context
PURPOSE
Enterprise terms, rules, policies, examples, knowledge, and applicability boundaries.
DESIGN QUESTION
What business knowledge is in scope, sourced, fresh, and permitted?
REPRESENTATIVE DESIGN ASSETS
Glossary · policy boundary · examples · business ontology · knowledge boundary
L2
OPERATING LAYER
Instructions
PURPOSE
Roles, SOPs, judgment principles, Skills, Prompts, and completion criteria.
DESIGN QUESTION
What method, judgment principles, and completion criteria guide the task?
REPRESENTATIVE DESIGN ASSETS
SOP · Skill candidate · system/project instructions · prompt template · done criteria
L3
OPERATING LAYER
Tools
PURPOSE
Approved files, CLI, API, MCP, databases, and business systems.
DESIGN QUESTION
Which read and write actions are explicitly authorized?
REPRESENTATIVE DESIGN ASSETS
Approved file · CLI · API · MCP · connector · database adapter
L4
OPERATING LAYER
Orchestration
PURPOSE
Steps, state, triggers, human approvals, retries, exceptions, and recovery when the task requires them.
DESIGN QUESTION
Does the work require persistent state, multiple roles, approval, recovery, or monitoring?
REPRESENTATIVE DESIGN ASSETS
Workflow specification when authorized · state model · approval points · retry and recovery rules
L5
CROSS-CUTTING ASSURANCE
Evaluation
PURPOSE
Golden cases, criteria, regression checks, and acceptance thresholds.
DESIGN QUESTION
What representative cases, dimensions, threshold, and acceptance authority determine release?
REPRESENTATIVE DESIGN ASSETS
Golden cases · scorecard · regression suite · release threshold · acceptance owner
L6
CROSS-CUTTING ASSURANCE
Governance
PURPOSE
Permissions, logs, data boundaries, versions, escalation, rollback, and responsibility.
DESIGN QUESTION
Who may access, approve, audit, stop, recover, and own the capability?
REPRESENTATIVE DESIGN ASSETS
Permission matrix · logs · escalation · data boundary · fallback · versioning
L7
OPERATING LAYER
Experience
PURPOSE
User entry points, interaction, feedback, guidance, training, and support.
DESIGN QUESTION
How will users enter, understand, correct, and receive support for the capability?
REPRESENTATIVE DESIGN ASSETS
Entry point · interaction pattern · feedback path · user guide · training · support

LOGICAL RELATIONSHIPS

Context informs Instructions and Evaluation.
Instructions guide approved Tools and any necessary Orchestration.
Tools enable bounded read/write actions only when authorized.
Orchestration coordinates steps only when the task triggers that need.
Evaluation tests behavior across the capability.
Governance constrains authority across the capability.
Experience connects users, feedback, and support to the capability.

PROPORTIONATE BY DESIGN

Seven responsibilities do not mean seven new systems.

Each responsibility must be answered, but the answer may be an existing platform capability, a configuration, a short policy, a test set, a human checkpoint, or an explicit exclusion. FDE Delta designs only the depth needed to make the selected business capability usable, testable, and controlled.

01REUSE
Use an approved capability already present in the client environment.
02CONFIGURE
Prefer platform-native configuration before custom building.
03BUILD
Create only the smallest missing component justified by the business task and evidence.
04INTEGRATE
Connect systems only when value, permission, failure, and ownership conditions are explicit.
05EXCLUDE
State unsupported actions, data, users, or environments instead of hiding the gap.

Consider every responsibility. Implement only what the approved capability requires.

PORTABLE CORE · EXPLICIT ADAPTER

Define the business capability first. Then adapt it to the approved AI environment.

A Skill, Workflow, Prompt, MCP server, connector, CLI, automation, or platform configuration is an implementation form, not the business capability itself. Separating the durable capability specification from its platform adapter reduces avoidable lock-in and makes ownership clearer.

BUSINESS AI CAPABILITY SPECIFICATION

BUSINESS CONTEXT PACK

ASSURANCE & GOVERNANCE PACK

APPROVED PLATFORM ADAPTER

Codex
Claude Code
WorkBuddy
private or other approved environment

CLIENT-OWNED BUSINESS AI CAPABILITY

Platform names are examples of possible approved environments, not endorsements, integrations, compatibility claims, or current FDE Delta deployments.

Vendor-neutral does not mean adapter-free. It does not guarantee that one asset will run unchanged, at no cost, or with equivalent behavior across platforms.

WORKFLOW NECESSITY GATE

Not every capability needs a Workflow.

Simple tasks should not be forced into a complex Agent system for technical display. When a capability involves any trigger below, its roles, state, permissions, approvals, recovery, and operating responsibility must be decided before implementation is recommended.

01MULTIPLE ROLES
02PERSISTENT STATE
03REPEATED OR SCHEDULED OPERATION
04EXTERNAL SYSTEM OR DATA CONNECTIONS
05MATERIAL PERMISSIONS
06APPROVAL STEPS
07RETRIES, RECOVERY, OR MONITORING

Any Workflow trigger present?

NO

a direct task, instruction, Skill, or simple configuration may be sufficient

YES

WORKFLOW_DECISION_REQUIRED

define roles, state, permissions, approvals, recovery, monitoring, and ownership

“May be sufficient” is a design option, not an implementation or Skill-creation authorization.

CLAIM & DESIGN STATUS

The diagram explains design responsibilities. It is not evidence that a Harness has been built, integrated, accepted, or operated.

FACT: An accepted description of the generic FDE Delta method or the visible page model.
HYPOTHESIS: Client-specific layer depth, platform fit, value, portability, and operating design until validated.
UNKNOWN: Data, access, permission, authority, user, acceptance, and support conditions until confirmed.
RECOMMENDATION: A bounded next design decision, not a deployment result, approval, or promise.

OUTPUTS

01Business AI Capability Specification
02Capability Harness Architecture
03Target Platform Mapping
04Business Context Pack Design
05Evaluation and Acceptance Plan
06Permission and Human-Control Design
07Failure, Fallback, and Recovery Design
08Portability and Ownership Design

Every output is a design or decision artifact. It is not evidence that an implementation, integration, Skill, Workflow, evaluation, or client capability exists.

GATE 03 / DEFINE THE CAPABILITY PACKAGE?

accepted business-capability specification
minimum necessary Harness decisions
approved platform and data boundary
human control and acceptance authority
evaluation and failure path
Workflow decision when triggered

may enter capability-package definition

A Harness may enter capability-package definition only when the durable business capability, minimum platform implementation, evaluation, authority, failure path, ownership, and exclusions are explicit.

Passing this Gate does not authorize a build, integration, production release, client access, Skill creation, or Workflow activation.

Next chapter: Capability Package ↗

Back to Opportunity Shaping ↖Return to the FDE Delta overview ↖

OPEN A CONVERSATION

Build something worth testing.

For AI-native products, global GTM, or independent projects, choose a channel below.