A pattern I have found useful for small services, internal tools, and projects that benefit from fast iteration is to make the repository itself the lifecycle boundary for the service and its infrastructure.

The basic idea is simple:

Create the Git repository from a specific template, and the necessary infrastructure is provisioned along with it automatically.

I think of the resources associated with a repository as an infrastructure arena: an isolated set of environments, cloud resources, identities, Terraform state, deployment automation, and other service-specific machinery whose lifecycle is tied to that repository.

This is not a pattern I would claim is universally applicable. There are plenty of systems whose infrastructure have a longer lifecycles than any individual application repository, and plenty of organizations where shared resources, cross-service dependencies or more centralized control make sense.

But for the right class of workload, I have found this model makes experimentation and service development substantially cheaper.

The problem

Provisioning a new service usually involves significantly more work than developing the service itself.

Before the first useful line of application code is deployed, someone may need to create a cloud project or account, configure Terraform state, create identities and permissions, establish CI/CD, configure workload identity, create registries, set up deployment infrastructure, and wire all of those things together.

Platform teams often try to solve this by introducing increasingly high-level abstractions, which in many cases result in big modules, multiple infrastructure monorepos or automated workflows.

That can work, but those abstractions often come with a different cost: the platform begins to dictate what an application is supposed to look like. They are usually designed around what infrastructure teams think is an “average” service, yet very few services are actually completely average in practice. The result is often infrastructure that only approximately fits the workload: overprovisioned resources, unnecessary components, and design choices preserved primarily for the sake of uniformity. Opting out may be technically possible, but doing so often means leaving the intended golden path, taking on additional work, and having to justify decisions that would otherwise be perfectly reasonable for the service at hand.

I believe that automating the repetitive parts aggressively while keeping the underlying infrastructure accessible is more scalable, faster to iterate with and often leads to an overall better development experience.

Instead of starting from a large abstraction designed around an imagined average service, the base layer should provide only the essentials that are guaranteed to be common across all services: sensible defaults, security guardrails, lifecycle management, and a working deployment path. From there, teams can opt into additional capabilities as their service requires them.

Those capabilities should themselves be reusable and composable: databases, queues, deployment patterns, observability, workload-specific templates, and other infrastructure pieces that can be stacked together as needed rather than imposed upfront.

The result is closer to a set of interchangeable and reusable components than to a fixed application framework. Start with the smallest universally useful unit as a foundation, add the pieces that actually fit the workload, and retain the ability to build something different when the provided pieces do not.

The repository as the lifecycle root

In this model, engineers create services from repository templates.

A minimal template might be called something like google-cloud-project. Creating a repository from that template is enough to bootstrap the fundamental infrastructure needed by the project.

A GitHub Actions workflow in the template repository triggers a centrally maintained reusable bootstrap workflow when a new repository is created.

Detecting repository creation is slightly more awkward than it should be. There is a create event, but in my experience it does not fire reliably for repositories instantiated from a template. What has worked consistently is triggering on push and gating the bootstrap job on github.event.created, which the push payload sets to true for the initial push into a new repository. Organization-level webhooks or a GitHub App also work and are likely the more robust option at scale, at the cost of running infrastructure outside Actions.

That workflow has access to a tightly scoped bootstrap identity and establishes things such as:

• isolated Terraform state

• project-level cloud resources

• service identities

• IAM bindings to federated workload identities and deployment permissions

• the normal Terraform execution path

• whatever minimum organizational guardrails are required (although these should preferably be inherited from the account or folder level whenever possible)

After bootstrap, the repository manages its own infrastructure through ordinary Terraform.

The obvious objection is that this makes repository creation a privileged operation. If creating a repository provisions cloud projects and identities, what stops a repository from provisioning whatever it wants?

The answer is that the bootstrap identity is not bound to the repository. It is bound to the workflow. GitHub’s OIDC token includes a job_workflow_ref claim identifying the reusable workflow that produced it, and workload identity federation can condition on that claim rather than on repository name. The trust policy says, in effect: I will issue this identity only to tokens minted by this centrally maintained workflow, at this ref.

A newly created repository can therefore invoke the bootstrap and get exactly what the bootstrap grants. It cannot write its own workflow that assumes the same identity, because its own workflow produces a different job_workflow_ref. The privilege lives in code the application team does not control, invoked from a repository they do.

The important part is that each repository gets its own state and its own isolated security boundary. One experimental service does not share a Terraform state file with ten unrelated services. Its infrastructure can be modified, broken, recreated, or destroyed independently.

The repository effectively becomes the root object from which the service hangs. Admittedly, tearing down a service is somewhat less straightforward: reacting to repository deletion requires either a GitHub App or an organization-level webhook capable of receiving the repository deletion event.

Infrastructure allocation as an arena

The analogy I like is an arena allocator. In it, instead of managing the lifecycle of each object independently, many individual allocations are associated with a larger lifetime.

The same idea can be useful for cloud infrastructure.

A developer experimenting with a service should not need to maintain a mental inventory of every type of infrastructure provisioned along with their service: cloud resources, mailing lists, Slack channels, GitHub teams, etc.

Those resources belong to the service arena, which makes experimentation considerably less intimidating.

Composable, rather than prescriptive

The other part of the model that I think matters is composability.

The default template should be minimal, unopinionated and lightweight. It provides good defaults and establishes the lifecycle and security boundaries, but it does not have to become a bespoke internal application framework.

Higher-level templates can then build on top of it. For example, I might have a cloud-run-service-go template built on top of the basic Google Cloud project template. In addition to the normal project bootstrap, it includes:

• a small Hello World application written in Go

• Terraform for the Cloud Run service

• the resources required to build and deploy the application

• a ready-to-use CI/CD pipeline

Creating a repository from that template gives me a working Cloud Run service almost immediately. There is no separate infrastructure provisioning step, no Terraform backend setup, and no need to assemble a deployment pipeline before testing an idea.

But importantly, the template remains a starting point.

If I want a database or queue, I can compose with another centrally maintained Terraform module. Or, if an existing module does not fit my use case, I can define the Terraform resources directly. And if I do not want the higher-level Cloud Run template at all, I can still start from the bare-bones cloud project and build something entirely different.

The abstraction is therefore progressive:

modules → minimal project template → workload-specific templates

Each layer provides additional convenience, but none needs to hide or replace the layer below it.

There is a major difference between a platform that says, “Here is the easiest way to do this,” and one that says, “This is the only way you are allowed to do this.”

I strongly prefer the former.

Centralized machinery, decentralized (but clear) ownership

This pattern also creates what I think is a useful division of responsibility.

Platform or infrastructure teams can centrally maintain the pieces that benefit from standardization:

• bootstrap workflows

• Terraform modules

• identity configuration

• security controls

• CI/CD primitives

• organization-wide defaults

Application teams still own their repositories and can evolve their infrastructure independently.

There is a meaningful difference between understanding that your Cloud Run service has an identity, a Terraform state, and a deployment pipeline, and having to manually construct all three every time you start a project.

Security implications

This model also changes where some of the most important security boundaries live, and it’s important to keep this in mind when adopting this type of platform architecture.

First, the ability to create a repository may now imply the ability to provision infrastructure. If repository creation can automatically trigger bootstrap workflows with privileged cloud identities, repository creation is no longer just a source-control permission. It becomes a general infrastructure operation.

That may be perfectly acceptable, but it should be treated deliberately. Organizations that need tighter control can place additional authorization checks in the GitHub App or bootstrap workflow, restrict which users or teams may create repositories from infrastructure-enabled templates, or host these repositories in a separate organization with more restrictive creation policies.

Second, branch protection becomes a core part of the infrastructure change management security model. Merge rights become deployment rights.

Once Terraform and deployment configuration live inside the repository, the ability to modify protected branches can effectively become the ability to modify the service’s infrastructure. In many cases, changing the Terraform means changing almost everything: identities, permissions, network configuration, databases, deployment targets, and the application itself.

Repository protections therefore become real access controls rather than merely development-process safeguards. Required reviews, CODEOWNERS, protected branches, restricted force pushes, and appropriate controls around automation credentials all matter considerably more under this model.

The same is true of the repository containing centralized workflows. Reusable workflows capable of assuming privileged identities form an important part of the organization’s software and infrastructure supply chain. Changes to those workflows should be treated accordingly: tightly controlled write access, protected branches, careful review, pinned dependencies where appropriate, and strict validation of any inputs that cross the trust boundary between an application repository and a privileged reusable workflow.

The convenience of repository-scoped infrastructure does not eliminate privileged operations. But it does move them into a smaller number of explicit and auditable control points, and those need to be protected as such.

Why I like this model

The main advantage, in my experience, is speed.

The cost of trying and iterating on an idea becomes very low. A developer can create a repository, immediately get an isolated and deployable environment, iterate normally, and discard the entire thing when the experiment is no longer useful.

At the same time, the organization keeps important guardrails around authentication, identity, state isolation, deployment, and resource ownership.

This is a combination that is often surprisingly hard to achieve. Fast developer environments sometimes become loosely governed collections of manually created cloud resources. Highly governed environments sometimes turn every new service into a platform request. Repository-scoped infrastructure provides a useful middle ground.

Not every repository is a service

This pattern should not be interpreted as saying that every repository must correspond to a service. Many repositories clearly do not: shared libraries, documentation, tooling, Terraform modules, reusable workflows, and monorepos are obvious examples.

The point I’m trying to make is that a repository is often a very good lifecycle and ownership boundary for an independently operated service.

For many internal services in particular, I have found little reason to introduce another abstraction between the repository and the workload if the repository model itself remains sufficiently flexible. A service can own its application code, infrastructure definition, deployment configuration, identities, and operational metadata in one place without requiring a separate platform-controlled object to represent it.

There will always be exceptions. Some systems contain several independently deployed services in one repository. Others span several repositories while still representing a single operational system. Shared infrastructure may have a lifecycle entirely independent from application code. A shared production database serving twenty applications should obviously not disappear because one repository was deleted.

However, coupling infrastructure lifecycles across service boundaries should be a deliberate decision, made with a clear ownership model and lifecycle plan. Personally, I would also try to avoid architectures where resources are grouped primarily by their provider (such as a particular cloud or SaaS platform) and their lifecycle is managed collectively. Whenever possible, I prefer resources to follow the lifecycle of the services that actually depend on them.

The core idea is not to force a one-to-one mapping between repositories and services everywhere. It is to recognize that, where the repository already represents the natural unit of ownership and change, it can also serve as the infrastructure lifecycle root.

Cheap creation changes behavior

Perhaps the most important effect of this pattern is not technical.

When services are expensive to create, developers naturally avoid creating them. They extend existing systems, share resources that should not really be shared, or postpone experiments because provisioning another environment feels like too much work.

But when a deployable service is roughly as cheap to create as a repository (and just as easy to discard), the calculus changes. Experiments can actually be experiments. Small services can have small overhead. And infrastructure can become something developers compose when needed rather than something they accumulate and eventually have to clean up.

It sounds like simple question any team should have an immediate answer to.

However, this question is underspecified in ways that most organizations never bother to articulate, and the result is that access reviews produce answers that range from incomplete to meaningless. Not because the teams doing them are necessarily incompetent, but because the industry lacks a shared understanding for what “access” actually means in practice.

The problem with “access”

Suppose you’re asked: who can edit DNS records in Cloud DNS on Google Cloud Platform?

Your first instinct might be to check who has the dns.changes.create permission on the DNS zone. You look at any predefined and custom IAM roles containing that permission, IAM bindings for that resource, find the employees with matching roles, and hand over a list.

Except that list is incomplete in ways you (or your auditor) haven’t scoped.

Maybe a user doesn’t have the permission directly, but they’re in a group that does. Maybe the binding isn’t on the zone itself, but on the project that contains it, or the folder above that project, or the organization above that folder. Maybe the user has no binding anywhere, but they can impersonate a service account that does. Maybe they can impersonate a service account that can impersonate another service account that has access through a group membership inherited from a folder three levels up. Maybe the user has no current access at all, but they possess the power to grant it to themselves at any time: a permission that only wakes up when they decide to edit an IAM policy or role somewhere else.

All of these are real and all of them answer “who has access” differently. However, most access reviews stop looking at the first or second layer.

The root issue is that we’re conflating fundamentally different things under a single word. To have a useful conversation about access, I believe it’s necessary to distinguish between three broad categories: effective access, assumable access, and escalatable access.

The examples throughout this article use Google Cloud Platform because that’s where I work the most daily, but nothing here is GCP-specific. AWS has an arguably more complex IAM system, with largely the same patterns involving IAM roles, SCPs, resource policies, and cross-account role assumption. Azure has management group inheritance, managed identities, and service principal impersonation. Hence, the underlying problem is structural: any system with hierarchical resource organization, group-based policy resolution, and delegated identity mechanisms will produce the same complexity.

Effective access

Effective access is the set of permissions a principal can exercise right now, without performing any intermediate action. The principal navigates to the resource, performs the operation, and it works. No impersonation, no credential exchange, no role modification needed.

This is what most people picture when they hear “access,” but even this category is more complex than it first appears. The principal might hold the permission through any of several mechanisms:

The simplest is a direct binding: the user is bound to a role containing the permission on the resource itself. Then there’s group-mediated access: the user is a member of a group (or a complex nested chain of groups) that holds the binding. On top of this, there’s hierarchy inheritance: the binding exists on an ancestor resource, such as a project, folder, or organization, and propagates down.

These mechanisms are orthogonal and composable: a user might be a member of a group that is a member of another group that has a role binding on a folder, and that binding propagates to a project, which contains the resource. The result is an access path of length four or five, but the access is still effective, meaning the user can exercise the permission immediately, right now, without doing anything first.

The length of the access path matters, but not for whether the access exists. It matters for auditability. A direct binding on a resource is visible, easy to review and more likely to be intentional, while a nested group membership inherited through three layers of resource hierarchy is harder to discover, and more likely to be accidental or ungoverned. Access path length can be a useful proxy to determine how likely the access is unintentional.

Assumable access

Assumable access is when a principal does not have effective access to a resource, but can obtain it by assuming a different identity. The defining operation here is identity impersonation: the principal temporarily becomes another principal and inherits that principal’s effective access in whole or in part.

The most obvious example in GCP is service account impersonation. A user with the iam.serviceAccounts.getAccessToken permission on a service account can mint tokens as that service account. If the service account has effective access to the resource, the user can reach it through impersonation. And just like effective access, the service account’s path to the resource itself might be mediated through groups, inheritance, or both.

This creates two independent path dimensions. The assumable path is the chain of identity assumptions: how does the user reach the target identity? The effective path is the chain from that identity to the resource. The composition of both results in the total access path.

Service account impersonation can also chain. A user impersonates service account A, which can impersonate service account B, which has the role binding. Each hop adds a layer of indirection and, more often than not, a layer of unintentionality.

But impersonation through the IAM API isn’t the only way to assume an identity. Consider a user who can SSH into a VM, or deploy code to a Cloud Run service, or trigger a Cloud Build pipeline. Each of these workloads runs with an attached service account. If the user can execute arbitrary code in a workload’s context, they effectively have access to its credentials. This is identity assumption through compute access rather than through the IAM impersonation API, but the end result is the same: the user acts as the service account.

These paths are harder to enumerate because they cross the boundary between IAM analysis and infrastructure or application analysis. IAM tooling can tell you who can impersonate a service account. Understanding that a user can push code to a Cloud Run service which runs as that service account requires understanding the deployment pipeline, repository permissions, and CI/CD configuration. The access path exists, but because it lives in a different system it’s easy to overlook it.

Where federated identities fit

Identity federation adds another dimension to assumable access. In workload identity federation, an external identity, such as a GitHub Actions runner, an AWS role, or a CI/CD pipeline in another platform, can exchange its native credentials for short-lived GCP credentials. The federation configuration defines which external identities map to which GCP principals.

This means the question of “who has access” can extend outside your cloud boundary entirely. If a GitHub Actions workflow for a specific repository has federated access to a GCP service account, then anyone who can create or modify workflows in that repository effectively has assumable access to whatever that service account can reach. The user’s credential never touches GCP directly: they push a commit to a repository, a workflow runs, it federates into a GCP identity, and that principal has effective access to your resources.

Federated identity is particularly challenging for access reviews because the trust boundary is defined in configuration of the workload identity pool and in an external system’s permission model. You won’t find these paths by examining role bindings just in the resource’s platform alone. You need to trace the federation configuration, understand the external identity provider’s authorization model, and map backward from “who can assume this external identity” all the way to “which principals are able to grant or influence access along that path.”

The AI agent identity problem

This is about to get even more complicated. Cloud providers are introducing first-class identity types for AI agents, and these create entirely new assumable access paths.

Google Cloud’s Vertex AI Agent Engine now supports agent identity as an IAM principal type. Agents get their own principal identifiers in the format principal://TRUST_DOMAIN/NAMESPACE/AGENT_NAME, and you can bind IAM roles to these identities just like you would for users or service accounts. From an access review perspective, this means agents are principals that can hold effective access to resources.

Where they differ from traditional service accounts is in their constraints. Agent identities cannot be directly impersonated by another principal through the IAM API. There are also no downloadable keys to create, rotate, or leak. The credentials are cryptographically bound to the agent's runtime environment on Vertex AI through certificate-bound tokens and mTLS, which means stolen credentials are not replayable outside that context. In practice, they are more restricted service accounts: scoped to a specific workload, tied to its lifecycle, and stripped of the portability that makes service accounts both useful and dangerous. This matters for access analysis because the assumable access path to an agent's permissions doesn't run through impersonation or credential theft. It only runs through the ability to invoke the agent itself, which is a fundamentally different trust boundary.

The assumable access question then becomes: who can invoke the agent? If a user can send requests to an agent, and that agent has IAM permissions to perform actions on resources, the user has indirect access to those resources through the agent. The agent is an intermediary identity, similar in structure to a service account, but with a critical difference: the agent’s behavior is driven by a language model that interprets natural language instructions, not by deterministic code. The blast radius of “access through the agent” is harder to scope because it depends not just on what permissions the agent holds, but on what the agent can be instructed to do.

Agent identity also composes with everything else. An agent might use a service account for some operations, federate into external services for others, and hold direct IAM bindings on GCP resources. Mapping the full access surface of “user can talk to agent” requires tracing through all of these paths.

We are early in understanding what governance looks like for agent identities. But one thing is already clear: any access taxonomy that doesn’t account for non-human, non-deterministic intermediaries is very likely to age poorly.

Escalatable access

The third category is fundamentally different from the first two. Effective access and assumable access describe paths that exist. Escalatable access describes the ability to create paths that don’t exist yet.

A user with resourcemanager.projects.setIamPolicy on a project can add any role binding they want to that project. They might not have dns.changes.create right now, but they can grant it to themselves at any time. For example, a user who can impersonate a service account that has setIamPolicy on a folder can modify IAM bindings on that folder and everything below it. More subtly, a user might be able to modify their own roles: impersonate a service account that has the ability to edit the role definition or IAM policy that applies to the user’s own principal.

This is where I’d argue that access review becomes vulnerability analysis. The access path doesn’t exist yet. The user has to construct it. But if they can construct it, the access is effectively attainable from a security perspective.

Tools like PMapper exist specifically for this kind of analysis. They model IAM as a directed graph and traverse it to find escalation paths: edges that don’t represent current access, but the ability to create it. This is computationally expensive and, in the worst case, the graph of potential escalation paths grows combinatorially.

For most access review purposes, escalatable access is where you draw the line and say “this is a different exercise.” Certifying effective access is a governance activity. Reviewing assumable access is a more sophisticated governance activity. Finding and closing escalatable access paths is a security engineering problem. The vocabulary matters because it lets you be explicit about which problem you’re solving and where the boundary is.

The one exception is privileged access management. PAM and JIT access systems are, by design, sanctioned escalation: a user requests elevated permissions, approval is granted (by a human or a policy), and temporary bindings are created. This is escalatable access that’s been formalized into a workflow with controls around it. When an auditor asks about access, whether PAM grants count depends entirely on whether they’re asking about “access right now” or “access that could exist.”

In conclusion

Without shared vocabulary, every access review is a negotiation. The auditor asks “who has access,” the security team counters with “what do you mean by access,” and both parties waste time arriving at an ad hoc definition that won’t be consistent with the next review or third-party’s interpretation.

With a taxonomy, you can scope the question precisely. “Show me all principals with effective access to production DNS zones” is tractable and well-defined. “Show me all principals with assumable access, including compute-mediated impersonation” is harder but still scoped. “Show me all escalation paths to DNS write access” is a different project entirely.

This vocabulary also gives you a framework for evaluating tooling. Most cloud IAM analysis tools, including the built-in policy analyzers, primarily cover effective access. Some are specifically designed for escalatable access. Almost none handle compute-mediated assumable access or federated identity paths. Knowing which category you’re trying to cover tells you which tools are fit for purpose and where you have gaps.

More importantly, it lets you be honest about what you don’t know. Most organizations think they govern effective access reasonably well, some might even partially cover assumable access through service account reviews, but very few touch escalatable access. That is defensible, as long as it is known, understood, and stated explicitly. Issues arise when partial coverage is treated as a complete picture of access.

You ask what someone is working on. They tell you mostly things you already knew. You then ask if there are blockers. They say no, or mention one, and it gets noted somewhere and the meeting moves on. This happens every morning, or three times a week, or whatever cadence the team has settled on. Everyone is present, but almost no one is really listening.

The problem isn’t the frequency or the length. It’s the structure. It puts the team on the hook for producing information that, in many cases, everyone in the room already has, or that no one in the room actually needs at that moment.

The worst version of this is when someone has to repeatedly announce that nothing has happened on a six-month project that was never going to move this week. That’s not information. That’s management theater at best and a slow tax on morale at worst. But the ritual demands it, so someone performs it.

The setup

I’ve been running my security team’s check-ins differently for the past year or so, and I want to describe the part that I think matters most.

We meet on Mondays, Wednesdays, and Fridays. Wednesdays and Fridays are short syncs, usually under fifteen minutes. Monday is the main meeting and runs for about an hour.

The gap between meetings is intentional: enough time for things to actually move, not so long that anything slips through.

The Monday structure is straightforward: I open with announcements, urgent or unplanned work, kudos where they’re due, and what’s top of mind for me on both the security and business side. Then each person goes through what they’re working on, what they need help with, what they’re stuck on.

None of that is unusual. The part that’s different happens roughly every two weeks, at the end of one of those Monday meetings, after everyone has had their turn.

I go through every project on our pipeline and I state my understanding of its current status. Not as a question. As a statement. I say what I think is happening, what I think the blockers are, what I think the next steps are. The team corrects me where I’m wrong. Mostly, I’m right.

We also run a monthly retrospective focused on team health and process improvements, but it’s separate from this mechanism.

Shifting the burden

The reason it works, I think, comes down to who carries the tracking burden.

In a traditional standup, that burden sits with the team. They’re responsible for surfacing progress, flagging issues, and producing updates on demand. The manager is the receiver. The implicit contract is: I ask, you report, and I follow up if something seems off.

This model inverts the contract. I absorb whatever surfaces naturally in normal conversation or check-ins over the course of two weeks. I don’t prompt for project-level status. I don’t ask “where are we on X?” in sync meetings, ever. Long-running work that hasn’t moved doesn’t need to be announced as unmoved. It surfaces when there’s something worth saying about it.

Then, at the biweekly recap, I carry the synthesis myself. I’m the one who has to demonstrate that I’ve been paying attention. If my understanding is wrong or outdated, that’s on me to correct, not on someone else to have proactively flagged.

The effect on the team is real, even if it’s subtle. Nobody has to say “no progress this week” on a project they haven’t touched, because I’m the one stating the status. The pressure to produce the update disappears. What remains is just the conversation. The team can instead focus exclusively on producing high-value signals.

There’s a flattening effect too. When the manager is the one producing the update rather than extracting it, the dynamic stops feeling like a reporting line and starts feeling more like a team that shares context.

The catch

There’s a prerequisite worth being honest about: this only works if the manager is actually engaged. The biweekly recap isn’t a technique for reducing your own involvement. It’s a forcing function for maintaining it. You have to be absorbing what people say in normal conversation accurately enough to reconstruct the state of the entire project pipeline every two weeks. If you’re not doing that, the recap falls apart immediately and you’ve just created a new awkward meeting format.

I would argue that engagement is the job anyway. Knowing the current state of your team’s work, understanding why things are moving or not, and being able to communicate that clearly to stakeholders is not a bonus feature of good management. It’s the baseline. This mechanic just makes it visible and creates a regular moment where you have to prove it to yourself and your team.

The upstream benefit

One more thing worth naming: it helps me upstream as much as it helps the team. I’m regularly synthesizing project status in a form that’s ready to communicate to stakeholders. The biweekly recap isn’t just a check-in tool. It’s also how I keep my own model current and accurate enough to answer questions quickly when someone above me asks.

I’m not claiming this is novel or scientifically validated. My sample size is one and every team is different. Other people have almost certainly arrived at versions of this and built better systems around it. But it has worked well enough that the mechanism is worth describing: Don’t ask. Absorb. Carry. Read it back. Let your team correct you.

The correction is the update. The absence of interrogation is the point.