Vertex Macro | Financial Cloud Cloud · AWS Re:cap
AWS Re:cap 04: Controlled End-to-End Automation of Government Development with Cloud Agents
For government technology advisers, digital-government leads, data and security officers, digital-government architects, and large SOE technology decision-makers.
Public governance and value: Decision positioning
Answer why first, then talk about technology
This page focuses on "Public governance and value" at the decision positioning stage. The core content covers public service time, one-stop completion, frontline burden, and public rights. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are administrative discretion, appeals, accountability attribution, and continuity of essential services. The accountable executive must confirm public value, unacceptable consequences, the accountable owner, data legality, and whether the process can be improved before using a model. If the problem cannot be measured, an agent should not be the answer. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: wrap the agent in an event-driven workflow; the model handles only unstructured judgement; high-risk outcomes are subject to veto by the accountable owner. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
At review, require a one-page decision card listing the baseline, target, affected groups, human veto, appeal, degradation, and exit. Any blank field means the project is not yet ready to be initiated. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Public governance and value: Architecture implementation
Turn principles into system boundaries, then talk about technology
This page focuses on "Public governance and value" at the architecture implementation stage. The core content covers public service time, one-stop completion, frontline burden, and public rights. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are administrative discretion, appeals, accountability attribution, and continuity of essential services. Draw the lines of responsibility across events, data, identity, models, agents, tools, workflows, humans, and observability. A deterministic engine controls sequence, retry, timeout, compensation, and approval. The model must not lower policy on its own. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: wrap the agent in an event-driven workflow; the model handles only unstructured judgement; high-risk outcomes are subject to veto by the accountable owner. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
Walk through the three most recent real tasks step by step. For every read, write, and publish, specify permission, input structure, stop conditions, and evidence location. Simulate injection, missing data, and tool failure. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Public governance and value: Acceptance and operations
Prove sustainability with evidence, then talk about technology
This page focuses on "Public governance and value" at the acceptance and operations stage. The core content covers public service time, one-stop completion, frontline burden, and public rights. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are administrative discretion, appeals, accountability attribution, and continuity of essential services. Establish normal, boundary, adversarial, historical, and surge tests. Preserve versions of the model, prompts, knowledge, tools, and human decisions. Account time, quality, cost, and intervention against successful tasks. Do not treat call volume as a substitute for benefit. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: wrap the agent in an event-driven workflow; the model handles only unstructured judgement; high-risk outcomes are subject to veto by the accountable owner. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
Go live with a limited scope and feature flags. Set stop thresholds for error, latency, cost, leakage, and complaints. Review failure samples weekly. Review jointly each month across business, technology, security, and finance. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Public governance and value: Take-home practice
Take the method back to the organisation, then talk about technology
This page focuses on "Public governance and value" at the take-home practice stage. The core content covers public service time, one-stop completion, frontline burden, and public rights. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are administrative discretion, appeals, accountability attribution, and continuity of essential services. Start with high-frequency, low-risk, reversible work. Establish a baseline and evidence in read-only or draft mode, then accept controlled tools, and only then consider high-impact actions. Every exception must have an approver, a time limit, and a remedy. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: wrap the agent in an event-driven workflow; the model handles only unstructured judgement; high-risk outcomes are subject to veto by the accountable owner. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
After photographing this page, ask immediately: who is accountable, where the data comes from, which versions of the model and prompt are in use, what the tool did, what the approval was based on, how failure is stopped, how rollback works, and whether service can continue if the vendor leaves. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Requirements and task engineering: Decision positioning
Answer why first, then talk about technology
This page focuses on "Requirements and task engineering" at the decision positioning stage. The core content covers requirement sources, affected services, prohibited scope, acceptance criteria, and accountable owners. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are vague descriptions, scope creep, incorrect assumptions, and inconsistent cross-department definitions. The accountable executive must confirm public value, unacceptable consequences, the accountable owner, data legality, and whether the process can be improved before using a model. If the problem cannot be measured, an agent should not be the answer. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: separate known facts, inferences, gaps, and recommendations, and decompose the plan into nodes with inputs, outputs, dependencies, and stop conditions. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
At review, require a one-page decision card listing the baseline, target, affected groups, human veto, appeal, degradation, and exit. Any blank field means the project is not yet ready to be initiated. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Requirements and task engineering: Architecture implementation
Turn principles into system boundaries, then talk about technology
This page focuses on "Requirements and task engineering" at the architecture implementation stage. The core content covers requirement sources, affected services, prohibited scope, acceptance criteria, and accountable owners. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are vague descriptions, scope creep, incorrect assumptions, and inconsistent cross-department definitions. Draw the lines of responsibility across events, data, identity, models, agents, tools, workflows, humans, and observability. A deterministic engine controls sequence, retry, timeout, compensation, and approval. The model must not lower policy on its own. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: separate known facts, inferences, gaps, and recommendations, and decompose the plan into nodes with inputs, outputs, dependencies, and stop conditions. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
Walk through the three most recent real tasks step by step. For every read, write, and publish, specify permission, input structure, stop conditions, and evidence location. Simulate injection, missing data, and tool failure. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Requirements and task engineering: Acceptance and operations
Prove sustainability with evidence, then talk about technology
This page focuses on "Requirements and task engineering" at the acceptance and operations stage. The core content covers requirement sources, affected services, prohibited scope, acceptance criteria, and accountable owners. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are vague descriptions, scope creep, incorrect assumptions, and inconsistent cross-department definitions. Establish normal, boundary, adversarial, historical, and surge tests. Preserve versions of the model, prompts, knowledge, tools, and human decisions. Account time, quality, cost, and intervention against successful tasks. Do not treat call volume as a substitute for benefit. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: separate known facts, inferences, gaps, and recommendations, and decompose the plan into nodes with inputs, outputs, dependencies, and stop conditions. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
Go live with a limited scope and feature flags. Set stop thresholds for error, latency, cost, leakage, and complaints. Review failure samples weekly. Review jointly each month across business, technology, security, and finance. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Requirements and task engineering: Take-home practice
Take the method back to the organisation, then talk about technology
This page focuses on "Requirements and task engineering" at the take-home practice stage. The core content covers requirement sources, affected services, prohibited scope, acceptance criteria, and accountable owners. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are vague descriptions, scope creep, incorrect assumptions, and inconsistent cross-department definitions. Start with high-frequency, low-risk, reversible work. Establish a baseline and evidence in read-only or draft mode, then accept controlled tools, and only then consider high-impact actions. Every exception must have an approver, a time limit, and a remedy. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: separate known facts, inferences, gaps, and recommendations, and decompose the plan into nodes with inputs, outputs, dependencies, and stop conditions. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
After photographing this page, ask immediately: who is accountable, where the data comes from, which versions of the model and prompt are in use, what the tool did, what the approval was based on, how failure is stopped, how rollback works, and whether service can continue if the vendor leaves. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Code, testing, and release: Decision positioning
Answer why first, then talk about technology
This page focuses on "Code, testing, and release" at the decision positioning stage. The core content covers isolated branches, diff review, multi-layer testing, artefact signing, and progressive release. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are generated defects, unauthorised commits, supply-chain vulnerabilities, self-attested tests, and failed rollback. The accountable executive must confirm public value, unacceptable consequences, the accountable owner, data legality, and whether the process can be improved before using a model. If the problem cannot be measured, an agent should not be the answer. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: the agent must not push directly to the main branch; after compile, unit, contract, integration, and security scans pass, different roles approve a limited-traffic release. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
At review, require a one-page decision card listing the baseline, target, affected groups, human veto, appeal, degradation, and exit. Any blank field means the project is not yet ready to be initiated. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Code, testing, and release: Architecture implementation
Turn principles into system boundaries, then talk about technology
This page focuses on "Code, testing, and release" at the architecture implementation stage. The core content covers isolated branches, diff review, multi-layer testing, artefact signing, and progressive release. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are generated defects, unauthorised commits, supply-chain vulnerabilities, self-attested tests, and failed rollback. Draw the lines of responsibility across events, data, identity, models, agents, tools, workflows, humans, and observability. A deterministic engine controls sequence, retry, timeout, compensation, and approval. The model must not lower policy on its own. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: the agent must not push directly to the main branch; after compile, unit, contract, integration, and security scans pass, different roles approve a limited-traffic release. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
Walk through the three most recent real tasks step by step. For every read, write, and publish, specify permission, input structure, stop conditions, and evidence location. Simulate injection, missing data, and tool failure. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Code, testing, and release: Acceptance and operations
Prove sustainability with evidence, then talk about technology
This page focuses on "Code, testing, and release" at the acceptance and operations stage. The core content covers isolated branches, diff review, multi-layer testing, artefact signing, and progressive release. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are generated defects, unauthorised commits, supply-chain vulnerabilities, self-attested tests, and failed rollback. Establish normal, boundary, adversarial, historical, and surge tests. Preserve versions of the model, prompts, knowledge, tools, and human decisions. Account time, quality, cost, and intervention against successful tasks. Do not treat call volume as a substitute for benefit. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: the agent must not push directly to the main branch; after compile, unit, contract, integration, and security scans pass, different roles approve a limited-traffic release. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
Go live with a limited scope and feature flags. Set stop thresholds for error, latency, cost, leakage, and complaints. Review failure samples weekly. Review jointly each month across business, technology, security, and finance. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Code, testing, and release: Take-home practice
Take the method back to the organisation, then talk about technology
This page focuses on "Code, testing, and release" at the take-home practice stage. The core content covers isolated branches, diff review, multi-layer testing, artefact signing, and progressive release. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are generated defects, unauthorised commits, supply-chain vulnerabilities, self-attested tests, and failed rollback. Start with high-frequency, low-risk, reversible work. Establish a baseline and evidence in read-only or draft mode, then accept controlled tools, and only then consider high-impact actions. Every exception must have an approver, a time limit, and a remedy. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: the agent must not push directly to the main branch; after compile, unit, contract, integration, and security scans pass, different roles approve a limited-traffic release. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
After photographing this page, ask immediately: who is accountable, where the data comes from, which versions of the model and prompt are in use, what the tool did, what the approval was based on, how failure is stopped, how rollback works, and whether service can continue if the vendor leaves. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Identity, permissions, and tools: Decision positioning
Answer why first, then talk about technology
This page focuses on "Identity, permissions, and tools" at the decision positioning stage. The core content covers user identity, agent identity, short-lived credentials, whitelisted tools, and risk classification. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are prompt injection, privilege expansion, arbitrary commands, long-lived secrets, and high-risk writes. The accountable executive must confirm public value, unacceptable consequences, the accountable owner, data legality, and whether the process can be improved before using a model. If the problem cannot be measured, an agent should not be the answer. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: classify read, write, deploy, delete, payment, and authorisation; a tool gateway validates parameters, task, data classification, and approval status. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
At review, require a one-page decision card listing the baseline, target, affected groups, human veto, appeal, degradation, and exit. Any blank field means the project is not yet ready to be initiated. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Identity, permissions, and tools: Architecture implementation
Turn principles into system boundaries, then talk about technology
This page focuses on "Identity, permissions, and tools" at the architecture implementation stage. The core content covers user identity, agent identity, short-lived credentials, whitelisted tools, and risk classification. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are prompt injection, privilege expansion, arbitrary commands, long-lived secrets, and high-risk writes. Draw the lines of responsibility across events, data, identity, models, agents, tools, workflows, humans, and observability. A deterministic engine controls sequence, retry, timeout, compensation, and approval. The model must not lower policy on its own. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: classify read, write, deploy, delete, payment, and authorisation; a tool gateway validates parameters, task, data classification, and approval status. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
Walk through the three most recent real tasks step by step. For every read, write, and publish, specify permission, input structure, stop conditions, and evidence location. Simulate injection, missing data, and tool failure. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Identity, permissions, and tools: Acceptance and operations
Prove sustainability with evidence, then talk about technology
This page focuses on "Identity, permissions, and tools" at the acceptance and operations stage. The core content covers user identity, agent identity, short-lived credentials, whitelisted tools, and risk classification. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are prompt injection, privilege expansion, arbitrary commands, long-lived secrets, and high-risk writes. Establish normal, boundary, adversarial, historical, and surge tests. Preserve versions of the model, prompts, knowledge, tools, and human decisions. Account time, quality, cost, and intervention against successful tasks. Do not treat call volume as a substitute for benefit. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: classify read, write, deploy, delete, payment, and authorisation; a tool gateway validates parameters, task, data classification, and approval status. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
Go live with a limited scope and feature flags. Set stop thresholds for error, latency, cost, leakage, and complaints. Review failure samples weekly. Review jointly each month across business, technology, security, and finance. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Identity, permissions, and tools: Take-home practice
Take the method back to the organisation, then talk about technology
This page focuses on "Identity, permissions, and tools" at the take-home practice stage. The core content covers user identity, agent identity, short-lived credentials, whitelisted tools, and risk classification. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are prompt injection, privilege expansion, arbitrary commands, long-lived secrets, and high-risk writes. Start with high-frequency, low-risk, reversible work. Establish a baseline and evidence in read-only or draft mode, then accept controlled tools, and only then consider high-impact actions. Every exception must have an approver, a time limit, and a remedy. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: classify read, write, deploy, delete, payment, and authorisation; a tool gateway validates parameters, task, data classification, and approval status. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
After photographing this page, ask immediately: who is accountable, where the data comes from, which versions of the model and prompt are in use, what the tool did, what the approval was based on, how failure is stopped, how rollback works, and whether service can continue if the vendor leaves. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Data, knowledge, and memory: Decision positioning
Answer why first, then talk about technology
This page focuses on "Data, knowledge, and memory" at the decision positioning stage. The core content covers data classification, source, version, validity period, original permissions, and retention period. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are expired policy, unauthorised documents, cross-department mixing, sensitive leakage, and unbounded memory. The accountable executive must confirm public value, unacceptable consequences, the accountable owner, data legality, and whether the process can be improved before using a model. If the problem cannot be measured, an agent should not be the answer. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: govern task memory, preferences, and organisational knowledge separately; retrieval must return citations, and refuse with a stated gap when no basis is found. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
At review, require a one-page decision card listing the baseline, target, affected groups, human veto, appeal, degradation, and exit. Any blank field means the project is not yet ready to be initiated. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Data, knowledge, and memory: Architecture implementation
Turn principles into system boundaries, then talk about technology
This page focuses on "Data, knowledge, and memory" at the architecture implementation stage. The core content covers data classification, source, version, validity period, original permissions, and retention period. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are expired policy, unauthorised documents, cross-department mixing, sensitive leakage, and unbounded memory. Draw the lines of responsibility across events, data, identity, models, agents, tools, workflows, humans, and observability. A deterministic engine controls sequence, retry, timeout, compensation, and approval. The model must not lower policy on its own. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: govern task memory, preferences, and organisational knowledge separately; retrieval must return citations, and refuse with a stated gap when no basis is found. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
Walk through the three most recent real tasks step by step. For every read, write, and publish, specify permission, input structure, stop conditions, and evidence location. Simulate injection, missing data, and tool failure. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Data, knowledge, and memory: Acceptance and operations
Prove sustainability with evidence, then talk about technology
This page focuses on "Data, knowledge, and memory" at the acceptance and operations stage. The core content covers data classification, source, version, validity period, original permissions, and retention period. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are expired policy, unauthorised documents, cross-department mixing, sensitive leakage, and unbounded memory. Establish normal, boundary, adversarial, historical, and surge tests. Preserve versions of the model, prompts, knowledge, tools, and human decisions. Account time, quality, cost, and intervention against successful tasks. Do not treat call volume as a substitute for benefit. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: govern task memory, preferences, and organisational knowledge separately; retrieval must return citations, and refuse with a stated gap when no basis is found. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
Go live with a limited scope and feature flags. Set stop thresholds for error, latency, cost, leakage, and complaints. Review failure samples weekly. Review jointly each month across business, technology, security, and finance. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Data, knowledge, and memory: Take-home practice
Take the method back to the organisation, then talk about technology
This page focuses on "Data, knowledge, and memory" at the take-home practice stage. The core content covers data classification, source, version, validity period, original permissions, and retention period. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are expired policy, unauthorised documents, cross-department mixing, sensitive leakage, and unbounded memory. Start with high-frequency, low-risk, reversible work. Establish a baseline and evidence in read-only or draft mode, then accept controlled tools, and only then consider high-impact actions. Every exception must have an approver, a time limit, and a remedy. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: govern task memory, preferences, and organisational knowledge separately; retrieval must return citations, and refuse with a stated gap when no basis is found. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
After photographing this page, ask immediately: who is accountable, where the data comes from, which versions of the model and prompt are in use, what the tool did, what the approval was based on, how failure is stopped, how rollback works, and whether service can continue if the vendor leaves. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Cloud-native, multi-cloud, and cost: Decision positioning
Answer why first, then talk about technology
This page focuses on "Cloud-native, multi-cloud, and cost" at the decision positioning stage. The core content covers model gateway, event orchestration, containers, security observability, data portability, and cost per completed service. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are vendor lock-in, service stacking, regional failure, hidden labour cost, and failed exit. The accountable executive must confirm public value, unacceptable consequences, the accountable owner, data legality, and whether the process can be improved before using a model. If the problem cannot be measured, an agent should not be the answer. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: compose capabilities such as Bedrock, EventBridge, Step Functions, Lambda, and ECS/EKS; retain open interfaces, export, and degradation paths. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
At review, require a one-page decision card listing the baseline, target, affected groups, human veto, appeal, degradation, and exit. Any blank field means the project is not yet ready to be initiated. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Cloud-native, multi-cloud, and cost: Architecture implementation
Turn principles into system boundaries, then talk about technology
This page focuses on "Cloud-native, multi-cloud, and cost" at the architecture implementation stage. The core content covers model gateway, event orchestration, containers, security observability, data portability, and cost per completed service. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are vendor lock-in, service stacking, regional failure, hidden labour cost, and failed exit. Draw the lines of responsibility across events, data, identity, models, agents, tools, workflows, humans, and observability. A deterministic engine controls sequence, retry, timeout, compensation, and approval. The model must not lower policy on its own. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: compose capabilities such as Bedrock, EventBridge, Step Functions, Lambda, and ECS/EKS; retain open interfaces, export, and degradation paths. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
Walk through the three most recent real tasks step by step. For every read, write, and publish, specify permission, input structure, stop conditions, and evidence location. Simulate injection, missing data, and tool failure. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Cloud-native, multi-cloud, and cost: Acceptance and operations
Prove sustainability with evidence, then talk about technology
This page focuses on "Cloud-native, multi-cloud, and cost" at the acceptance and operations stage. The core content covers model gateway, event orchestration, containers, security observability, data portability, and cost per completed service. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are vendor lock-in, service stacking, regional failure, hidden labour cost, and failed exit. Establish normal, boundary, adversarial, historical, and surge tests. Preserve versions of the model, prompts, knowledge, tools, and human decisions. Account time, quality, cost, and intervention against successful tasks. Do not treat call volume as a substitute for benefit. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: compose capabilities such as Bedrock, EventBridge, Step Functions, Lambda, and ECS/EKS; retain open interfaces, export, and degradation paths. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
Go live with a limited scope and feature flags. Set stop thresholds for error, latency, cost, leakage, and complaints. Review failure samples weekly. Review jointly each month across business, technology, security, and finance. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Cloud-native, multi-cloud, and cost: Take-home practice
Take the method back to the organisation, then talk about technology
This page focuses on "Cloud-native, multi-cloud, and cost" at the take-home practice stage. The core content covers model gateway, event orchestration, containers, security observability, data portability, and cost per completed service. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are vendor lock-in, service stacking, regional failure, hidden labour cost, and failed exit. Start with high-frequency, low-risk, reversible work. Establish a baseline and evidence in read-only or draft mode, then accept controlled tools, and only then consider high-impact actions. Every exception must have an approver, a time limit, and a remedy. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: compose capabilities such as Bedrock, EventBridge, Step Functions, Lambda, and ECS/EKS; retain open interfaces, export, and degradation paths. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
After photographing this page, ask immediately: who is accountable, where the data comes from, which versions of the model and prompt are in use, what the tool did, what the approval was based on, how failure is stopped, how rollback works, and whether service can continue if the vendor leaves. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Reliability, observability, and incidents: Decision positioning
Answer why first, then talk about technology
This page focuses on "Reliability, observability, and incidents" at the decision positioning stage. The core content covers end-to-end SLO, trace identifiers, business telemetry, idempotency, RTO, RPO, and post-incident review. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are model unavailability, tool timeout, retry storms, log leakage, and absent approvers. The accountable executive must confirm public value, unacceptable consequences, the accountable owner, data legality, and whether the process can be improved before using a model. If the problem cannot be measured, an agent should not be the answer. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: chain technical, agent, and business telemetry; on failure, fall back to rules, search, or a human, preserve evidence, and rehearse recovery. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
At review, require a one-page decision card listing the baseline, target, affected groups, human veto, appeal, degradation, and exit. Any blank field means the project is not yet ready to be initiated. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Reliability, observability, and incidents: Architecture implementation
Turn principles into system boundaries, then talk about technology
This page focuses on "Reliability, observability, and incidents" at the architecture implementation stage. The core content covers end-to-end SLO, trace identifiers, business telemetry, idempotency, RTO, RPO, and post-incident review. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are model unavailability, tool timeout, retry storms, log leakage, and absent approvers. Draw the lines of responsibility across events, data, identity, models, agents, tools, workflows, humans, and observability. A deterministic engine controls sequence, retry, timeout, compensation, and approval. The model must not lower policy on its own. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: chain technical, agent, and business telemetry; on failure, fall back to rules, search, or a human, preserve evidence, and rehearse recovery. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
Walk through the three most recent real tasks step by step. For every read, write, and publish, specify permission, input structure, stop conditions, and evidence location. Simulate injection, missing data, and tool failure. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Reliability, observability, and incidents: Acceptance and operations
Prove sustainability with evidence, then talk about technology
This page focuses on "Reliability, observability, and incidents" at the acceptance and operations stage. The core content covers end-to-end SLO, trace identifiers, business telemetry, idempotency, RTO, RPO, and post-incident review. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are model unavailability, tool timeout, retry storms, log leakage, and absent approvers. Establish normal, boundary, adversarial, historical, and surge tests. Preserve versions of the model, prompts, knowledge, tools, and human decisions. Account time, quality, cost, and intervention against successful tasks. Do not treat call volume as a substitute for benefit. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: chain technical, agent, and business telemetry; on failure, fall back to rules, search, or a human, preserve evidence, and rehearse recovery. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
Go live with a limited scope and feature flags. Set stop thresholds for error, latency, cost, leakage, and complaints. Review failure samples weekly. Review jointly each month across business, technology, security, and finance. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Reliability, observability, and incidents: Take-home practice
Take the method back to the organisation, then talk about technology
This page focuses on "Reliability, observability, and incidents" at the take-home practice stage. The core content covers end-to-end SLO, trace identifiers, business telemetry, idempotency, RTO, RPO, and post-incident review. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are model unavailability, tool timeout, retry storms, log leakage, and absent approvers. Start with high-frequency, low-risk, reversible work. Establish a baseline and evidence in read-only or draft mode, then accept controlled tools, and only then consider high-impact actions. Every exception must have an approver, a time limit, and a remedy. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: chain technical, agent, and business telemetry; on failure, fall back to rules, search, or a human, preserve evidence, and rehearse recovery. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
After photographing this page, ask immediately: who is accountable, where the data comes from, which versions of the model and prompt are in use, what the tool did, what the approval was based on, how failure is stopped, how rollback works, and whether service can continue if the vendor leaves. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Procurement, acceptance, and accountability: Decision positioning
Answer why first, then talk about technology
This page focuses on "Procurement, acceptance, and accountability" at the decision positioning stage. The core content covers outcome-based specifications, data policy, SLA, security testing, a responsibility matrix, and exit assistance. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are judging by demonstration only, averages that mask high risk, opaque subcontracting, and incapacity after contract termination. The accountable executive must confirm public value, unacceptable consequences, the accountable owner, data legality, and whether the process can be improved before using a model. If the problem cannot be measured, an agent should not be the answer. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: accept correctness, safety, fairness, performance, reliability, cost, and governance together; bind payment to verifiable milestones and exit drills. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
At review, require a one-page decision card listing the baseline, target, affected groups, human veto, appeal, degradation, and exit. Any blank field means the project is not yet ready to be initiated. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Procurement, acceptance, and accountability: Architecture implementation
Turn principles into system boundaries, then talk about technology
This page focuses on "Procurement, acceptance, and accountability" at the architecture implementation stage. The core content covers outcome-based specifications, data policy, SLA, security testing, a responsibility matrix, and exit assistance. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are judging by demonstration only, averages that mask high risk, opaque subcontracting, and incapacity after contract termination. Draw the lines of responsibility across events, data, identity, models, agents, tools, workflows, humans, and observability. A deterministic engine controls sequence, retry, timeout, compensation, and approval. The model must not lower policy on its own. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: accept correctness, safety, fairness, performance, reliability, cost, and governance together; bind payment to verifiable milestones and exit drills. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
Walk through the three most recent real tasks step by step. For every read, write, and publish, specify permission, input structure, stop conditions, and evidence location. Simulate injection, missing data, and tool failure. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Procurement, acceptance, and accountability: Acceptance and operations
Prove sustainability with evidence, then talk about technology
This page focuses on "Procurement, acceptance, and accountability" at the acceptance and operations stage. The core content covers outcome-based specifications, data policy, SLA, security testing, a responsibility matrix, and exit assistance. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are judging by demonstration only, averages that mask high risk, opaque subcontracting, and incapacity after contract termination. Establish normal, boundary, adversarial, historical, and surge tests. Preserve versions of the model, prompts, knowledge, tools, and human decisions. Account time, quality, cost, and intervention against successful tasks. Do not treat call volume as a substitute for benefit. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: accept correctness, safety, fairness, performance, reliability, cost, and governance together; bind payment to verifiable milestones and exit drills. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
Go live with a limited scope and feature flags. Set stop thresholds for error, latency, cost, leakage, and complaints. Review failure samples weekly. Review jointly each month across business, technology, security, and finance. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Procurement, acceptance, and accountability: Take-home practice
Take the method back to the organisation, then talk about technology
This page focuses on "Procurement, acceptance, and accountability" at the take-home practice stage. The core content covers outcome-based specifications, data policy, SLA, security testing, a responsibility matrix, and exit assistance. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are judging by demonstration only, averages that mask high risk, opaque subcontracting, and incapacity after contract termination. Start with high-frequency, low-risk, reversible work. Establish a baseline and evidence in read-only or draft mode, then accept controlled tools, and only then consider high-impact actions. Every exception must have an approver, a time limit, and a remedy. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: accept correctness, safety, fairness, performance, reliability, cost, and governance together; bind payment to verifiable milestones and exit drills. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
After photographing this page, ask immediately: who is accountable, where the data comes from, which versions of the model and prompt are in use, what the tool did, what the approval was based on, how failure is stopped, how rollback works, and whether service can continue if the vendor leaves. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Hong Kong digital government success cases: Decision positioning
Answer why first, then talk about technology
This page focuses on "Hong Kong digital government success cases" at the decision positioning stage. The core content covers smart city governance, iAM Smart, CorpID, consent-based data exchange, an AI+ public-service catalogue, and a cross-department shared platform. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are identity authorisation, data purpose, cross-border flow, multi-vendor fragmentation, and publicly perceptible outcomes. The accountable executive must confirm public value, unacceptable consequences, the accountable owner, data legality, and whether the process can be improved before using a model. If the problem cannot be measured, an agent should not be the answer. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: use shared identity, a data catalogue, an exchange gateway, shared cloud, and security standards as the agent foundation, and verify by service penetration and usage outcomes. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
At review, require a one-page decision card listing the baseline, target, affected groups, human veto, appeal, degradation, and exit. Any blank field means the project is not yet ready to be initiated. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Hong Kong digital government success cases: Architecture implementation
Turn principles into system boundaries, then talk about technology
This page focuses on "Hong Kong digital government success cases" at the architecture implementation stage. The core content covers smart city governance, iAM Smart, CorpID, consent-based data exchange, an AI+ public-service catalogue, and a cross-department shared platform. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are identity authorisation, data purpose, cross-border flow, multi-vendor fragmentation, and publicly perceptible outcomes. Draw the lines of responsibility across events, data, identity, models, agents, tools, workflows, humans, and observability. A deterministic engine controls sequence, retry, timeout, compensation, and approval. The model must not lower policy on its own. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: use shared identity, a data catalogue, an exchange gateway, shared cloud, and security standards as the agent foundation, and verify by service penetration and usage outcomes. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
Walk through the three most recent real tasks step by step. For every read, write, and publish, specify permission, input structure, stop conditions, and evidence location. Simulate injection, missing data, and tool failure. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Hong Kong digital government success cases: Acceptance and operations
Prove sustainability with evidence, then talk about technology
This page focuses on "Hong Kong digital government success cases" at the acceptance and operations stage. The core content covers smart city governance, iAM Smart, CorpID, consent-based data exchange, an AI+ public-service catalogue, and a cross-department shared platform. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are identity authorisation, data purpose, cross-border flow, multi-vendor fragmentation, and publicly perceptible outcomes. Establish normal, boundary, adversarial, historical, and surge tests. Preserve versions of the model, prompts, knowledge, tools, and human decisions. Account time, quality, cost, and intervention against successful tasks. Do not treat call volume as a substitute for benefit. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: use shared identity, a data catalogue, an exchange gateway, shared cloud, and security standards as the agent foundation, and verify by service penetration and usage outcomes. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
Go live with a limited scope and feature flags. Set stop thresholds for error, latency, cost, leakage, and complaints. Review failure samples weekly. Review jointly each month across business, technology, security, and finance. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Hong Kong digital government success cases: Take-home practice
Take the method back to the organisation, then talk about technology
This page focuses on "Hong Kong digital government success cases" at the take-home practice stage. The core content covers smart city governance, iAM Smart, CorpID, consent-based data exchange, an AI+ public-service catalogue, and a cross-department shared platform. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are identity authorisation, data purpose, cross-border flow, multi-vendor fragmentation, and publicly perceptible outcomes. Start with high-frequency, low-risk, reversible work. Establish a baseline and evidence in read-only or draft mode, then accept controlled tools, and only then consider high-impact actions. Every exception must have an approver, a time limit, and a remedy. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: use shared identity, a data catalogue, an exchange gateway, shared cloud, and security standards as the agent foundation, and verify by service penetration and usage outcomes. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
After photographing this page, ask immediately: who is accountable, where the data comes from, which versions of the model and prompt are in use, what the tool did, what the approval was based on, how failure is stopped, how rollback works, and whether service can continue if the vendor leaves. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Five-year plan and regional innovation: Decision positioning
Answer why first, then talk about technology
This page focuses on "Five-year plan and regional innovation" at the decision positioning stage. The core content covers Northern Metropolis, Loop cooperation, AI+, smart healthcare, smart mobility, green transition, and the talent ecosystem. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are policy still under consultation, cross-border rules, industry-academia-research gaps, data sensitivity, and technology projects detached from livelihoods. The accountable executive must confirm public value, unacceptable consequences, the accountable owner, data legality, and whether the process can be improved before using a model. If the problem cannot be measured, an agent should not be the answer. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: first convert planning directions into service outcomes, process changes, data needs, annual milestones, and accountable departments, then choose models and platforms. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
At review, require a one-page decision card listing the baseline, target, affected groups, human veto, appeal, degradation, and exit. Any blank field means the project is not yet ready to be initiated. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Five-year plan and regional innovation: Architecture implementation
Turn principles into system boundaries, then talk about technology
This page focuses on "Five-year plan and regional innovation" at the architecture implementation stage. The core content covers Northern Metropolis, Loop cooperation, AI+, smart healthcare, smart mobility, green transition, and the talent ecosystem. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are policy still under consultation, cross-border rules, industry-academia-research gaps, data sensitivity, and technology projects detached from livelihoods. Draw the lines of responsibility across events, data, identity, models, agents, tools, workflows, humans, and observability. A deterministic engine controls sequence, retry, timeout, compensation, and approval. The model must not lower policy on its own. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: first convert planning directions into service outcomes, process changes, data needs, annual milestones, and accountable departments, then choose models and platforms. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
Walk through the three most recent real tasks step by step. For every read, write, and publish, specify permission, input structure, stop conditions, and evidence location. Simulate injection, missing data, and tool failure. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Five-year plan and regional innovation: Acceptance and operations
Prove sustainability with evidence, then talk about technology
This page focuses on "Five-year plan and regional innovation" at the acceptance and operations stage. The core content covers Northern Metropolis, Loop cooperation, AI+, smart healthcare, smart mobility, green transition, and the talent ecosystem. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are policy still under consultation, cross-border rules, industry-academia-research gaps, data sensitivity, and technology projects detached from livelihoods. Establish normal, boundary, adversarial, historical, and surge tests. Preserve versions of the model, prompts, knowledge, tools, and human decisions. Account time, quality, cost, and intervention against successful tasks. Do not treat call volume as a substitute for benefit. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: first convert planning directions into service outcomes, process changes, data needs, annual milestones, and accountable departments, then choose models and platforms. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
Go live with a limited scope and feature flags. Set stop thresholds for error, latency, cost, leakage, and complaints. Review failure samples weekly. Review jointly each month across business, technology, security, and finance. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.
Five-year plan and regional innovation: Take-home practice
Take the method back to the organisation, then talk about technology
This page focuses on "Five-year plan and regional innovation" at the take-home practice stage. The core content covers Northern Metropolis, Loop cooperation, AI+, smart healthcare, smart mobility, green transition, and the talent ecosystem. These are not supplementary documents. They are preconditions for whether an agent may enter a production system. The team must convert an abstract vision into concrete services, data flows, permissions, accountability, and acceptance. Fluency of model answers, demonstration speed, or vendor brand must not be treated as pass criteria.
Evidence this domain must show
The main risks are policy still under consultation, cross-border rules, industry-academia-research gaps, data sensitivity, and technology projects detached from livelihoods. Start with high-frequency, low-risk, reversible work. Establish a baseline and evidence in read-only or draft mode, then accept controlled tools, and only then consider high-impact actions. Every exception must have an approver, a time limit, and a remedy. Reviewers should require that raw inputs, citation sources, versions, tool calls, human decisions, costs, and exceptions are all traceable. If any step can be explained only orally, the control has not truly landed.
Derive controls from risk
The engineering main line is: first convert planning directions into service outcomes, process changes, data needs, annual milestones, and accountable departments, then choose models and platforms. Every control must name an owner, an inspection frequency, an evidence location, and a failure response. A control without an owner does not exist. A rollback that has never been rehearsed is not a rollback. An exception without a time limit eventually becomes a permanent back door.
Field operation and acceptance statement
After photographing this page, ask immediately: who is accountable, where the data comes from, which versions of the model and prompt are in use, what the tool did, what the approval was based on, how failure is stopped, how rollback works, and whether service can continue if the vendor leaves. Write the requirements of this page into requirements, tests, approvals, and operations manuals, and use the same data set for normal, boundary, and failure cases. Success is not that the agent always completes the task. It is that when the agent is uncertain, exceeds authority, or a service fails, it can stop, explain, notify the accountable owner, and fall back safely to a human.