COR
Open Standards
Six core standards, COR-1 to COR-6, covering the six aspects of operations that fail most readily and most need a common language across organisations; they follow a definite order of dependency and are not parallel.
Six Core Standards
| Number | Standard | What it covers |
|---|---|---|
| COR-1 | Operational Documentation and Traceability | Where authority for a document sits, the single-source principle, the minimum requirement for recording reasons and decisions, versioning and revision procedure |
| COR-2 | Configuration Baselines and Drift Detection | How the target configuration is described, the requirement to compare live state against target, the grading of drift and time limits for handling it |
| COR-3 | Change Gates and Risk Grading | Risk grading of changes, criteria for where a gate belongs, requirement for prior review of irreversible work |
| COR-4 | The Boundary Between AI and Human Work | Distinguishing capability boundaries from authorisation boundaries, credential handling boundaries, the list of work requiring human decision and its criteria |
| COR-5 | Data Classification and Processing Control | Data sensitivity classification, the applicability matrix for processing services, requirements for cross-border and cross-organisation data flow |
| COR-6 | Multi-Tenant Isolation Verification | Classification of isolation claims, the corresponding tests, and the principles for handling a failed verification |
How the Standards Relate
The six are not parallel; they have a definite order of dependency. COR-1 is the foundation of them all — without a traceable documentation framework, whether the other five are being followed cannot be verified. COR-2 builds on COR-1, because a target configuration is itself a document requiring an owner of authority. COR-3 depends on COR-2, because the risk grading of a change must be judged against the target configuration.
COR-4 and COR-5 address boundary problems along two dimensions — the performer and the data — and refer to each other. COR-6 is the concrete application of the first five in a multi-tenant setting, with the added requirement that claims be verified by testing.
A Note on COR-4
Its core contribution is separating two boundaries long conflated: the capability boundary (technically impossible) and the authorisation boundary (possible but not permitted).
The distinction has practical consequences. When the two sit on one list, the disappearance of a capability boundary through technical progress removes the authorisation boundary along with it — because the list says only "a person does this", not which kind of reason applies. COR-4 requires every item of human work to state its boundary type, and to be reviewed rather than automatically released when a capability boundary disappears.
The other core content is the credential handling boundary. The standard requires distinguishing access credentials from application secrets, on the test of whether, if this secret leaked, the holder could impersonate someone — anything that can impersonate a person or a machine is an access credential and must be generated by a person; anything that is merely a service-to-service password is an application secret, which automation may generate provided its value never enters records, reports or version control.
The standard specifically notes that the test is what it can sign, not which configuration file it happens to sit in.