isA AEPEnterprise portal
Solara Commerce demo
AEP ownsMiddle-platform orchestration

Workspaces, catalog facade, policy gates, app generation, evidence, and release control.

ISA ownsAuthoritative capability providers

Data, MCP tools, agents, cloud routing, identity, secrets, and enterprise SOR adapters.

Citizens useOne governed golden path

Start with project context, request approved capabilities, generate, preview, and release.

AEP middle platform

Platform modules needed

Each module owns a distinct operational responsibility across discovery, governance, generation, and release.

01

Portal / Workspace

Single operating surface for projects, environments, requests, previews, and release evidence.

Project contextVisible scope
02

Capability Catalog

Federated view of provider-owned API, data product, MCP tool, workflow, agent, and template contracts.

Provider refsReadiness
03

Policy / Entitlement

Decision layer for project visibility, sn_iam groups, data classification, side effects, and approvals.

Access gatesApproval policy
04

App Factory

Scaffolds enterprise apps from templates, binds approved capabilities, and produces preview builds.

Template bindingPreview build
05

Tool Gateway

Governed invocation layer for MCP tools and APIs so generated apps and agents never call SORs directly.

Tool routingInvocation policy
06

Evidence / Audit

Captures who requested, approved, generated, invoked, promoted, and changed each capability-backed app.

Evidence bundleTrace log
07

Provider Connectors

Syncs contracts and runtime metadata from ISA platforms while leaving ownership with each provider.

Contract syncHealth state
08

Release / GitOps

Promotes generated apps through pull request, approval, deployment, reconciliation, and rollback.

Promotion gateRollback

ISA integration

Provider owners and retained authority

AEP consumes contracts and runtime state; the ISA owner remains accountable for the authoritative platform.

isA_Data / Dataphin

AEP consumes
Data products, read models, lineage, quality state, and governed consumption metadata.
Owner keeps
Data truth, schema governance, quality rules, and data-platform operations.

isA_MCP

AEP consumes
Tool registry, schemas, runtime health, input constraints, and policy metadata for tool use.
Owner keeps
Tool implementation, server lifecycle, versioning, and tool-specific observability.

isA_Agent

AEP consumes
Agent profiles, orchestration policies, evaluation telemetry, and approved invocation plans.
Owner keeps
Agent runtime behavior, model strategy, prompt assets, and orchestration quality.

isA_Cloud / APISIX

AEP consumes
Gateway routes, traffic policy, service discovery, platform health, and release target status.
Owner keeps
Cluster operations, ingress enforcement, service routing, and runtime observability.

sn_iam / Vault / ESO

AEP consumes
Identity groups, entitlement claims, secret references, and environment-scoped credential bindings.
Owner keeps
Identity lifecycle, secret material, rotation, and enterprise access controls.

Enterprise SOR adapters

AEP consumes
ERP, PLM, MES, SRM, finance, commerce, and MDM adapters exposed as governed capabilities.
Owner keeps
Transaction semantics, source approvals, compensation, reconciliation, and ownership SLAs.

Citizen developer path

From project context to governed release

The user experience stays linear while policy, approvals, provider checks, app tasks, and GitOps evidence run underneath. Entitlement and app-task lifecycles remain linked but distinct.

  1. 1

    Project

    Citizen developer chooses a project, domain, environment, data class, and target user group.

    Workspace profile
  2. 2

    Catalog

    AEP filters provider-owned capabilities to the project-visible API, data, tool, and template set.

    Scoped catalog view
  3. 3

    Request

    Access requests route through policy checks, owner approvals, and side-effect review when needed.

    Approved capability grant
  4. 4

    Policy precheck

    A structured allow, review, or deny decision explains reasons, obligations, missing prerequisites, and approvers before a provider is called.

    Decision envelope
  5. 5

    Approval

    Data owners, source-system owners, and platform operators review sensitive data, production, and command/write paths.

    Accountable decision
  6. 6

    Provision

    An enabled provider adapter applies the entitlement or records a manual handoff while AEP tracks state and evidence.

    Provider grant ref
  7. 7

    Template

    App Factory binds approved capabilities and secret references into an enterprise app blueprint.

    Generated draft app
  8. 8

    Preview / test

    The draft proves capability bindings, policy obligations, security controls, data handling, and task evaluations in a non-production environment.

    Preview result
  9. 9

    Evidence

    Requests, decisions, approvals, grants, artifacts, tests, release targets, rollback plans, and correlation IDs form one release record.

    Evidence bundle
  10. 10

    Release / GitOps

    A proposal moves through production approval and a deployment target; GitOps owns execution while AEP records intent and reconciliation.

    Promotion intent
  11. 11

    Audit / rollback / revoke

    Operators correlate events, investigate failures, renew or revoke access, and roll back or compensate a release after promotion.

    Operational history