FDAI Functional Specification
FDAI observes Azure resources within an authorized management scope, identifies operational issues from evidence, and helps operators respond. When an operator explicitly approves an action or grants valid prior authorization, FDAI agents act within that authority, verify the outcome, and retain an audit trail.
This document defines target product functions, not a declaration that every function is implemented or enabled. Resource coverage, supported actions, and operational readiness need separate implementation evidence. The FDAI Constitution and the linked owner documents govern the detailed safety and authority requirements.
What this document covers
Section titled “What this document covers”Use four levels to describe a function: product purpose, function group, subfunction, and detailed function. The hierarchy describes operator outcomes rather than internal agent names. Keep product functions, the common operating flow, and implementation coverage separate.
| View | Question | Contents |
|---|---|---|
| Product function hierarchy | What does FDAI provide? | Numbered function groups, subfunctions, and detailed requirements. |
| Common operating flow | How does a function reach an outcome? | Observation, assessment, planning, authorization, execution, verification, recovery, audit, and improvement. |
| Implementation coverage | What is supported and verified now? | Supported targets and actions, deployment bindings, constraints, and dated code, test, and operational evidence. |
Product purpose
Section titled “Product purpose”Detect operational issues in Azure resources, support timely operator response, and perform automated actions only within explicitly authorized boundaries.
Deploying FDAI into a subscription does not grant blanket visibility or permission to change resources. Coverage depends on configured sources, supported adapters, and access permissions. Operators authorize work; a separate authenticated execution identity performs it. FDAI does not share the operator’s credentials or inherit all of the operator’s permissions.
Function hierarchy
Section titled “Function hierarchy”The following inventory expands the operating domains and shared product capabilities into
testable functions. IDs prefixed with F identify product functions, not workflow stages or
agent roles. Each subfunction can have detailed requirements with separate acceptance criteria.
Readiness describes completion within a declared support scope. It does not describe the connection state of a particular installation or grant automatic execution authority. Local verification and live operational verification remain separate in the assessment evidence.
The 2026-10-18 F10-F15 audit reviewed all 21 subfunctions from F10 onward and corrected ten
Ready decisions to Partial. F01-F09 retain their earlier assessments. Group summaries count
subfunction assessments, not deployment health or percentage complete.
Group summaries omit the Partial badge when its count is zero; individual assessments remain unchanged.
Count reconciliation, 2026-10-19: All 52 individual assessments, 15 group summaries, and
English/Korean decisions were cross-checked at revision
c3a8a26275. The counts below supersede the earlier Ready 38/52 and Partial 14/52 totals.
This recount preserves the recorded decisions; it is not a new functional or deployment qualification.
The 2026-10-23 exact-source acceptance subsequently restored F14.2 to Ready and produced the
current 29/23 totals below.
Overall: Ready 29/52 Partial 23/52 Blocked 0/52 Planned 0/52 Not assessed 0/52
These are product-function counts, not customer production acceptance. The development
full-authority activation remains blocked as recorded in
the deployment evidence;
the failed rollout was rolled back, and no operational learning improvement or realized savings
is established by these counts.
See the dated assessment for support scopes and historical focused
checks, and the complete F10-F15 backlog and execution plan
for source gaps, mandatory operational gates, deferred scope, dependencies, and exit criteria.
This audit does not rerun the historical tests or claim new live operational validation.
See Readiness states for badge meanings, or select a function name for its individual assessment record.
Operational foundation
Section titled “Operational foundation”| Function group | Subfunction | Detailed functions | Readiness |
|---|---|---|---|
| F01. Configure the operating environment Ready 2/3 Partial 1/3 | F01.1 Management scope | Configure the managed subscription and resource-group scope, observation sources, access requirements, and connection readiness. | Ready |
| F01.2 Operating criteria | Define service objectives, thresholds, maintenance windows, notification suppression, and impact limits as governed configuration. | Partial | |
| F01.3 Operational ownership | Assign accountable owners and backup responders, contact routes, and ownership handover requirements. | Ready | |
| F02. Manage resources and relationships Ready 3/3 | F02.1 Resource inventory | Discover resources, collect configuration and ownership facts, and reconcile additions, changes, and deletions. | Ready |
| F02.2 Service and dependency relationships | Relate resources to services and workloads through the operating ontology, the shared model of operational meaning; inspect dependency and impact paths. | Ready | |
| F02.3 Historical state and coverage | Query state and topology at a stated time, retain source and freshness, and distinguish absent resources from unobserved ones. | Ready |
Operating capabilities
Section titled “Operating capabilities”| Function group | Subfunction | Detailed functions | Readiness |
|---|---|---|---|
| F03. Observe, prevent, and forecast Ready 4/4 | F03.1 Operational signals | Collect resource health, metrics, logs, traces, events, and changes through supported sources. | Ready |
| F03.2 Service reliability objectives | Evaluate service-level objectives (SLOs), error budgets, and the rate at which the budget is consumed. | Ready | |
| F03.3 Capacity and performance | Assess utilization, performance trends, capacity pressure, and evidence-backed forecasts. | Ready | |
| F03.4 Detection quality | Detect abnormal states and trends, assess alert noise, and expose missing permissions, stale signals, and incomplete coverage. | Ready | |
| F04. Manage incidents Ready 3/3 | F04.1 Incident lifecycle | Normalize and deduplicate events, correlate incident signals, classify severity, and track acknowledgment, ownership, progress, and closure. | Ready |
| F04.2 Investigation and cause analysis | Gather bounded evidence, assess service impact, and distinguish causal hypotheses from confirmed facts and conflicting evidence. | Ready | |
| F04.3 Response and follow-up | Propose mitigation, track independently verified recovery, retain unresolved outcomes, and prepare post-incident review and follow-up work. | Ready | |
| F05. Govern resilience and recovery Ready 1/3 Partial 2/3 | F05.1 Backup and recovery readiness | Assess backup coverage, recovery-point availability, and restore prerequisites without treating a successful backup as proof of recoverability. | Ready |
| F05.2 Disaster-recovery drills | Plan and authorize restore and failover drills, measure recovery point and time objectives (RPO and RTO), and verify recovery and failback effects. | Partial | |
| F05.3 Chaos experiments | Plan separately authorized fault experiments with bounded impact, continuous stop conditions, and tested recovery. | Partial | |
| F06. Govern changes and architecture Ready 1/3 Partial 2/3 | F06.1 Proposed-change assessment | Inspect proposed infrastructure and configuration changes, evaluate policy and risk, and present pre-change simulation and rollback evidence. | Ready |
| F06.2 Drift and policy compliance | Detect configuration drift and control gaps, retain exceptions and evidence, and propose governed corrections. | Partial | |
| F06.3 Architecture and readiness review | Assemble Architecture Review Board (ARB) evidence, assess architectural constraints, and check ownership and operational readiness before ownership handover or promotion. | Partial | |
| F07. Govern cost Ready 4/4 | F07.1 Cost visibility and allocation | Associate costs and utilization with resources and services, identify allocation gaps, and explain source coverage. | Ready |
| F07.2 Budgets and forecasts | Compare costs with budgets and baselines, detect anomalies, and forecast costs with stated assumptions. | Ready | |
| F07.3 Optimization planning | Recommend resource sizing and cleanup, assess reliability and capacity trade-offs, and route eligible actions through approval and execution. | Ready | |
| F07.4 Realized savings | Verify utilization and cost effects against comparable baseline and treatment periods; distinguish estimated savings from realized savings. | Ready |
Shared automation and operator support
Section titled “Shared automation and operator support”| Function group | Subfunction | Detailed functions | Readiness |
|---|---|---|---|
| F08. Manage actions and workflows Ready 3/4 Partial 1/4 | F08.1 Registered action catalog | Describe supported actions and workflows, parameters, prerequisites, risk limits, and recovery contracts. | Ready |
| F08.2 Response planning | Compose multi-step plans, compare alternatives and objective conflicts, and validate exact targets, expected effects, and stop conditions. | Ready | |
| F08.3 Triggers and schedules | Support governed operator, event, and scheduled initiation; track occurrences and execution history and isolate scheduled tasks within declared limits. | Ready | |
| F08.4 Execution and recovery | Dispatch authorized work once, track progress, stop at defined boundaries, and apply approved rollback or bounded recovery. | Partial | |
| F09. Support operator investigation and collaboration Ready 4/4 | F09.1 Evidence-backed conversations | Answer scoped questions about resources, incidents, plans, and FDAI behavior through supported Web Console, CLI, and ChatOps interfaces with citations and explicit uncertainty. | Ready |
| F09.2 Background investigations | Track durable long-running investigations, progress, cancellation, queued input, and resumable results without treating conversation state as execution authority. | Ready | |
| F09.3 Notifications and escalation | Route alerts and approval requests, track per-channel delivery and acknowledgment, apply declared fallback routes, and escalate without interpreting silence as consent. | Ready | |
| F09.4 Continuity and ownership handover | Preserve authorized conversation context, verified channel identity links, responder assignments, and explicit ownership handover. | Ready | |
| F10. Manage operating knowledge and rules Ready 0/4 Partial 4/4 | F10.1 Document and attachment intake | Ingest supported manuals, documents, and evidence attachments with access checks, extraction limits, retention, and deletion controls. | Partial |
| F10.2 Knowledge retrieval and freshness | Retrieve operational knowledge and past cases with source, version, scope, collection time, and freshness; explain missing or conflicting knowledge. | Partial | |
| F10.3 Rule governance | Author and scope rules, manage versions, enablement and exceptions, and review proposed additions, revisions, or retirement. | Partial | |
| F10.4 Governed knowledge compilation | Propose rules, workflows, and ontology facts from reviewed documents; validate provenance and semantics before separate approval and activation. | Partial | |
| F11. Evaluate, learn, and promote Ready 0/3 Partial 3/3 | F11.1 Operational feedback | Capture operator feedback and immutable incident and action outcomes as attributed learning candidates. | Partial |
| F11.2 Evaluation and replay | Evaluate detection, reasoning, plans, and recovery through scenario tests, historical replay, and comparable measured outcomes. | Partial | |
| F11.3 Capability promotion and recall | Evaluate capabilities in observation mode, govern activation and promotion, and demote or recall regressions without letting learned output grant authority. | Partial | |
| F12. Govern authority, evidence, and service health Ready 0/4 Partial 4/4 | F12.1 Identity and approval | Manage roles, exact-action approvals, conditional prior authorization, approval profiles, expiration, and revocation with separate approval and execution identities. | Partial |
| F12.2 Policy and safety | Apply versioned policies, risk limits, emergency-stop controls, and all required execution safeguards. | Partial | |
| F12.3 Audit and data governance | Preserve attributable decisions and effect records, support replay, and enforce data access, retention, privacy, and evidence-export boundaries. | Partial | |
| F12.4 FDAI health and recovery | Monitor required services, models, source and delivery connections, durable state, and audit dependencies; expose degraded operation and control-plane recovery needs. | Partial |
Supporting product capabilities
Section titled “Supporting product capabilities”| Function group | Subfunction | Detailed functions | Readiness |
|---|---|---|---|
| F13. Present operational evidence and reports Ready 1/3 Partial 2/3 | F13.1 Operational views | Present resources, relationships, incidents, work, approvals, history, and source-qualified outcomes through authorized read views. | Ready |
| F13.2 Reports and export | Render catalog-defined reports and supported exports with source, scope, time, and partial-source failures; reports do not execute actions. | Partial | |
| F13.3 Outcome measurement | Measure reliability, recovery, automation, and cost outcomes against declared baselines instead of claiming improvement from activity counts alone. | Partial | |
| F14. Install, configure, and extend FDAI Ready 1/4 Partial 3/4 | F14.1 Installation and onboarding | Establish installation scope and identity, check prerequisites, configure real source bindings, and verify startup readiness. | Partial |
| F14.2 Updates and distribution | Cover source deployment and signed offline packages; distinguish the designed, not implemented, Hub-managed lifecycle from available installation paths. | Ready | |
| F14.3 Capability settings | Expose availability, enablement, mode, prerequisites, licensing limits, and model health without treating enablement or entitlement as action authority. | Partial | |
| F14.4 Trusted extensions and integrations | Govern versioned capability bundles, skills, provider adapters, and Model Context Protocol (MCP) tools through publisher trust, compatibility checks, scoped access, activation, and revocation. | Partial | |
| F15. Assess code security Ready 2/3 Partial 1/3 | F15.1 Governed scan and detected-issue intake | Acquire authorized exact-revision code for isolated scanning or ingest supported external detected security issues while reporting scan coverage and limits. | Partial |
| F15.2 Detected issues and prioritization | Consolidate detected issues by root cause, separate severity from confidence and priority, and record verification and false-positive review. | Ready | |
| F15.3 Developer fix support | Produce evidence-backed fix packs for developer-run coding sessions and verify returned fix claims by rescan; this path does not edit customer repositories. | Ready |
Readiness states
Section titled “Readiness states”| State | Assessment rule |
|---|---|
| Ready | Implementation and required verification are complete for the declared scope, with current evidence and no remaining mandatory condition. |
| Partial | Some required implementation or verification remains incomplete; record the supported subset and the remaining work. |
| Blocked | A required condition prevents use in the assessed environment; record that environment’s scope, the blocker, and recovery conditions. |
| Planned | Design exists but no executable implementation exists for the assessed scope. |
| Not assessed | Evidence has not been reviewed or no longer supports a current assessment. This is neither Ready nor evidence of missing implementation. |
Only product subfunctions receive readiness states. The common flow below is a process model, not a second status inventory. Rollups retain each state’s count instead of marking a group Ready when only some children are Ready. Update the row, group summary, and overall counts together after an evidence review; changes in scope or source revision require revalidation.
Do not mark a function Ready while its owner retains mandatory implementation, integration, or operational acceptance work. Calling that work installation qualification does not close it. Record local implementation, required operational gates, and explicitly deferred expansion separately, as in the F10-F15 audit and plan.
Readiness assessment
Section titled “Readiness assessment”The function readiness assessment records a decision, support scope, source evidence, and remaining conditions for every product subfunction. Badge meanings are explained under Readiness states; function names link to their individual evidence records. An unassessed function uses the same legend instead of an empty evidence record. Use the following fields when updating an assessment.
| Assessment field | Required information |
|---|---|
| Function, state, and assessment basis | Stable function ID, assessed state, accountable reviewer, source or release revision, and assessment date. |
| Support scope | Supported resources, actions, interfaces, exclusions, and the acceptance criteria being assessed. |
| Verification evidence | Code and test references and dated observations, with local, live operational, and production-readiness results distinguished. |
| Use conditions | Required source bindings, permissions, channels, configuration, capability mode, and the scope of any environment-specific assessment. |
| Remaining work and reassessment | Observable unmet conditions, the work required to reach Ready, and revision or freshness changes that invalidate the assessment. |
Common operating flow
Section titled “Common operating flow”The original five groups below describe the reusable processing flow, not the complete product
inventory. Their numeric references are retained for continuity and are distinct from F IDs.
Every applicable product function uses this flow and the common controls; a read-only function
does not acquire mutation authority by reaching a planning stage.
| Function group | Subfunction | Detailed functions |
|---|---|---|
| 1. Observe operational state | 1.1 Discover managed resources | Discover resources, collect configuration, and identify dependencies within the authorized scope. |
| 1.2 Collect operational signals | Collect supported resource states, metrics, logs, and events with source and time information. | |
| 1.3 Detect changes | Detect resource creation, updates, deletion, configuration changes, and deployment changes. | |
| 1.4 Track observation quality | Identify collection gaps, missing permissions, stale data, and incomplete coverage. | |
| 2. Assess anomalies and incidents | 2.1 Detect anomalies | Detect policy violations, abnormal states, and concerning trends against configured operating criteria. |
| 2.2 Investigate incidents | Correlate related events, assess affected resources, and identify possible causes. | |
| 2.3 Explain assessments | Classify severity, cite evidence, separate facts from hypotheses, and report unknown or conflicting results. | |
| 3. Support operator response | 3.1 Notify and escalate | Notify responsible responders, track delivery and acknowledgment, and escalate according to policy. |
| 3.2 Support investigation | Answer authorized questions about state, change history, incident evidence, and action progress. | |
| 3.3 Propose response plans | Present actions, expected effects, risks, impact scope, stop conditions, and recovery plans. | |
| 4. Perform authorized actions | 4.1 Manage action authority | Manage per-action approval, conditional prior authorization, expiration, and revocation. |
| 4.2 Validate before execution | Check current authority, policy, target identity and revision, impact limits, and required safeguards. | |
| 4.3 Execute registered actions | Execute supported registered actions, track progress, and prevent duplicate changes. | |
| 5. Verify outcomes and recover | 5.1 Verify expected effects | Use independent authoritative observations to check whether the intended effect occurred. |
| 5.2 Handle failure | Apply stop conditions and authorized rollback or bounded recovery; escalate when recovery cannot proceed. | |
| 5.3 Report outcomes | Distinguish verified success, failure, and unresolved outcomes, notify operators, and connect follow-up work. |
Example: a resource health event arrives, related telemetry supports an incident assessment, and the operator receives an evidence-backed response plan. An approved action passes the execution checks, runs through the execution identity, and is reported as successful only after an independent observer confirms the expected effect.
Audit and evidence retention span all five groups. Verified outcomes and operator feedback then feed F10 and F11 as candidates for reviewed knowledge and rule improvements, not as automatic permission to change policy or execute another action.
Common controls
Section titled “Common controls”These controls apply to the whole hierarchy rather than forming additional workflow stages.
| Control | Functional requirements |
|---|---|
| Management scope and access | Define the managed subscription and resource-group scope, user roles, execution identity, and minimum permissions. Keep unauthorized and unobserved resources visible as coverage limitations. |
| Evidence and decisions | Preserve source, provenance, time, freshness, and completeness. Prefer deterministic rules for repeatable decisions and use bounded, evidence-checked reasoning for unresolved ambiguity. Missing evidence remains unknown rather than healthy. |
| Policy and execution safety | Apply risk and approval policies. Every autonomous state change needs a stop condition, tested rollback or bounded recovery, an impact limit, successful dry-run or an explicitly permitted equivalent, a logical-target lock, duplicate prevention, and audit records before and after the effect. |
| Capability lifecycle | Separate availability, enablement, and execution authority. New capabilities start in observation mode, where they assess and record without applying the proposed changes; changing mode follows the governed promotion process. |
| Audit and traceability | Link observations, decisions, notifications, approvals, execution, verification, and recovery. Retain the identities, versions, timestamps, and evidence needed to reconstruct each outcome. |
| FDAI service health | Expose collection and notification failures and required-component availability. Missing safety dependencies block affected changes instead of silently bypassing a control. |
Authority boundaries
Section titled “Authority boundaries”Read access and change authority are separate. An action is eligible only when current policy, risk, identity, approval, capability mode, and safety checks all permit it.
| Situation | Expected behavior |
|---|---|
| Authorized observation or investigation | Read and explain within the allowed scope; no resource change is implied. |
| Explicit approval for one action | Execute only the approved action against its approved target, revision, and scope while the approval remains valid. |
| Valid prior authorization | Execute only when the declared trigger, action, scope, validity period, and applicable risk conditions are satisfied. |
| Missing, expired, revoked, or mismatched authority | Do not start the action. Request the required approval, hold for review, or deny it with an audit record. |
An unanswered notification, a natural-language request, or a broad role assignment alone does not authorize a specific change. Revocation blocks new execution under that authorization; work already in progress follows its defined stop and recovery policy. Irreversible production actions require current approval for each execution rather than prior standing authorization.
For the detailed approval profiles and emergency limits, see Risk tiers and Escalation and Standing Authority.
Operating domains
Section titled “Operating domains”SRE is the overall operating model. F03-F07 expand the four operating domains below into product functions, while the shared capabilities support every domain. Reporting and code-security analysis are supporting capabilities, not additional constitutional domains. Listing a domain does not prove complete implementation coverage.
| Domain | Application of the common flow |
|---|---|
| SRE operations | Observe availability and performance, assess incidents and service objectives, and verify recovery. SRE is the overall operating model. |
| Resilience | Assess backup and recovery readiness and govern disaster-recovery drills, restore, failover, and separately authorized Chaos experiments. |
| Change safety | Assess proposed changes, configuration drift, policy compliance, and architecture constraints before and after a change. |
| Cost governance | Observe costs and utilization, detect anomalies, propose optimization, and verify the effects of approved changes. |
Coverage and owner references
Section titled “Coverage and owner references”This inventory was compared with the roadmap index, the SRE capability map, productization designs, and the reporting and code-security owner documents. These references support scope, not a claim of exhaustive code review, live validation, or runtime readiness. Detailed contracts and current implementation status stay with their owners.
Detailed function records
Section titled “Detailed function records”Give each detailed function an ID beneath its subfunction. Keep the ID stable when wording changes, and use it to connect acceptance tests and implementation evidence without mixing target requirements with delivery status.
The following example expands product subfunction F12.1 into one testable requirement. The
original draft ID 4.1.3 remains an alias to preserve references to approval revocation.
| Field | Example |
|---|---|
| Function ID | F12.1.3 |
| Previous draft ID | 4.1.3 |
| Readiness | Illustrative requirement; its parent F12.1 is assessed Partial until the full requirement and operational evidence close. The criteria below are not a separate verification receipt. |
| Function name | Revoke action approval |
| Actor and trigger | An authorized operator revokes an existing approval. |
| Preconditions | The operator can revoke that approval and identifies its exact revision. |
| Expected behavior | Block new execution using the revoked approval. Handle in-progress work through its defined stop and recovery policy. |
| Acceptance criteria | A new dispatch under the revoked approval is blocked; in-progress work has an explicit recorded outcome; the audit identifies the operator, approval revision, time, and affected actions. |
| Exception behavior | An unauthorized request is denied. Failure to establish current authority holds affected new execution for review. |
In a separate implementation record, connect each function ID to its status, supported resource and action types, constraints, code and test references, and dated verification evidence. Implementation, local verification, live operational verification, and production readiness are different claims; none follows from the presence of this specification alone.
Record those claims separately rather than reducing them to a single complete/incomplete flag. The dated assessment supplies the current decisions; future changes require renewed evidence, and unsupported claims return to Not assessed rather than inheriting an earlier Ready label.
| Coverage field | Required information |
|---|---|
| Function and implementation | Stable function ID, owner, and separately evidenced design-only, partial, or implemented scope. |
| Supported scope | Resource and action types, interfaces, known exclusions, and deployment prerequisites. |
| Bindings and authority | Real source and channel bindings, effective scope, capability mode, and approval requirements. |
| Verification | Separate local test results, live operational observations, and promotion or production-readiness evidence. |
| Traceability | Exact source or release revision, test references, observation time, evidence provenance, and remaining work. |
Related docs
Section titled “Related docs”| To learn about | Read |
|---|---|
| Initial setup and the operator journey | Get started |
| Component responsibilities | FDAI Architecture |
| Observation before enabling changes | Observe, then enable changes |
| Approval and notification surfaces | Approvals and channels |
| Function-by-function decisions and remaining conditions | Function readiness assessment |
| Complete F10-F15 remaining work and dependency order | Readiness audit and completion plan |
| Product safety and authority requirements | FDAI Constitution |