Delivery state
Review checkpoints, planned/actual progress, schedule/cost evidence and the current state of connected telemetry rather than relying only on narrative status.
The control loop
Observe
telemetry + evidence→Assess
state + impact→Preview
scenario + trade-offs→Act
authorised intervention→Verify
new evidence
telemetry + evidence→Assess
state + impact→Preview
scenario + trade-offs→Act
authorised intervention→Verify
new evidence
The purpose of AIDE is not to produce more status reporting. It is to shorten the time between a meaningful change in the delivery system and an informed management response.
1. Projects workspace
The Projects workspace is the control room for an individual delivery system. A project combines explicit configuration with measured or imported evidence.
Backlog and throughput
Use work-arrival, completion and throughput measures to understand whether demand is accumulating faster than the team can clear it.
Dependencies
Record upstream/downstream relationships so an issue can be assessed for propagation rather than treated as an isolated project problem.
Resources
Track required/shared resources and allocations so contention can be seen across projects rather than discovered through competing status reports.
Risks and signals
Use risks, tolerances, telemetry freshness and algedonic/attention signals to identify conditions requiring review.
Interventions
Preview authorised actions, understand expected time/cost consequences and record committed interventions so later evidence can show whether the response worked.
2. Programmes workspace
The Programmes workspace is where local project conditions become system-level decisions. It rolls multiple projects into a single dependency, resource, budget, benefit and assurance picture.
Cross-project dependency view
Inspect how a delay or change in one project affects others. The objective is to see propagation early enough to intervene before downstream teams encounter the problem themselves.
Resource contention
Compare shared demand across active projects and identify bottlenecks, over-allocation or sequencing options at programme level.
Programme budget
Use the live roll-up of linked active-project budgets and recognised spend while retaining any explicit programme funding envelope as a separate governance constraint.
Scenario preview
Model declared schedule, delivery-item or project changes and inspect their programme consequences before committing an intervention.
Outcomes and benefits
Track benefits as programme-owned control objects with accountable owners, baselines, targets, evidence gates, project contributions, measurements and acceptance rather than assuming completion automatically creates value.
Assurance
Programme status considers the quality/freshness of contributing evidence as well as declared delivery state. A silent source can therefore reduce confidence in an otherwise green-looking picture.
3. AIDE Blueprint
Blueprint is the architecture and enterprise-design control environment. It is independently licensed from AIDE Chain and can operate as a standalone product.
Business intent
Capture the outcomes, capabilities, requirements and constraints that the architecture must support.
Current-state discovery
Use controlled imports, Azure discovery or CMDB evidence to create immutable observations about the existing estate.
Reconciliation
Architects explicitly accept/reconcile observations before they change the approved architecture baseline. Discovery evidence and design authority remain separate.
Target state
Model future outcomes, capabilities, information, applications, platforms, controls and relationships using deterministic reference rules plus customer-specific design decisions.
Gap and transition analysis
Compare current and target states, identify work packages and transition needs and retain the relationships that explain why the change is required.
Compile to delivery
When Chain is also active, approved Blueprint gaps/work packages can generate native AIDE projects and programmes, preserving architecture-to-delivery traceability.
4. Admin Centre
The Admin Centre is the organisation control surface rather than a delivery dashboard. Owners and Administrators use it to establish the environment in which delivery control operates.
Key functions include organisation profile and branding, member/invitation administration, role and project-access assignment, seat usage, MFA visibility, connector readiness, first-use mobilisation, subscription and billing status, and audit events. Billing-only users can manage commercial functions without receiving delivery access.
5. Evidence and telemetry
Where possible, use source-system evidence rather than manually retyping status. AIDE supports both connected telemetry and explicit manual evidence, but the provenance should remain clear.
Freshness matters
Before acting on a control signal, check whether the evidence is fresh enough for the decision. Fresh, ageing, stale and silent connector states are intended to make data quality part of management judgement.
6. Interventions and authority
An AIDE intervention should answer four questions: What condition triggered attention? What response is being considered? What consequences are expected? What later evidence will show whether it worked?
Where the organisation has pre-approved action types, AIDE can preview their expected time/cost effects before the Controller or other authorised role commits them. The committed intervention is retained in history rather than disappearing into a revised status report.
7. Suggested operating cadence
Continuous / source cadence
Allow connected systems to provide evidence at their natural cadence and watch for stale/silent source conditions.
Project review
Review material changes, attention signals, upcoming checkpoints, resource pressure and open interventions rather than re-reading every field.
Programme review
Focus on propagation: shared resources, dependencies, benefit exposure, evidence gaps and scenarios that require cross-project authority.
Architecture review
Reconcile new discovery evidence, approve material target-state decisions and ensure accepted gaps remain linked to delivery.
Monthly / governance
Review trend evidence, decisions made, realised effects, benefits, stale risks and whether tolerances or authority settings still match the delivery environment.
After intervention
Return specifically to the intervention's expected outcome and determine whether later evidence supports, contradicts or leaves the decision unresolved.
8. Project lifecycle
Projects can be closed without deleting their evidence. Closure preserves checkpoints, reports, interventions, dependencies and audit records, captures final delivery/financial state and releases active resource demand. Closed projects remain useful as historical programme nodes but no longer drive live programme status or allocations. Projects can be reopened through the governed lifecycle when necessary.
9. Reporting and decision evidence
AIDE reporting is intended to describe the current controlled system using the same underlying project/programme evidence visible in the application. The strongest use of reports is therefore as a communication output from the control process, not as a separate manual status-production process.
Correlation IDs, structured logs, audit events, intervention history, source observations and programme benefit evidence together provide a chain of evidence for how a material management decision was reached.
10. What good use looks like
A well-operated AIDE environment should make these questions easier to answer:
What changed? How trustworthy is the evidence? What else does it affect? Who has authority to respond? What response gives the best trade-off? Did the response actually improve the system?
AIDE should reduce reporting work, not create it.
If operating AIDE becomes primarily an exercise in manually reproducing information already held elsewhere, connect or simplify the evidence flow instead. Human effort belongs in interpretation, authority and intervention.