Working with IT and compliance

IT owns the network the appliance sits in. Compliance owns the question of whether the site can account for what the agent did. E31 Consulting works with both from the first conversation, because an engagement that surprises either of them at the end has been run badly.

What IT decides

The customer's IT team decides the posture: air-gapped, connected only to the systems they already secure, or a mixed estate with both. The practice builds inside that decision. It does not ask for a special exception, a tunnel, or a path out of the building for the engineers' convenience.

IT also provides the segment the engineers work in during a forward-deployed engagement, and decides how that access is granted, supervised, and withdrawn. The practice expects that access to end at handoff and plans the work so that nothing depends on it continuing. The particulars are in do engineers need access to our network.

For connected work, IT names the systems the agent may call. Those become declared routes in the version. IT can read the route list and see that it matches what they approved, and the run record shows every call made over them.

What compliance gets

Compliance teams are used to asking for evidence after the fact and receiving a slide. What they get from a use case built on Czar is the run record: for every run, the version that was running, the material the agent retrieved, the routes it called, and the named role that approved at each marked point.

The practice does not make compliance claims on the customer's behalf and does not describe the record as meeting any particular standard. It describes it as something an auditor can read. What the customer's compliance team does with that is theirs to decide, and they are in a better position to decide it when they have helped design where the approval points go.

Approvals by named roles

Agency governs by bounds and approvals assigned to named roles. The practice asks IT and compliance to help name them. Who may publish a version. Who approves before a result lands in a system of record. Who may widen the corpus the agent reads.

These are the questions a compliance team would ask later anyway. Asking them during the build means the answers are in the version rather than in a policy document the version may not match.

Integrity and provenance

Substrate performs integrity verification on what runs on the appliance. For IT, that means the version running is the version that was published, and a change shows up as a new version with a publishing role attached. For compliance, it means the record can be trusted to describe the thing that actually ran, not a thing that was quietly altered.

The practice does not alter the platform's verification, work around it, or ask the customer to. Engineers work on the same terms as the customer's own publishing roles.

Reviewing before handoff

Before an engagement ends, the practice walks IT and compliance through the operating picture of the final version: who may publish, which model, where a person approves, which systems it may call. They walk through a run in the record from start to finish. They confirm that engineer access has been withdrawn and that no route exists that they did not approve.

This review is not a formality. If IT finds a route they did not expect, or compliance finds an approval point in the wrong place, the version is changed and republished before the handoff is complete.

After the engagement

IT and compliance keep the same visibility they had during the work, because the visibility came from the version and the record, not from the engineers. When the site team publishes a new version, the picture updates and the record continues. Where the customer wants an outside review of a later version, that is a scoped project; see after the engagement: support and the next version. The ordinary review, like the ordinary change, stays with the site.