Drafting from a policy
Turn a document your risk committee already approved into contracts, with every check citing the sentence it enforces.
Drafting from a policy
Rules that already exist and are already agreed beat rules invented in a meeting. If the team has a policy document, a runbook or a procedure, that is where the contract should come from.
coco author --from procedures/onboarding.md --action approve_customer
coco author --describe "no export over 500 rows without a compliance officer"| Flag | What it does |
|---|---|
--from | A policy document, or a folder of them |
--describe | The rule in a sentence, when there is no document |
--constraints | What must hold, in the team's own words |
--action | The action this governs |
--out | Where to write the draft |
--model --base-url --timeout | Which model drafts it, and how long to wait |
Authoring needs an API key in COCO_API_KEY or DASHSCOPE_API_KEY. This is the
one path where a model is involved, and it runs once at drafting time. Nothing
about the runtime check involves a model.
Know what leaves the machine before you run it. The drafting call sends your policy
text to the model behind that key, over the endpoint --base-url names, so point
it at a model host your team has already approved. If the policy cannot leave your
infrastructure at all, skip drafting and write the contract by hand, because the
whole shape is in Writing a contract and the gate treats a
hand-written contract identically.
What the draft carries
Every drafted check cites the policy file and quotes the sentence it enforces, so your reviewer can hold the draft against the policy line by line. A rule whose citation does not match the sentence is a rule to reject, and that is easier to see than to argue about.
The three validations
A draft passes three checks before anyone reads it, and none of them involves a model.
The schema has to parse. Every rule has to compile under the safe expression subset. And the draft is run against fixtures, so you can see which way it decides before anyone relies on it.
A rule that fails any of the three is rejected rather than written. That is the point of validating at drafting time, because a rule that only fails at runtime fails in the middle of someone's work.
Drafts enforce nothing
Drafts land in ~/.coco/packs/_drafts/, and the compiler does not load that
directory. A draft cannot be enforced by accident.
Read each one, edit it, and move it into a set the mandate names when you are satisfied. Moving it is a person's decision, never the tool's.
mv ~/.coco/packs/_drafts/kyc.approve_customer.yaml ~/.coco/packs/kyc/
coco compileWhat the model is and is not doing
The model reads a document and proposes a rule. It does not decide anything at runtime, it does not approve its own draft, and it cannot move a draft into enforcement.
A drafted contract is a first pass at the thing your compliance team already believes. Treat it as a draft written by somebody who read the policy once, because that is what it is.
Next
- Writing a contract for the shape you are reviewing
- Behavioural contracts for why the format is small