Keep authoritative systems authoritative
Jira, Azure DevOps, Dynamics 365, Power BI, CMDB tools and cloud platforms remain responsible for their native records. AIDE uses bounded evidence from those systems rather than pretending to replace them.
Integration principles
Integrate for decisions, not completeness
The objective is not to ingest every available field. Connect the evidence that changes programme, project or architecture decisions and expand only when additional data improves control.
Test before trust
Connectors are configured and tested before operational use. Where supported, evidence is previewed before import so mapping errors can be found before they affect the control picture.
Preserve provenance
Imported telemetry remains attributable to its source and source timestamps are retained where available. AIDE's control signals sit beside that evidence rather than erasing it.
Make silence visible
An enabled connector with no recent evidence is not considered healthy merely because it has not reported an error. AIDE classifies telemetry freshness so stale or silent sources become attention signals.
Protect customer configuration
Credentials, tokens and connection details are runtime/customer configuration. They are not embedded in public documentation, hard-coded into the application or exposed through public website pages.
Standard connector lifecycle
Configure
approved scope→Test
connectivity + auth→Preview
where supported→Import / refresh
bounded evidence→Review
mapping + freshness
approved scope→Test
connectivity + auth→Preview
where supported→Import / refresh
bounded evidence→Review
mapping + freshness
The exact fields and APIs vary by provider, but the operating principle remains the same: establish a connection, prove it works, inspect what AIDE will use, then allow that evidence into the control model. Connector readiness is surfaced in the Admin Centre so customer administrators can distinguish not configured, configured-but-disabled, credential-missing, ready-to-test and tested states.
Supported delivery and reporting sources
Jira Cloud
Jira can supply project and delivery evidence while remaining the team's execution system of record. AIDE supports connection testing, preview/import patterns and checkpoint/delivery updates based on approved Jira evidence.
Azure DevOps
Azure DevOps supports the same telemetry-first pattern for organisations using Microsoft delivery tooling. Project evidence can be connected without requiring the customer to migrate backlog or work-item management into AIDE.
Dynamics 365 Project Operations
Dynamics 365 can contribute project schedule, cost, resource and dependency evidence where configured. AIDE can map that evidence into the project/programme control picture while D365 remains authoritative for its source records.
Power BI
Where a customer already curates decision-relevant operational measures in Power BI, those measures can contribute to AIDE's evidence model rather than being manually re-keyed into a separate reporting process.
Blueprint discovery sources
Azure Resource Graph
Blueprint can query explicitly approved Azure scopes through the App Service managed identity. The managed identity receives Azure Reader access only at the approved subscription or resource-group scope; no separate Azure client secret is required for this pattern.
CMDB / asset snapshots
Bounded CSV or TSV snapshots can be imported from platforms such as ServiceNow, Ivanti, Jira Assets or controlled spreadsheets. Reusing a stable source key allows Blueprint to identify new, changed, unchanged and missing configuration items across runs.
Continuous CMDB feeds
Authenticated tenant-scoped feeds support create, update, relationship change, retirement, deletion and full-snapshot events. Event IDs support idempotency and stale evidence is retained without overwriting newer state.
Service economics
Where cost, supplier, service and allocation information is provided, Blueprint can roll component costs into business-service views, identify unallocated cost or data-quality gaps and separate identified rationalisation opportunities from validated or realised savings.
Evidence handling and provenance
AIDE is designed to make it possible to answer “why does the control room believe this?” Evidence imported from a connector is therefore kept distinguishable from manually entered project configuration, approved architecture baselines and committed interventions.
For Blueprint, discovery observations are immutable evidence until an architect reconciles them. A discovered Azure resource or CMDB change does not silently become an approved current-state architecture element. This separation allows automated discovery without surrendering architecture governance.
For AIDE Chain, source telemetry informs project state, checkpoint evidence, delivery progress, reporting and freshness signals. Human decisions remain explicit, and committed interventions are retained as decision evidence.
Telemetry freshness
Enabled sources are classified using configurable time thresholds. The standard states are:
Fresh
Evidence has arrived within the expected recent window and can be treated as current for normal control review.
Ageing
Evidence is getting older than expected and should be watched, particularly before making a material decision.
Stale
The source has not supplied evidence within the acceptable window. AIDE raises this as an assurance problem rather than continuing to display the source as healthy.
Silent
The source is enabled but has no delivery evidence. This is treated as a stronger warning because absence of data cannot be interpreted as absence of problems.
No news is worse than bad news.
A bad measurement can be investigated. A silent source can make an apparently green programme picture untrustworthy. Freshness therefore contributes to project and programme assurance rather than being hidden in connector administration.
Credential and access model
Each connector should receive the minimum practical permissions for the agreed customer use case. Customer implementation should document who owns the source system, what scope AIDE is permitted to read, how credentials are rotated and what evidence is expected.
For Azure discovery, managed identity is preferred because the Azure role assignment itself defines the allowed scope. For other connectors, credentials remain protected runtime configuration. Support staff should never ask customers to send passwords, MFA codes, API secrets or private keys through ordinary support messages.
What to integrate first
The best first integration is the one that changes a real control decision. A typical order is:
1. Delivery progress
Connect the source that best represents actual work completion, milestone/checkpoint state or backlog movement.
2. Shared constraints
Add the source that reveals resource, dependency, cost or environment constraints that can propagate between projects.
3. Programme outcomes
Connect measures that demonstrate whether benefits or outcomes are actually being realised rather than assuming delivery completion equals value.
4. Architecture evidence
For Blueprint, connect the current-state evidence that most reduces uncertainty about the existing estate and transition design.
Integration workshop checklist
For each proposed source, agree:
Purpose: Which decision will this evidence improve? Owner: Who controls the source system and can authorise access? Scope: Which projects, boards, queries, subscriptions, resource groups or CI classes are relevant? Fields: Which measures or identifiers are decision-relevant? Cadence: How fresh must the evidence be? Mapping: How will source identifiers map to AIDE projects, programmes, resources or architecture elements? Exception path: Who acts when the connector becomes stale, silent or fails?
Failure and recovery behaviour
A connector failure should not silently erase the last known evidence. AIDE separates connection health/freshness from the underlying previously observed state so reviewers can see both what was last known and whether that evidence is now too old to trust.
Application observability records request correlation and dependency failures so production support can trace an integration problem without exposing credentials in user-facing errors. Customer-specific remediation may involve refreshing credentials, correcting provider scope, re-running a test/preview or intentionally disabling a source that is no longer authoritative.
Expansion pattern
Once the first source is trusted, add further integrations only where they close an evidence gap. AIDE's value is not proportional to the number of APIs connected; it comes from a better, earlier understanding of schedule pressure, resource contention, dependencies, risk, benefits and architecture change.
Implementation principle
Spend customer effort on telemetry that improves the picture. Do not create an integration programme whose only success measure is the number of systems connected.