SOLUTION ARCHITECTURE · UPDATED AUGUST 2026
AIDE separates the systems where delivery work is performed from the system used to understand and control that delivery. Existing project, programme, reporting and architecture tools remain authoritative for their native data. AIDE consumes approved evidence, creates a cross-project control picture, and records the interventions and decisions made in response.
AIDE is not intended to become another task-management tool. Jira, Azure DevOps, Dynamics 365, Power BI, CMDB platforms and other customer systems can remain in place while AIDE supplies project, programme and architecture control above them.
The browser interface is not the security boundary. Authentication, active organisation membership, subscription entitlement, tenant ownership, project grants and role capabilities are checked server-side before protected operations execute.
AIDE preserves source evidence and explicit customer configuration. Delivery state, architecture observations, benefits and interventions are traceable to declared data rather than silently rewriting source systems.
AIDE Chain and AIDE Blueprint share the platform control plane but are independently licensed and independently entitlement-gated. A customer may operate either product alone or both together.
In production, operational product routes remain locked until the relevant product entitlement is active or trialling. Billing and account-security functions remain available so the customer can activate or restore access.
Customers can begin with one or two high-value telemetry sources, establish a trustworthy control picture, and expand coverage over time without re-platforming the delivery organisation.
Azure Database for PostgreSQL Flexible Server stores identity, organisation tenancy, memberships, invitations, project and programme control state, Blueprint records, entitlement state, audit evidence and other transactional records.
Azure Blob Storage stores generated reports, exports, evidence files and organisation branding. Objects remain private and are resolved only after the application authorises the requesting organisation and resource.
Structured application logs, correlation IDs, health endpoints and OpenTelemetry traces flow to Azure Monitor Application Insights and its Log Analytics workspace for support and production monitoring.
Approved customer connectors provide bounded telemetry from delivery, reporting, architecture and asset systems. AIDE retains source context and uses that evidence in the control model.
Stripe supports direct SaaS subscriptions. Microsoft Marketplace fulfilment supports marketplace-origin subscriptions, lifecycle events and organisation claiming. The entitlement layer separates the payment source from the product-access decision.
GitHub Actions runs automated tests before deployment and verifies application health and deployed release identity after deployment. Production configuration and secrets remain outside source code.
The web application is implemented in Python and Flask and served through Waitress on Azure App Service for Linux. One authenticated control plane supplies account, organisation, role, billing and administrative functions to both AIDE products.
Provides project and programme control: checkpoints, telemetry, schedule and cost evidence, dependencies, shared resources, risks, control signals, scenario previews, interventions, reporting, project lifecycle, programme outcomes and benefits.
Provides deterministic enterprise-design and assurance functions: discovery, current-state evidence, target-state modelling, architecture relationships, gap analysis, CMDB/service economics, verification and architecture-to-delivery compilation.
Provides organisation profile, member and invitation administration, role assignment, branding, MFA status, connector readiness, subscription/billing state, first-use mobilisation guidance and audit visibility.
Project and programme services operate over organisation-scoped repositories and server-side authorisation. Programme-wide operations validate ownership of linked projects and resources rather than trusting browser-supplied identifiers.
AIDE currently provides application-native identity with password authentication, TOTP authenticator MFA, recovery codes and time-limited password recovery. Password-reset and invitation flows use time-limited or one-time tokens; invitation tokens are stored as hashes rather than reusable plaintext credentials.
Authenticate session → validate CSRF for state-changing operations → confirm active organisation membership → confirm product entitlement → resolve the requested organisation/project/programme → verify tenant ownership and project grant → verify role capability → execute the operation and retain audit evidence.
Full read, reporting, control, administration and billing capabilities, including Owner-only functions such as privileged role management and controlled demonstration reset.
Organisation administration plus project/programme control, without Owner-only or billing authority.
Organisation-wide project/programme control where the member has the required portfolio scope, without tenant administration.
progressively narrower reporting and read-only access for users who should not alter control configuration.
Commercial administration without project or programme access, allowing finance/procurement users to manage subscriptions without receiving delivery data access.
Where required, a member may be limited to selected projects. Requests for resources outside the member's tenant or grant return a generic not-found response rather than disclosing existence.
The organisation is the primary tenant boundary. Membership, project/programme ownership, resources, architecture records, billing state and private artefacts are associated with that organisation. Cross-tenant requests are rejected before the underlying resource is returned.
For additional concealment, requests for another organisation's project, programme, report, export, connector or referenced resource return a generic 404 response. The same behaviour applies when a selected-project member attempts to enumerate an ungranted project.
Blob objects remain private. Application routes authorise the project or programme before resolving the organisation-scoped object path. Customer-specific credentials and connection information remain runtime configuration and are not placed in public documentation or committed source code.
AIDE deliberately separates commercial billing from application authorisation. The product-access decision is based on the organisation's current entitlement state, not on whether a payment was collected by a particular provider.
Stripe Checkout creates the subscription and signed Stripe webhooks update the organisation's commercial state. Billing Portal is used for later subscription management where applicable.
Marketplace purchase tokens are resolved server-to-server. The buyer authenticates with Microsoft, purchaser/beneficiary identity is validated, the subscription is claimed into an AIDE organisation and lifecycle webhooks keep plan, quantity and status aligned.
AIDE Chain and Blueprint are checked independently. A Chain-only organisation cannot open Blueprint; a Blueprint-only organisation can operate Blueprint without being granted project/programme access.
The model supports one product being marketplace-billed and another being Stripe-billed. For example, Chain may be purchased through Microsoft Marketplace while Blueprint is purchased directly.
In production, an unpaid organisation can authenticate only far enough to secure the account, select/activate products, manage eligible billing operations and switch to another organisation to which the user already has access. It cannot create delivery data or invite a free team around the paywall.
AIDE's core design assumption is that delivery state should be measured from evidence wherever practical. Supported connectors can be tested, and where implemented previewed, before evidence is imported into the control picture. Imported evidence remains attributable to its source.
Enabled telemetry sources are also assessed for freshness. AIDE distinguishes fresh, ageing, stale and silent sources so the absence of evidence is not mistaken for healthy delivery. This is the operational principle behind “no news is worse than bad news.”
Once evidence is available, AIDE combines it with explicitly configured project and programme relationships, tolerances, resources, risks, outcomes and benefits. Control signals and scenario previews are then used to support a human decision; committed interventions are recorded as auditable actions rather than silently mutating external systems.
Blueprint uses a governed observation-and-reconciliation pattern. Discovery evidence does not silently become an approved architecture baseline.
Where configured, the App Service managed identity receives Azure Reader access only to approved subscriptions or resource groups and queries Azure Resource Graph without storing an Azure client secret.
Bounded CSV/TSV snapshots from systems such as ServiceNow, Ivanti, Jira Assets or controlled spreadsheets can be compared as immutable discovery runs.
Tenant-scoped authenticated event feeds support create, update, relationship-change, retirement, deletion and full-snapshot events, with idempotency, stale-event handling and reconciliation evidence.
When Blueprint and Chain are both active, approved gaps and work packages can compile into native AIDE Chain projects/programmes while preserving the architecture evidence that justified the work.
AIDE operates two persistent stores and tests recovery for both rather than treating configured backup as sufficient evidence.
Azure point-in-time recovery is configured with a 14-day recovery window. The planning objective is an RPO of 15 minutes and an RTO of two hours. Recovery drills restore to a separate PostgreSQL server and validate schema revision, diagnostic marker state and key table counts before any cutover is considered.
Blob versioning and 30-day soft-delete protection are used for artefacts. Recovery drills create isolated diagnostic objects, overwrite/delete them, restore a known-good version and verify checksums without touching customer artefacts.
These recovery objectives are operating targets rather than contractual service levels. Actual drill outcomes are captured as evidence and used to improve the recovery model.
Every HTTP request receives a new correlation ID. That ID is attached to request lifecycle logs and tracing and is returned to the browser; unexpected error pages expose a shortened support reference so an incident can be traced without exposing stack details to the user.
Health endpoints distinguish process liveness from dependency readiness. Production monitoring covers the application, PostgreSQL and artefact store and can alert on readiness failure, repeated server errors and dependency failures. Sensitive values such as passwords, tokens, cookies, connection strings and database URLs are excluded or redacted from structured telemetry.
Application changes move through GitHub pull requests and automated tests before deployment. The deployment pipeline verifies the running application after release, including health and expected release identity. Database schema evolution is controlled through Alembic migrations and privileged migration procedures rather than granting the normal runtime account broad schema-creation rights.
Secrets and production Price IDs are environment configuration, not repository content. Customer-specific connector credentials follow the same principle.
This public architecture describes the standard managed SaaS baseline. It does not assert that a customer's Authority to Operate, IRAP assessment or other organisation-specific certification has been completed. AIDE can supply architecture, data-flow, control, deployment, recovery and test evidence to support the customer's assessment process.
Where a customer risk profile requires additional controls, separately scoped uplifts can include WAF/reverse-proxy controls, Key Vault/managed-identity improvements, private connectivity, SIEM/SOC integration, dedicated environments, enhanced retention, external identity-provider integration, penetration testing and formal assurance activity.
The platform is designed so onboarding and access are routine. Customer effort should be concentrated on the higher-value problem: choosing reliable telemetry, modelling the delivery system and deciding how control signals will be governed.
Read the customer onboarding process Explore integrations & telemetry
