Asgard governance, stages 0 to 7

One pool, one lane per role. Dashed groups wrap forms that more than one role completes. Click a step to see its notes under Properties and its mockup under Form; Submit on a form moves to the next step. Questions for Shane sit in Properties; click one to jump to the part of the diagram it concerns.

STAGE 0 Risk AssessmentGate: Is the opportunity agentic, appropriately risk-tiered and ready to enter governance?

STAGE 1 Plan and DesignGate: What business outcome are we delegating, and who remains accountable?

STAGE 2 Collect and Process DataGate: Does the Agentic Use Case have the trusted information required to operate safely?

STAGE 3 Build Use CaseGate: What must change to enable this Agentic Use Case?

STAGE 4 Verify and ValidateGate: Can delegated work safely commence?

STAGE 5 Deploy and UseGate: How do we transition the Agentic Use Case into live business operations?

STAGE 6 Operate, Monitor and EvaluateGate: Can we trust the Agentic Use Case is operating safely, effectively and within delegated authority?

STAGE 7 Decommission and RetireGate: Has delegated authority been withdrawn and responsibilities appropriately closed?

Legend

Workshop and development notes

Statistics

Processes per stage

A process step is a user task or a system task. Gateways, events, notes and groups are not counted, and neither is the one out-of-scope task (Assess Data Readiness). A step several roles share counts once in Total and once under each role, so a row's role cells can add up to more than its Total. A system task sits in System, not in the lane it is drawn in.

Process steps per stage and role
Stage	Any user	ABUCO	ABSO	ABO	ATSO	ATO	ADT	DDO	DPT	AIC	DS	System	Total
0 Risk Assessment	1	0	6	0	0	0	0	0	0	0	0	0	7
1 Plan and Design	0	1	8	2	5	1	0	0	0	0	0	1	12
2 Collect and Process Data	0	0	4	4	1	3	0	2	1	1	0	4	17
3 Build Use Case	0	0	0	0	0	7	1	0	0	0	0	0	8
4 Verify and Validate	0	1	3	2	0	1	4	0	0	0	0	0	9
5 Deploy and Use	0	0	2	2	2	5	2	0	0	0	0	2	11
6 Operate, Monitor and Evaluate	0	0	8	5	0	5	4	0	0	0	1	0	18
7 Decommission and Retire	0	2	6	4	1	3	1	0	0	0	0	0	15
All stages	1	4	37	19	9	25	12	2	1	1	1	7	97

UI forms per stage

Every form in the Form column. A form several roles complete counts once in Total and once under each role. A gate or system-check checklist has no role, so it has its own column and counts in Total. Stages 6 and 7 show zero because no mockups exist yet.

UI forms per stage and role
Stage	Any user	ABUCO	ABSO	ABO	ATSO	ATO	ADT	DDO	Checklist	Total
0 Risk Assessment	1	0	4	0	0	0	0	0	1	6
1 Plan and Design	0	1	7	2	5	1	0	0	2	14
2 Collect and Process Data	1	0	5	4	1	3	0	2	2	15
3 Build Use Case	0	0	0	0	0	7	1	0	1	9
4 Verify and Validate	0	1	3	2	0	1	4	0	2	11
5 Deploy and Use	0	0	2	2	2	5	2	0	1	10
6 Operate, Monitor and Evaluate	0	0	0	0	0	0	0	0	0	0
7 Decommission and Retire	0	0	0	0	0	0	0	0	0	0
All stages	2	2	21	10	8	17	7	2	9	65

Integrations per stage

Each row is a system Asgard or Bifrost exchanges data with. Steps and flow directions come from the diagram; the mechanism and source are curated in src/stats-data.mjs. By hand means a person moves the data and no system call is documented. Inference marks a row whose route or content rests on inference, not on a decision. Decisions are numbered in docs/business-processes.md, and NN-stage files are in docs/claude-docs/business-processes/.

Systems exchanging data with Asgard or Bifrost, by stage
Stage	System	Direction	Steps	Mechanism and source
0-7	Entra ID	To Asgard	Every step	Users sign in by OIDC and the browser holds no tokens. Group membership comes from the token, resolved once per session and again before approve, publish and retire. MuleSoft and Asgard each hold an Entra app role on Bifrost, and the AIRA system one on Asgard's endpoint.Source: architecture.md G1, G3, G7, G7a, G11a; ADR-0016
0	AIRA system	Both	0.3	Asgard gives the ABSO a link to start the AIRA in the AIRA system. The AIRA system then POSTs the AIRA to an authenticated Asgard endpoint over BHP's network. Bifrost is not in the path. The stage 0 gate does not wait for the POST.Source: ADR-0016; decisions 11, 35, 108, 113
0	Collibra	To Asgard	0.0	Inference The search covers Collibra and Asgard. Asgard calls no external system, so Bifrost would read Collibra and hand the result over through bifrost.inbox. No document routes this search.Source: decision 14; architecture.md A1 and its 24 October note
0	Email or notification	From Asgard	0.3 and the stage 0 gate	Inference The gate passes once the ABSO is told an AIRA should be created. Asgard composes the notice and Bifrost would send it through Microsoft Graph. The docs say email or notification, so the channel is inferred.Source: decisions 112, 113; architecture.md L1 note, L2, L4
0	Assurance Tower, via MuleSoft	To Asgard	No step drawn	Inference The Tower can discover an agent before any AIRA exists. MuleSoft pushes the discovery to Bifrost's ingest, which inserts it into bifrost.inbox, and Asgard reads it under grant. Whichever of discovery or assessment arrives first mints the identifier. The route is inferred and contract v2.2 gives the object no schema.Source: architecture.md Components, Record Arrival, J1; ADR-0016; scope.md Stage 0, question 11
1	Collibra	From Asgard	1.7, 1.9Collibra status: Candidate (use case), Candidate	Bifrost publishes the use case as Candidate after the 1.7 Yes, then the agent record as Candidate at 1.9, and republishes owner responsibilities when an owner is replaced. A failed publish leaves the status unchanged, Bifrost retries and raises it to Data Strategy.Source: ADR-0014; decisions 42, 96; architecture.md D1 to D4
1	Collibra	To Asgard	1.7	Inference Collibra sets the AI Use Case ID when it first receives the use case. Asgard needs it back, so Bifrost would read it and hand it over through bifrost.inbox.Source: decision 42 (q-1-13); ADR-0014; architecture.md A1 note
1	Collibra	To Asgard	1.8	Inference A GEAR ID is valid when it exists as a Collibra Business Application, and many agents may share one. Bifrost reads it and would hand the result over through bifrost.inbox.Source: decision 43 (q-1-14); architecture.md A1 note; ADR-0011 Gates for Stages 1 to 5
1	GEAR	Both	1.8	Inference By hand. The ATSO creates the agent record in GEAR and keys the GEAR ID into Asgard. The diagram draws a create-entry and a GEAR ID flow, and no document describes a system call to GEAR (A1 lists none).Source: decision 43; architecture.md A1
1	AIRA system	Both	1.6	The ABSO and ATSO update the AIRA in the AIRA system, which reposts to Asgard by the same authenticated POST until its status is Complete.Source: ADR-0016; decisions 34, 35
1	Email or notification	From Asgard	1.4	Inference Completing 1.4 sends assignment requests to the ABUCO, ABO and ATSO. Asgard hands Bifrost a delivery request and Bifrost mails through Microsoft Graph. The docs do not say which stage 1 steps send mail.Source: decision 20; architecture.md L1 note, L4
2	Collibra	From Asgard	R-23 DPIA link, 2.4, Confirm Agent record is ready to publishCollibra status: In Progress	Bifrost publishes the use case to DPIA relation (R-23) after 2.1, COL3 Create Data Use Case once every Data Domain has approved 2.4, and COL2 Update Agentic Use Case with the 2.12 Ready publish, which sets the agent In Progress.Source: ADR-0014; decisions 28, 91, 98, 106
2	Collibra	To Asgard	2.3	Inference The ABSO picks Business Terms, Data Concepts, Data Domains, Data Entities and Business Applications from the catalogue. The design has no Collibra to Asgard read path yet; the A1 note proposes Bifrost reads handed over through bifrost.inbox.Source: docs/workflows.md Stage 2 and Effects on Existing Records; architecture.md A1 note, D6
2	Collibra	To Asgard	Domain owner for 2.4 and 2.6	Inference Bifrost reads each Data Domain's owner from Collibra before 2.4 and 2.6 and sends the request. If none is found, Data Strategy names one. BHP has not confirmed the read, and the hand-off to Asgard is not specified.Source: decisions 95 (r-2-2), 106; architecture.md A1 note
2	Collibra	To Asgard	Check DPIA status in Collibra	Inference Bifrost reads the status of every DPIA linked to the use case from the Collibra DPIA records and would hand it over through bifrost.inbox. Asgard waits until every linked DPIA is Approved, with at least one.Source: decision 28; ADR-0011 External outcomes become system assignments; architecture.md A1 note
2	DPIA (privacy tool)	Both	2.1, 2.2	Inference The ABSO raises a DPIA in the privacy tool or attaches an approved one, and Asgard records the reference. The Data Privacy Team approves there, outside Asgard. Asgard learns the approval only from Collibra. No document describes an Asgard call to the privacy tool.Source: decisions 27, 28, 51; ADR-0011
2	ServiceNow	Both	2.5	By hand. The ATO raises the data access request as a ServiceNow ticket and keys the ticket number into Asgard, which records it and does not track it. A withdrawal before 2.6 cancels the ticket by hand.Source: decisions 55, 103
2	AIRA system	Both	2.9	The ABSO and ATSO finalise the AIRA in the AIRA system, which POSTs status Final to Asgard. Asgard takes a second dated risk tier snapshot.Source: ADR-0016; decisions 34, 45 (q-2-16)
2	AIRA system	To Asgard	2.10	The AI Committee approves in the AIRA system, outside Asgard, which POSTs the approval to Asgard. The stage 2 gate waits for it, and a rejection stalls stage 2.Source: decisions 28 (q-g-6), 56; ADR-0011
2	Email or notification	From Asgard	Tell the ABSO and ATO why it was rejected, Domain owner for 2.4 and 2.6	Inference A rejected access request at 2.6 tells the ABSO and ATO why. When no Data Domain owner is found, Data Strategy is told. The docs name no channel; mail would go through Bifrost and Microsoft Graph.Source: decision 96 (r-2-3); architecture.md L4
2	Assurance Tower, via MuleSoft	From Asgard	2.7	Inference The owners set the KPIs and business policy at 2.7 and the Tower reports against them. No document says how they reach it.Source: 05-stage-2-collect-process-data.md (2.7)
3	Assurance Tower, via MuleSoft	Both	3.1, ATO confirms the AAT registration and AAT ID	Bifrost registers the agent in the Tower through MuleSoft and the ATO confirms the result and records the AAT ID. The result and technical profile arrive through bifrost.inbox. Contract v2.2 gives the call no schema.Source: decision 92; ADR-0011; architecture.md A1 note
3	Collibra	From Asgard	3.1Collibra status: In Development	Bifrost publishes the agent's AAT registration and sets the agent In Development.Source: ADR-0014; decision 87
4	Collibra	From Asgard	4.1, 4.4Collibra status: Testing, Verifying	Bifrost publishes the test evidence and sets the agent Testing at 4.1, then the business readiness and sets it Verifying at 4.4.Source: ADR-0014; decision 87
4	Assurance Tower, via MuleSoft	To Asgard	4.1	Inference The 4.1 form shows read-only results from the Tower: offline evaluation, adversarial testing, Red Team findings and safe stop tests. No document says how they reach Asgard.Source: 07-stage-4-verify-validate.md (4.1)
4	Azure Blob evidence container	From Asgard	4.1	Evidence files uploaded at 4.1 go to the evidence container that BHP provisions. Asgard writes them and keeps them like the audit log. They are Asgard's evidence, not Collibra attachments.Source: decision 67 (q-4-7); architecture.md B2 note
4	ServiceNow (CAB)	Both	4.6	By hand. The ADT raises the change for CAB and the ATO keys the CAB number into Asgard. Asgard does not track CAB approval, which is a separate process; the number is used to review the approval in ServiceNow.Source: decisions 71, 89
5	Assurance Tower, via MuleSoft	Both	5.2	Bifrost calls the Tower through MuleSoft to set the agent Operational and the ATO confirms. The MuleSoft return reaches Asgard through ingest and bifrost.inbox, though Bifrost reading its own response may remove the push. Contract v2.2 gives the return no schema. A failed or blocked call retries.Source: decisions 74, 92, 99, 104; architecture.md A1 notes; scope.md question 11
5	Assurance Tower, via MuleSoft	To Asgard	5.1	Inference The 5.1 and 5.2 forms show read-only Tower values: deployment date, environment and endpoint, guardrail and safe stop status, baseline, lifecycle status. No document says how they reach Asgard.Source: 08-stage-5-deploy-use.md (5.1, 5.2)
5	Collibra	From Asgard	5.2Collibra status: Approved, Approved (use case)	The ABO and ABSO confirm in Asgard and Bifrost sets the agent and the use case Approved in Collibra. Approved replaces Operational as the agent's Collibra status.Source: decisions 74, 87; ADR-0014
5	Collibra	To Asgard	Approvals are still valid	Inference The pre-deploy check reads the DPIA status from Collibra through Bifrost and, for a lapsed 2.4 or 2.6 approval, the current Data Domain Owner. The other approvals are Asgard's own records. The hand-off route is the A1 proposal.Source: decisions 28, 102, 106; architecture.md A1 note
5	GEAR	Both	5.3	Inference By hand. The ATO finalises the GEAR entry the ATSO created at 1.8 and records Yes or No in Asgard. No document describes a system call to GEAR.Source: 08-stage-5-deploy-use.md (5.3); architecture.md A1
5	Email or notification	From Asgard	5.5, Which approval lapsed, to ATO and approver	Inference 5.5 sends its notification to the four 5.5 parties only, inside the L3 allowlist, and collects each confirmation. The lapsed-approval notice to the ATO and approver has no stated channel.Source: decisions 75, 102; architecture.md L3
6	Assurance Tower, via MuleSoft	To Asgard	Monitor telemetry, drift and anomalies, 6.2	Inference Held for confirmation. The Tower owns the four monitoring streams, supported by the ADT, and an AAT event opens 6.2. It notifies Asgard of non-compliance, which is inferred. No document gives the route or a schema.Source: decision 77; architecture.md F1; scope.md Stage 6; decision 86
6	Assurance Tower, via MuleSoft	From Asgard	Set Agent to under review in AAT, Maintain Agent details in AAT	Inference Held for confirmation. After 6.4 the ATO sets the agent under review in the Tower, and 6.5 maintains its details. No document gives the route; by A1 it would be a Bifrost call through MuleSoft.Source: 09-stage-6-operate-monitor-evaluate.md (6.4, 6.5); architecture.md A1; decision 86
6	Collibra	From Asgard	Set under review in Collibra, Maintain details in Collibra	Held for confirmation. Bifrost publishes under review and later maintenance changes for the use case and agent. Each is a confirmation in Asgard that Bifrost publishes, never an edit in Collibra.Source: ADR-0014 table, stages 6 and 7; architecture.md E3a note; decision 86
6	Collibra	From Asgard	6.6	Inference Held for confirmation. Data Strategy monitors ownership currency through Collibra assets, outside Asgard, so Bifrost must publish owner responsibilities.Source: decision 27 (inference there); architecture.md D2
6	Email or notification	From Asgard	6.4	Held for confirmation, except that the ABSO and ABO answer 6.4 inside Asgard (decision 79, final). The email only notifies them, with a plain deep link that needs sign-in.Source: decision 79; ADR-0015; architecture.md L1 note
6	New Relic	To Asgard	No step drawn	Inference A later-phase source of runtime evidence per agent: last invocation, invocation count and error rate, pulled by Bifrost on a schedule. Nothing in the first build reads it. The stage is inferred.Source: architecture.md Components
7	Assurance Tower, via MuleSoft	From Asgard	7.6	Inference Held for confirmation. The ATO updates the agent record at 7.6, and a withdrawal runs the update at any stage for an agent registered there. MuleSoft carries retire commands out. That 7.6 sends the retire command is inferred.Source: decision 88; architecture.md Components, Record Arrival; scope.md 6A; decision 86
7	Assurance Tower, via MuleSoft	To Asgard	7.2, 7.5	Inference Held for confirmation. 7.2, 7.5 and 7.6 show read-only Tower values: scope, dependencies, revocation evidence, Agent Registry status and Retirement Date. No document says how they reach Asgard.Source: 10-stage-7-decommission-retire.md (7.2, 7.5, 7.6); decision 86
7	Collibra	To Asgard	7.2	Inference Held for confirmation. 7.2 shows dependent use cases, and 7.6 the data-retention requirements and lifecycle status, from Collibra. No document gives the route.Source: 10-stage-7-decommission-retire.md (7.2, 7.6); decision 86
7	Collibra	From Asgard	7.6Collibra status: Retired (agent), Retired (use case)	Bifrost publishes Retired for each agent at its 7.6, then for the use case after its last agent. A withdrawn agent and an abandoned use case also publish Retired, with the reason kept in Asgard.Source: ADR-0014; decisions 37, 81, 87, 88
7	GEAR	From Asgard	7.6	Inference Held for confirmation. The ATSO updates the agent's GEAR record at 7.6, and a withdrawal runs the update for any agent registered in GEAR. No document describes a system call.Source: decision 88; ADR-0011; decision 86
7	Email or notification	From Asgard	7.3, 7.6	Held for confirmation, except that the 7.x approvals are answered inside Asgard (decision 79, final). The email only notifies, and the ABUCO is told when the agent retires.Source: decision 79; ADR-0015

DLM onboarding at 7.6 is a separate request by the ABSO, and CAB approval is a separate process, so neither moves data to or from Asgard. Any purge of audit rows older than five years is BHP's DLM process, not Asgard's (decision 36).

Asgard and the MuleSoft Assurance Tower

The Tower writes into no store here: MuleSoft pushes its data to Bifrost's ingest, the only sender the architecture records, and Bifrost's own calls and sweeps read it, so Asgard receives it as inbox rows and never as a direct write. That reconciles "the Tower writes nothing and is read" with the inbound rows below. No document names a path by which the Tower reads Collibra. Contract v2.2 gives the inbound objects and the 3.1 and 5.2a calls no schema, so most field lists are the forms' own and every unspecified list is an open item.

Data between Asgard and the Assurance Tower, via MuleSoft and Bifrost
Data item	Direction	Fields	Path and source	Stage and step
Agent discovery	To Asgard	Not specified	Open: fields Inference Tower, MuleSoft push, Bifrost ingest (the public origin), bifrost.inbox. The worker validates it against a registered JSON Schema and binds or mints the identifier, and Asgard reads the row under grant. Contract v2.2 lists nine inbound objects, none with a schema.Source: architecture.md Components, Record Arrival, J1, G11a, The MVP; ADR-0016; scope.md question 11	Before stage 0; no step drawn
Inventory and disappearance sweeps	To Asgard	Not specified	Open: fields Inference Bifrost jobs run on cron, read the Tower's inventory and insert queue rows. A divergence reaches Asgard as an exception queue entry. A push cannot report an agent that has disappeared, which is why the sweep exists.Source: architecture.md J1, F2, H3	Every stage; no step drawn
Registration result and technical profile	To Asgard	AAT ID and 30 profile fields in 7 groups AAT ID Agent card: Agent ID, Agent Description, Agent Type, Instructions Agent version: Agent Version, Asset Version Status, Change Summary, Version Effective Date, Version Published Date Capability: Enabled Agentic Capabilities Model profile: AI Base Model, AI Endpoint, AI Model Deployment, AI Model Version, Approved Model List, Primary LLM Provider Tools and MCP: Tool Approval Status, Tool Description, Tool Usage Scope Identity and controls: Workload identity, Authentication and credentials, Least privilege permissions, Registry access controls, Control plane implementation, Runtime guardrail configuration, Safe stop design, Fallback design, Audit logging configuration Relationships: Agent-to-agent relationship, Reusable agent relationship As the 3.1 form shows them. Contract v2.2 gives the call no schema.	Bifrost calls the Tower through MuleSoft; the result arrives through bifrost.inbox like any Bifrost read.Source: 06-stage-3-build-use-case.md (3.1); decision 92; ADR-0011	Stage 3, step 3.1
Test evidence	To Asgard	Offline evaluation results; Adversarial-testing results; Red Team findings; Safe stop test resultsAs the 4.1 form shows them.	Open: path Inference Not specified. By A1 it would come through Bifrost and bifrost.inbox.Source: 07-stage-4-verify-validate.md (4.1)	Stage 4, step 4.1
Post-deployment facts	To Asgard	8 values Production deployment date Production environment and endpoint Production access status Runtime guardrail status Safe stop status Monitoring thresholds and alerts Initial performance baseline AI Monitor and System Version As the 5.1 form shows them.	Open: path Inference Not specified. By A1 it would come through Bifrost and bifrost.inbox.Source: 08-stage-5-deploy-use.md (5.1)	Stage 5, step 5.1
Operational status return	To Asgard	Lifecycle Status; Published ByAs the 5.2 form shows them. Contract v2.2 gives the return no schema.	Bifrost sets Operational through MuleSoft. The return reaches Asgard as a MuleSoft push into ingest, then bifrost.inbox. Bifrost reading its own response may replace the push.Source: decisions 74, 99, 104; architecture.md A1 notes; scope.md question 11; 08-stage-5-deploy-use.md (5.2)	Stage 5, step 5.2
Monitoring values	To Asgard	21 values Business KPI actual result Proxy Metrics for Alignment AI Trust Score Compliance Status Technical performance metrics Reliability metrics Accuracy and Completeness Metrics Model-drift indicators Guardrail events Safe-stop or restriction events Human overrides and exception rates Agent-to-agent activity Error, failure and anomaly events Incidents and near misses Abuse and misuse events Data-use compliance Last refresh and freshness results User feedback Policy exceptions Control effectiveness results Monthly Cost Actual The 6.1 dashboard shows these read-only.	Open: path Inference Not specified. The Tower owns the four monitoring streams, supported by the ADT.Source: 09-stage-6-operate-monitor-evaluate.md (6.1); decisions 77, 86	Stage 6, step 6.1. Held (decision 86)
Event and non-compliance notice	To Asgard	The event; Policy Exception IDAs the 6.2 form shows them. That the Tower notifies Asgard of non-compliance is inferred.	Open: path Inference Not specified. The diagram draws an AAT event that opens 6.2.Source: 09-stage-6-operate-monitor-evaluate.md (6.2); architecture.md F1; scope.md Stage 6; decision 86	Stage 6, step 6.2. Held (decision 86)
Agent version and change history	To Asgard	Agent Version; Change historyAs the 6.5 form shows them.	Open: path Inference Not specified.Source: 09-stage-6-operate-monitor-evaluate.md (6.5); decision 86	Stage 6, step 6.5. Held (decision 86)
Downstream impact	To Asgard	Agents and systems in scope; Current version and deployment status; Agent-to-agent and system dependencies; Reusable agent impactAs the 7.2 form shows them.	Open: path Inference Not specified.Source: 10-stage-7-decommission-retire.md (7.2); decision 86	Stage 7, step 7.2. Held (decision 86)
Decommission evidence and retirement date	To Asgard	7 values Identity and credential revocation Tool and integration shutdown Endpoint and deployment retirement Safe-stop and decommission evidence Memory, prompts and output treatment Agent Registry status Retirement Date As the 7.5 and 7.6 forms show them.	Open: path Inference Not specified.Source: 10-stage-7-decommission-retire.md (7.5, 7.6); decision 86	Stage 7, step 7.5. Held (decision 86)
Registration request	From Asgard	Not specifiedNearest named items: the Agentic Asset onboarding object with policy bundle binding, and Target System Asset ID. That the call carries them is inference.	Open: fields Inference Asgard asks Bifrost, which calls the Tower through MuleSoft (A1). Contract v2.2 gives the call no schema.Source: decision 92; architecture.md A1 note, C3, H4	Stage 3, step 3.1
Operational status	From Asgard	Status Operational for the agentNo other field is specified.	Bifrost calls the Tower through MuleSoft; the ATO confirms the result. A failed or blocked call retries.Source: decisions 92, 99; ADR-0011	Stage 5, step 5.2
KPIs and business policy	From Asgard	KPI Name; KPI Unit; KPI Target; KPI Review Frequency; Monthly Cost Budget; Business policyThe 2.7 form fields. The Tower reports against them.	Open: path Inference Not specified.Source: 05-stage-2-collect-process-data.md (2.7)	Stage 2, step 2.7
Approved baseline	From Asgard	Model; Endpoint; Autonomy; Data access; IdentityF1's obvious five fields the approval is conditioned on. BHP has not agreed the list.	Open: path Inference Not specified. The Tower measures against the approval, so it needs the baseline from somewhere.Source: architecture.md F1, H2b, Record Arrival	Stage 4, step 4.5
Under review and detail changes	From Asgard	Status under review; Agent details after a model changeNo other field is specified.	Open: path Inference Not specified. By A1 it would be a Bifrost call through MuleSoft.Source: 09-stage-6-operate-monitor-evaluate.md (6.4, 6.5); architecture.md A1; decision 86	Stage 6, steps 6.4 and 6.5. Held (decision 86)
Retire instruction and 7.6 update	From Asgard	Not specified	Open: fields Inference Bifrost's outbound leg to MuleSoft, which carries retire and inventory commands out.Source: decision 88; architecture.md Components, Record Arrival; scope.md 6A; decision 86	Stage 7, step 7.6. Held (decision 86)
Contract v2.2 outbound objects	From Asgard	Not specifiedFifteen named schemas. Their field lists are not in this repository.	Open: fields The asgard schema, a new mapping onto the fifteen schemas, Bifrost's outbound leg, MuleSoft.Source: architecture.md The MVP; scope.md The first build	First build; no stage

Dependencies

Step	Roles	Depends on	Unblocks	Carried values
Search and Submit an idea	Any signed-in user	None	0.0	The idea as submitted. The real intake form is to be confirmed in the workshops.
0.0 Search	ABSO	Search and Submit an idea	0.1 on None match; a match links the idea to the existing record, then ends at Use this one	Search term and Existing found = No. The search page comes first, the create page (0.1) second.
0.1 Create Candidate Use Case	ABSO	0.0 None match	0.2; 1.9 reads Criticality	Owners named: the ABSO (required), the ATSO (optional, nominate if known), the Executive Sponsor and the Security Owner. Criticality.
0.2 Accept Ownership	ABSO	0.1	0.3 and the team assembly; Stage 0 gate; 1.1 (ABSO); 1.7 gate. A decline returns to 0.1.	Role acceptance evidence. The form is itself the acceptance. The ABUCO accepts at 1.1, not here.
0.3 Initiate AIRA	ABSO; AIRA	0.2	Stage 0 gate; 1.2, 1.3, 1.5 read it; 1.6	A link to start the AIRA directly after accepting ownership. The ATSO may support it but is not required. AI Project ID, Risk Tier and ratings come from the AIRA, which recalculates the tier and updates it through to 2.9. The stage 0 gate does not wait for the AIRA to arrive; which stage waits for it is open.
0.3 Start team assembly	ABSO	0.2, in parallel with Initiate AIRA	The team assembly process, which is separate and does not hold the stage 0 gate	None. What the process contains is not decided.
Stage 0 gate	None	0.1, 0.2, 0.3	Stage 1	Use case created in Asgard, ABSO accepted ownership (0.2), the AIRA email or notification sent to the ABSO (informed AIRA should be created). No ABUCO acceptance. No person approves this gate. It does not wait for the AIRA to arrive; which stage does is open.
1.1 Owner Onboarding	ABUCO, ABSO, ABO each	ABSO: stage 0 gate. ABUCO and ABO: completing 1.4 sends each a 1.1 assignment.	The ABO's part of 1.3 (ABO), once the ABO accepts; an ABUCO or ABO decline returns to 1.4. 1.7 gate waits for all three	Attestation and confirmation of responsibilities. For the ABUCO and the ABO the form is also the role acceptance, since 0.2 covers only the ABSO.
1.2 Business Outcome	ABSO	Stage 0 gate; AIRA	1.3, 1.7	The ABSO fills in the business case as form fields. Reads Business Objective, Value, Oversight. Guardrails go to 1.3.
1.3 Solution and Data	ABSO, ABO, ATSO, ATO joint	1.2 and the ATSO's 1.4, which names the ATO (gateway 1a, q-1-3); the ABO's part also on the ABO's 1.1. An ATSO rerun (an ATO decline, a re-named ATSO or a further agent) opens the ATO's part directly.	1.7, once the ATO accepts; an ATO decline returns to the ATSO's 1.4	Reads guardrails, AIRA concept and platform.
1.4 Identify Agent Owners	ABSO assigns the ABUCO, the ATSO and the ABO	Stage 0 gate; a decline by the ABUCO, ATSO or ABO runs it again	A first naming: 1.1 (ABUCO, ABO) and the ATSO's 1.4, which feeds the 1.2 and 1.4 join (gateway 1a) once accepted; the gateway then starts 1.3 (all four parts) and 1.6, then 1.9. A re-named ABUCO restarts only the ABUCO's 1.1; a re-named ABO restarts only the ABO's 1.1; a re-named ATSO restarts only the ATSO's 1.4; a further agent (decision 30) reruns the ABO's 1.1, the ATSO's 1.4, 1.5 and 1.6. 1.2 does not rerun.	ABUCO, ATSO, ABO.
1.4 Identify the ATO	ATSO names the ATO	The ABSO's 1.4, which names the ATSO; an ATO decline at 1.3 runs it again	Accepted: a first naming goes to gateway 1a, which opens 1.3 with 1.2; a rerun opens the ATO's part of 1.3 directly (the ATO accepts there, decision 40). An ATSO decline returns to the ABSO's 1.4	ATO.
1.5 Technical Requirements	ATSO	Stage 0 gate; AIRA	1.7	Reads Proposed Platform, Models and Components. The AIRA update (1.6) runs in parallel; 1.5 only feeds the 1.7 gate.
1.6 Update AIRA	ABSO with ATSO; AIRA	0.3; starts with 1.3 at gateway 1a (1.2 and the ATSO's 1.4 done); reposts until Complete. Runs in parallel with 1.3 and 1.5. A further agent reruns it.	1.7 gate; 1.9 reads Risk Tier	AIRA status, risk values.
1.7 Update Agentic Use Case	ABSO	1.1 (ABUCO, ABSO, ABO), 1.2, 1.3, 1.5, 1.6	Yes: update the use case record in Collibra (status Candidate), validate the GEAR ID, then 1.9. No returns to 1.7.	Final ABSO check before records are updated in Collibra. Gate: use case and outcomes, AIRA, ownership accepted (ABSO at 0.2; ABUCO and ABO at 1.1; the ATO named at 1.4 accepts at 1.3), onboarding, design.
1.8 GEAR record	ATSO; GEAR	None. The ATSO records it at any point in stage 1.	GEAR ID validation after the 1.7 Yes	GEAR ID as ATSO metadata. No approval.
1.8 Validate GEAR ID	System	1.7 Yes; the GEAR ID from 1.8	1.9, which waits for a valid GEAR ID. Not found returns to 1.8 with a reason, where the ATSO corrects it	GEAR ID checked against the use case and agent.
1.9 Initial Agent Record	ABSO	1.7 Yes, GEAR ID validated, 1.4, 1.6	Stage 2	Agent name nominated by the ABSO, GEAR ID, owners, Collibra status Candidate. Risk Tier snapshot with its date (each later change is in the audit history), Criticality. The Collibra statuses are added to BHP's operating model by Shane. Use case statuses are Candidate, Approved and Retired.
Withdraw agent	ABSO or ABO	Any stage before 6	Agent set to Retired (reason Withdrawn); lets a use case be abandoned	From stage 3 to 5 the revoke step and decommission evidence still run. Whenever the agent is registered in AAT or GEAR, the withdrawal also runs the 7.6 AAT update (ATO) and GEAR update (ATSO), at any stage. After 2.5 and before 2.6 the ATO cancels the open data access request; once 2.6 has granted access, the ATO confirms it is revoked (decision 90). Collibra status Retired (agent).
2.3 Initiate Data Use Case	ABSO	1.9	Resolve domain owners	Business terms, data concepts, purpose, quality, legal basis.
2.x Resolve Data Domain owners	System	2.3	2.4	Resolves the owner for 2.4 and 2.6 from Collibra and sends the request. If none is found, Data Strategy is told and names one. BHP has not confirmed the Bifrost read (architecture.md A1 note).
2.4 Approve Data Use Case	Data Domain Owner, one per domain	2.3	The DPIA, data access and KPI branches. A rejection returns to 2.3.	Approval, conditions, sensitivity. COL3 Create Data Use Case publishes once every Data Domain has approved.
2.1 Raise or attach DPIA	ABSO; privacy tool	2.4	Publish R-23 link, COL2 and COL3	DPIA reference. One or more per use case; an approved DPIA can be attached. IPDA, TPCRM and TSA are out of scope for now.
2.x Publish R-23 link, COL2 and COL3	System	2.1	2.2 for a newly raised DPIA; the Collibra status check for an attached approved DPIA	Publishes the use case to DPIA relation (R-23), which follows 2.1 (decision 91).
2.2 Approve DPIA	Data Privacy Team, outside Asgard	2.1	Collibra status check	Managed in the privacy tool. Asgard has no form for it.
2.x Check DPIA status	System	2.2, or an attached approved DPIA	Join before 2.8. The process waits until a DPIA is approved.	Reads the DPIA status from the Collibra DPIA records.
2.5 Raise Data Access Request	ATO, with ADT	2.4	2.6	Manual ServiceNow ticket; Asgard records the ticket number. Systems, access type, minimisation.
2.6 Approve Access to Data	Data Domain Owner, one per domain	2.5	Join before 2.8; Assess Data Readiness (out of scope). A rejection notifies the ABSO and ATO, then returns to 2.5.	Decision, access controls.
2.x Notify of a rejected access request	System	2.6 rejected	2.5	Tells the ABSO and the ATO the reason for the rejection.
2.7 Define KPI and Policy	ABSO, ABO joint	2.4	Join before 2.8	Business KPIs and policies. The ADT uses them for technical policies and monitoring.
2.7a Confirm data fitness	ABO	Join of DPIA, data access and KPI branches	2.8 when the data is fit; not fit returns to 2.3	Data fitness confirmed before the HLD. A No returns to 2.3 with a reason; the gap is not accepted. Data readiness is out of scope until Q3 FY27.
2.8 Complete High Level Design	ATO, with ADT	Confirm data fitness (ABO)	2.9	HLD document.
2.9 Finalise AIRA	ABSO with ATSO; AIRA	2.8	2.10	AIRA status Final.
2.10 Approve AIRA	AI Committee, outside Asgard	2.9	2.11	Approval arrives by POST from the AIRA system. Reads Risk Tier. A rejection in the AIRA system stalls stage 2 until a new approval POST.
2.11 Update Agent Record	ABO, ATO joint	2.10	ABO confirmation	Scope from 1.2, 2.7, 2.3. Sets no Collibra status.
2.x Confirm Agent record ready	ABO	2.11	Stage 2 gate, which passes automatically, when ready; not ready returns to 2.11 and publishes nothing	ABO confirms the record is correct and ready to publish. Collibra status In Progress. COL2 Update use case asset publishes with the Ready publish.
3.0 Build	ADT	Stage 2 gate	3.1	None.
3.1 Register Agent in AAT	Bifrost registers in AAT; the ATO confirms	3.0	ATO confirmation of the result, then 3.2 to 3.5 in parallel. A failed registration is repeated.	Initial registration. AAT is updated as technical detail develops. Collibra status In Development.
3.2 to 3.5	ATO	3.1	ATO sign-off	Decision authority, architecture and security references, control confirmation, support and training. Technical documents; business users see only that they were provided.
3.x ATO sign-off	ATO	3.1 to 3.5	Stage 3 gate, which passes automatically, when approved; refused returns to 3.2 to 3.5 with a reason	The ATO approves the architecture.
4.1 Technical testing (three activities)	ADT; the ATO confirms	Stage 3 gate	4.2	A checklist with links or file uploads. The activities run in parallel. Collibra status Testing. The ATO also confirms the build matches the approval: model, tools and tier against the AIRA (2.9), data sources against 2.5, 2.4 and 2.6, and the build against the 2.8 HLD. If not, 4.1 reruns, with a reason.
4.2 UAT and Validation	ABSO, ABO joint; each signs off inside the form, in parallel	4.1	4.4 when signed off; a failed UAT returns to 4.1 with a reason	UAT evidence, one sign-off per role.
4.4 Business Readiness	ABSO, ABO joint	4.2 (both sign-offs); a 4.5 rejection runs it again	4.5, governance update, 4.6 on the first pass; a rerun goes to 4.5 only	Readiness results, risk sign-off. Collibra status Verifying.
4.5 Approve Readiness	ABUCO	4.4	Stage 4 gate when approved; rejected returns to 4.4	Decision, residual risk, authorisation.
4.5 Update governance	ABSO	4.4	Stage 4 gate	Processes and delegations updated.
4.6 Initiate CAB	ADT; CAB	4.4	Stage 4 gate	CAB number from the ADT. CAB approval is a separate process.
5.x Check approvals still valid	System	Stage 4 gate	5.0 when valid; lapsed or unmet notifies the ATO and the approver, then loops back to the check	Checks the 2.4 and 2.6 approvals and conditions, the DPIA status and the 4.4 conditions have not lapsed. The approver renews on the original 2.4, 2.6 or 4.5 record, or the DPIA in the privacy tool; no gate reopens. If the original approver has left, the current role holder renews: the current Data Domain Owner from Collibra for 2.4 and 2.6, or the current ABUCO for 4.5.
5.0 Deploy	ADT	5.x check approvals; a failed 5.1 check returns here	5.1	None.
5.1 Post-Deployment Checks	ATO with ADT	5.0	5.2 (AAT) when the checks passed; failed returns to 5.0 with a reason	Checks passed, evidence.
5.2 Set status	Bifrost sets AAT, and only the ATO confirms Operational; ABO (Collibra Approved); ABSO (use case)	5.1; the MuleSoft return updates Asgard. Failed or blocked in AAT is retried before 5.2 runs in Collibra.	5.5	AAT goes Operational; the ABO sets the Agent to Approved in Collibra. The ABSO sets the use case to Approved in parallel. Collibra statuses: Agent Approved, use case Approved.
5.3 Finalise GEAR	ATO; GEAR	5.2 (AAT)	5.5	GEAR registration final.
5.4 Operational Support	ATSO	5.2 (AAT)	5.5	Escalation contact, support group.
5.5 Activate Support	ABSO, ABO, ATSO, ATO joint	5.2, 5.3, 5.4	Stage 5 gate, which passes automatically	Notification to the 5.5 parties (ABSO, ABO, ATSO, ATO); confirmation from each.
6.x Monitoring feeds	ATO, ADT; the AAT owns the streams, supported by the ADT	Stage 5 gate	6.1	Telemetry, KPIs.
6.1 Periodic Review	ABSO, ABO joint	Telemetry, operational monitoring	Review outcome	Decision, rationale, next review.
6.2 Respond to Event	ABSO, ABO joint	Review outcome or AAT event	6.4	Assessment, action.
6.3 Incident, Risk or Change	ADT	Patching, monitoring	6.4	Record type and reference.
6.4 Approve Restriction	ABSO, ABO joint; ATO executes	6.2 or 6.3	Under review in Collibra and AAT	Action, reason, effective from.
6.5 Agent Model Change	ATO, ABSO, ABO, ADT	Under review	Next review	Change summary, approval, release.
6.6 Ownership Currency	Data Strategy, outside Asgard	None	Maintain Collibra	Data Strategy monitor ownership currency through the Collibra assets. As platform admins they have full access at every stage; every change is logged and the audit is immutable. Stage 0 to 5 data is not expected to change after stage 6; an admin who changes it on a stage 6 or 7 record is warned and must give a reason, which is logged.
Stage 6 gate	Held for confirmation	To be confirmed	Stage 7 on a Retire outcome	Stage 6 content is held for confirmation.
7.1 Request to Retire Agent	ABO	6.1 Retire	7.2, 7.3	Reason, date, replacement.
7.4 Request to Retire Use Case	ABSO; ABUCO approves	6.1 Retire	Join before the use case record update	Reason, sign-off.
7.2 Downstream Impact	ATO	7.1 (assumed)	7.3 (assumed)	Impact; reads AAT and Collibra.
7.3 Approve Retirement	ABSO	7.1, 7.2	Decommission	Approval, authority withdrawn.
Revoke (ADT)	ADT	7.3; the ATO initiates the decommission	7.5	Identities, access, endpoints, tools and test environments revoked.
7.5 Decommission Evidence	ABSO and ABO receive	Revoke (ADT)	7.6	Access revoked, support closed.
7.6 Closure Confirmation	ABSO, ABO joint; then Collibra, AAT and GEAR updates	7.5	Closure gate	Outcomes closed, archival, retention. The use case record update sets the Collibra use case status Retired and the Agent record update sets the Agent status Retired; an abandoned use case also shows Retired, with the reason Abandoned recorded in Asgard.
7.x DLM onboarding	ABSO	7.6 use case record update	Separate request; not part of the closure gate	Data Lifecycle Management onboarding request.
Stage 7 gate	Held for confirmation	To be confirmed	Closure	Stage 7 content is held for confirmation.