AEP control plane guide

The ISA Agentic Enablement Platform (AEP) is the governed middle platform above ISA providers and enterprise systems of record. It helps a product team move from a business goal to a releasable app or agent capability without turning AEP into a second source catalog.

Open the AEP operations portal  when you are ready to act. Use this page when you need to understand why each step exists and which system owns the result.

What AEP is — and is not

AEP is a control plane. It owns the consumption context around a capability:

• project and environment context;
• a federated, requestable view of provider-owned capabilities;
• policy decisions, entitlements, approval routing, and obligations;
• app-template compatibility and generation tasks;
• release evidence, audit correlation, and rollback intent.

The source system remains authoritative for its own data, runtime, credentials, and transaction semantics. AEP stores references and evidence, not copied secrets or a replacement ERP/PLM/MES/MDM catalog.

The operating pipeline

The portal is an operating surface, not a catalog brochure. Each step creates context or an artifact that the next step can act on.

Project
  → Catalog
  → Request
  → Policy precheck
  → Approval
  → Provision
  → Template
  → Preview / test
  → Evidence
  → Release / GitOps
  → Audit / rollback / revoke

1. Project — establish operating context

Select or create a project workspace with its owner, role, environment, data classification, and target user group. This context determines what the operator can see and what policy can evaluate.

Start in Operations , then open Projects . A project is the boundary for requests, capability visibility, generated app drafts, and release evidence.

2. Catalog — discover a governed capability

Browse the federated catalog by business purpose, provider, owner, kind, readiness, classification, side-effect level, and environment. AEP shows a thin consumption contract and provider reference; it does not pretend to own the provider’s full technical catalog.

Use the Capability catalog . A capability should make its owner, provider reference, readiness, requestability, and approval path clear before anyone asks for access.

3. Request — state the intended use

Submit the desired capability under the selected project, role, environment, and duration. Include a business justification and acknowledge the data and side-effect obligations returned by policy.

Create a new access request . The request is the durable business object that joins the user’s intent to later approvals, provisioning, and audit evidence.

4. Policy precheck — decide before touching a provider

AEP evaluates the request before a provider is called. The decision is structured as allow, review, or deny, with reasons, obligations, missing prerequisites, approver groups, expiry, and an evidence reference.

Policy is a gate and an explanation, not a hidden error screen. review means the request can proceed after a human decision; deny explains what must change; allow still leaves provider provisioning and release gates intact.

5. Approval — obtain accountable human review

Sensitive data, production environments, and command/write capabilities require the responsible data owner, source-system owner, or platform operator to approve. The approval decision is bound to the request and its capability snapshot, not to an unbounded user session.

Operators review approvals . Approve, reject, request changes, or revoke with an explanation so the next actor can see the decision and its obligations.

6. Provision — record the provider grant

After approval, AEP asks the enabled provider adapter to apply the desired entitlement or records a manual/RPA/MCP handoff. The provider remains the authority for the actual grant. AEP records the provider grant reference, state transitions, retries, and evidence.

Provisioning can be asynchronous or degraded. A request must remain visible as pending, failed, or evidence-pending instead of being presented as successful merely because a button was clicked.

7. Template — assemble an app or agent draft

Choose a compatible template after the project has the required capabilities. The App Factory binds approved capability references and secret references into an auditable generation task. It never writes secret values into generated code or exposes raw source-system endpoints to the draft.

Open Templates  to inspect required capabilities, compatibility, release requirements, and rollback expectations before generating a draft.

8. Preview and test — prove the intended behavior

Run the generated draft in a non-production environment. Check capability bindings, policy obligations, security controls, data handling, side effects, and AI/task evaluations. A blocked or failed task must expose its next action and retain logs and artifact references for recovery.

The preview is where a team proves the app can do the intended job safely; it is not an informal bypass around approval or provider contracts.

9. Evidence — assemble the release record

The evidence bundle joins the request, policy decisions, approvals, provider grant references, generated artifact, tests, evaluation results, GitOps target, rollback plan, and correlation IDs. Audit search must still explain the business action when an external telemetry backend is unavailable.

Review Audit and evidence  before promotion. A release without evidence is an unreviewable change, not a production candidate.

10. Release and GitOps — promote through a controlled target

Create a release proposal, attach the evidence bundle, obtain any remaining production approval, and promote through the deployment/GitOps target. AEP records intent and reconciliation evidence; the GitOps controller owns deployment state and execution.

The release gate must include a rollback or compensation plan, the target environment, the expected health signal, and the owner responsible for reconciliation.

11. Audit, rollback, and revoke — operate after release

After promotion, operators use the same business IDs to search events, correlate traces, renew or revoke access, investigate provisioning failures, and roll back or compensate a release. The lifecycle ends only when the capability and its evidence are no longer needed.

Who does what?

When to leave AEP

Use the provider or platform that owns the authoritative operation when you need to:

• change source metadata, schema, lineage, or quality rules;
• execute a raw transaction or manage provider runtime internals;
• rotate secret material or change identity membership;
• inspect raw logs, traces, metrics, or cluster state;
• change GitOps deployment mechanics or gateway enforcement.

AEP should link you to those systems through ownership and provider references. It should not duplicate their source of truth.

Product and API references

• AEP Architecture notes 
• AEP portal information architecture 
• AEP OpenAPI contract 
• isA platform architecture

If a portal page shows a metric without a corresponding action, return to Operations  and follow the next action in the queue.