Roadmap: From Read-Only Posture to Constrained Write

The production Lambda Action Group registry for Digital Coworker contains no write functions. Part 4 described why: no write tool registered means no write operation possible, regardless of what the user asks or what a prompt injection attempts. The boundary is not a policy setting — it is the absence of a thing that would have to be deliberately added.

This post is about what adding it will require. Not a timeline. The preconditions — the conditions that must hold before a write Lambda function can enter the registry — examined as an architectural question.

What the read-only boundary deferred#

The case for deferring write capability had two components. Market readiness: OT customers do not grant write access to a system they have not run in advisory mode long enough to calibrate. Architecture: autonomous write operations in OT require a deterministic validation layer, and building it correctly is a project within a project.

The product lead characterised semi-autonomous configuration as “a dangerous use case.” The danger is not a bad recommendation. The danger is that the system through which the change passes might not catch a bad configuration before it executes. The LLM is not the safety mechanism. The validation layer is.

A “confirm and apply” intermediate step was considered and excluded. It still requires the deterministic validation layer. Human confirmation is a social check; it does not substitute for graph-based topology impact analysis.

What Phase 2 must actually deliver#

Part 4 named three components of the Phase 2 validation layer:

1. Graph-based topology impact validation. The validation layer must compute topology impact using the same NetworkX graph traversal the diagnostic agents use — for a VLAN reassignment, an MRP ring reconfiguration, a port isolation update. The relevant question is not “is this a valid configuration?” but “does applying this change to the current network state break any path the topology depends on?”

2. Rule-based operational constraint checking. IEC 62439-2 (MRP) defines the ring topology state machine and role assignments; IEEE 802.1Q (VLAN) defines valid membership and forwarding behaviour. The validation layer must check a proposed change against these constraints through deterministic rule evaluation — the same principle that drives the anti-hallucination architecture for diagnostics. Correctness requirements in OT cannot be delegated to probabilistic reasoning.

3. Explicit verification of redundancy paths. MRP’s self-healing assumes a single physical fault. A misconfigured device — a duplicate ring manager, a bridged ring port — removes that assumption. The validation layer must verify, before applying any change, that no redundancy path the topology depends on — active or standby — will be impaired. This is a gate, not a runtime check.

These are Lambda functions — deterministic, testable, versioned — not instructions in the agent’s prompt. The agent generates a proposed change via a tool call; the validation layer certifies or rejects before the change executes.

What Phase 3 will require beyond the validation layer#

A validated change is not yet a safe change. Phase 3 requires governance scaffolding that read-only operation does not need.

Diff-level audit completeness. The audit gap in Part 6 — CloudTrail records that an instruction changed, not what changed — is a manageable limitation for advisory operation. For write-enabled operation it is a disqualifier. The audit trail must record, before and after every proposed change: the exact configuration delta, the validation verdict, the approval identity, and the originating session identifier. This is not CloudTrail alone. It is an application-level change log that must exist before the first write Lambda is registered.

Blast-radius constraints registered as architecture. Which network paths are within scope for autonomous modification? Which are never touched? Those constraints must be registered as Lambda-level refusals — enforced before the validation layer runs — not as instructions the agent is told to follow. A runtime policy against out-of-scope paths is the same soft-constraint failure mode Part 4 described for the read-only boundary. The constraint must be structural.

Approval boundary sequencing. A proposed change requires two distinct reviews: topology consequence (the network engineer) and risk model (the safety or operations lead). Those are not the same review. The architecture must sequence them — topology first, risk second — without collapsing them into a single approval action that neither role can fully own. This requires state management across what are otherwise stateless Lambda invocations.

Rollback paths that are tested, not assumed. Write errors require a rollback; advisory errors do not. Phase 3 requires pre-execution snapshot capture and a tested restore path that does not assume the change is reversible by reverting it. Some OT configuration changes are not trivially reversible; treat every write as potentially irreversible until the rollback test says otherwise.

The cost of moving from recommending to acting#

In read-only operation, the three-way tension between diagnostic correctness, operational speed, and safety guarantee is manageable — the human carries the execution risk, so correctness and safety can both hold.

In constrained write operation, the triangle tightens at every point. Validation latency. Approval chain time. Blast-radius scope reduction. Audit overhead. Each is the cost of the move. Attempting Phase 3 before the four preconditions are in place is not a shortcut. It is deploying a partial system and calling it complete.

Closing the series#

This is the eighth deep-dive in the Digital Coworker series (plus two introductory posts). The arc: mechanism (Part 1) → discipline (Part 4) → human surface (Part 6) → external scrutiny (Part 7) → preconditions for what comes next.

New to the series: The Digital Coworker Stack at a Glance maps the full architecture with pointers to each deep-dive.

The governance question this architecture creates — why governance frameworks for advisory AI do not automatically scale to write-enabled AI — is addressed on javatask.systems: Governance That Scales with Autonomy.

The trust model and Phase 2 specification this post builds on: Read-Only Posture Is the Trust Model.

The audit gap that becomes a Phase 3 precondition here: Bedrock Agents: What Domain Experts Actually Edit.

The read-only posture as trust model, examined after one month of scrutiny: The Four Markers of AI-Native: What Held Up at One Month.

This post is part of the Digital Coworker series.