ChiralityHow it works
You already have a system for this.
Your organisation names who drafts, who checks and who accepts. It has hold points, issue states and boundaries between disciplines, and that machinery governs every deliverable except the parts a model wrote. This page is for the person who runs it.
The mapping
Your existing controls, applied to work an agent did.
Each row is written into the published workflows and looked for by the review scans. The application enforces the folder and the permission; the rest is the method, kept by the files and by the people who use them.
- The boundary a discipline works inside
An agent gets one job, one folder, and one limit on what it may alter. The folder and the permission are enforced by the application; the job is bounded by its brief.
- Hold points
Where a decision is properly yours, the work stops and waits for you by name. The workflow asks, and nothing in it advances until you answer.
- Drafter, checker, approver
Three separate acts by separate parties, exactly as on paper today. The drafter may now be an agent, and the record says so. Checking and approving stay with people.
- Issue states
An approval attaches to the exact content that was in front of the person who gave it. Alter the content and the approval lapses.
- Provenance, and the refusal to invent
A substantive claim carries the file and section it came from, or an explicit marker saying it has none. A missing value is recorded as missing and raised as an open item; it is never default-filled. Missing information is treated as a finding.
- Disagreement goes to a person
When two sources conflict, both are recorded with their references and the conflict is put in front of somebody with a decision to make. Silently reconciled sources are how a wrong number survives three reviews.
- Every claim carries its standing
Fact, assumption, proposal or unknown. Your checker reads the assumptions and the unknowns first, which is the entire mechanism by which checking gets cheaper.
- The design file
What ran, which files it drew on, what it changed and who accepted it accumulate in the project folder while the work happens.
How the work divides
Underneath your roles, the agents divide too.
One assistant that attempts everything holds up until a job is large enough to need dividing, and at exactly that point nobody can say who was responsible for which part. So the agents are separated the same way your people are.
-
Supervising architect
Aligns with you, selects and supervises managers, and brings decisions back. Holds no write scope of its own.
-
Manager
Turns direction into plans and sealed briefs, delegates bounded work, validates what comes back, and escalates what it cannot decide.
-
Specialist
Executes one bounded objective and returns outputs plus evidence. It does not delegate, and it cannot widen its own remit.
Why files
Because the person who asks will not have been in the room.
Six months after a job closes, the question is where a number came from, what was assumed, and who decided that was acceptable. So it is kept as plain files in the project, in the version control your organisation already trusts. A colleague can pick up work that was never explained to them, and none of it rests on a chat session that has ended or a service that may not be there in three years.
A method kept as files is an asset you hold. The same capability kept as configuration inside somebody’s platform is one you rent.