SOLUTION ARCHITECTURE · UPDATED SEPTEMBER 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.
A visual summary of the managed Azure platform, isolated environments, application and data services, integration boundaries, DevSecOps release path and current security posture.
This diagram reflects the current hardened pattern: managed identities, private PostgreSQL networking, tenant isolation with RLS policies, Key Vault-backed core secrets, signed inbound webhooks, immutable release artefacts and OIDC deployment for staging and showcase. Remaining secret coverage and deployment identities continue to migrate incrementally.
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 never treated as the security boundary. Authentication, session state, active organisation membership, subscription entitlement, tenant ownership, project grants and role capabilities are verified 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.
Paid access, automated telemetry and connector trust boundaries fail closed where required information is missing, conflicting or unauthorised. Security decisions are made from explicit identity, tenancy, entitlement and source state rather than assumptions.
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. Tenant-data tables also carry PostgreSQL row-level-security policies as an additional isolation mechanism.
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. Credential-bearing HTTP integrations use destination validation, redirect rejection and bounded response handling where implemented.
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 application, PostgreSQL and security checks before release. Dependency auditing, static analysis, secret scanning and reproducible SBOM generation form part of the release gate, and promotion verifies the exact published artefact and deployed application health.
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. Public authentication and inbound-integration POST surfaces also have application-level rate limits, with shared counters in PostgreSQL deployments.
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.
PostgreSQL row-level-security policies are installed and regression-tested across protected delivery, Blueprint and Mission tenant data. The application carries the active organisation into database transactions and the policies use both visibility and mutation checks. The production defence-in-depth objective is to run these policies under a non-owner runtime database identity; until that cutover is completed, server-side application authorisation remains the primary production tenant boundary.
Deployment environments are separate Azure resource stamps and customer artefacts remain private. Secrets, connector credentials and production configuration are not committed to the public website or application source. The hardened managed pattern uses private PostgreSQL networking and environment-scoped managed identities; customer-specific network controls remain deployment-specific.
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.
AIDE prefers outbound pull integrations and treats external telemetry as untrusted control input until source, scope and quality checks succeed.
SAP telemetry is read-only and outbound-only. HTTPS is required, redirects are rejected, destinations are constrained, response sizes and timeouts are bounded, credential namespaces are restricted, and upstream error bodies are not reflected into AIDE.
Dynamics 365 and Microsoft Marketplace credential-bearing requests use the shared hardened transport. Dynamics 365 is constrained to approved Dynamics HTTPS origins and validated continuation URLs; Marketplace calls use fixed Microsoft identity and Marketplace API hosts.
Automated polling runs with explicit organisation/project scope, locking and durable idempotency. Missing or conflicting enabled sources fail closed by default, provenance is retained, and the poller does not write back to connected systems.
Optional customer-system inbound connectors are disabled by default in production. Commercial webhooks require protocol credentials and adapter-level verification, while public POST surfaces are protected by application rate limits.
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 the canonical AIDE CI workflow. Tests exercise the application and PostgreSQL boundary, while the security job performs dependency auditing, Bandit static analysis, reviewed-exception drift detection, reproducible CycloneDX SBOM generation and repository-history secret scanning.
Release packaging repeats the relevant quality and security gates, publishes an immutable release ZIP plus SBOM, and produces SHA-256 integrity evidence. Promotion deploys the exact published release and verifies health and expected version rather than rebuilding arbitrary source at deployment time. Database schema evolution is controlled through Alembic migrations.
Secrets and production Price IDs remain environment configuration rather than repository content. Key Vault-backed references now protect core staging secrets, with remaining sensitive values being migrated in stages. GitHub-to-Azure OIDC deployment is active for staging and showcase, removing their long-lived publish-profile credentials; other managed environments are being migrated incrementally.
Production responses use secure/HttpOnly/SameSite session cookies, HSTS on secure deployments, no-sniff, deny framing, a restrictive referrer policy and a browser permissions policy. A minimal Content Security Policy is enforced and a stricter policy is currently emitted in report-only mode while compatibility is assessed before enforcement. Request payloads are bounded and public authentication/integration POST traffic is rate limited independently of account lockout.
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. It also does not claim that AIDE Chain is currently certified to ISO/IEC 27001 or covered by a SOC 2 Type II report.
AIDE can supply architecture, data-flow, access-control, deployment, recovery, monitoring, secure-development and test evidence to support customer assurance. A formal ISO/IEC 27001 certification requires an operating information security management system and an independent accredited certification audit; a SOC 2 Type II report requires an independent service-auditor examination of controls operating across a defined period.
Where a customer risk profile requires additional controls, separately scoped uplifts can include WAF/reverse-proxy controls, expansion of Key Vault coverage, customer-specific private connectivity, SIEM/SOC integration, dedicated environments, enhanced retention, external identity-provider integration, penetration testing and formal assurance activity.
AIDE's technical controls already generate useful evidence for an ISO/IEC 27001 ISMS and a SOC 2 examination. The remaining work includes formalising organisational policies, risk and control ownership, recurring access/supplier/incident/continuity processes, evidence retention and the external audit/attestation itself. See the Assurance Readiness page for the current control and evidence plan.
