Point
Checks govern writing, not authority
Atlas-local Checks add requirements to an already-authorized edit without redefining core meaning or requiring audit machinery for every change.
- Posture
- asserted
- Lifecycle
- active
Local policy can demand evidence, Area placement, prose, or review beyond the shared format. It cannot alter what a Point identity or context record means. Every applicable active required Check must be verified before claiming compliance; missing evidence or evaluator capability is not a pass.
An ordinary edit does not require a recorded baseline or a separate approval workflow. When a project requests an audit, the existing report contract captures the exact baseline, change set, subjects, Check revisions, evidence, and evaluator. The dedicated Meta-Atlas evaluator remains an example of that audit path rather than a mandatory architecture for all agents.
Checks remain outside Maps because policy is not mapped context. Neither a Check nor its result grants operations beyond the caller's existing permissions.
Checks and reviewThis separates local verification requirements from optional reporting machinery during ordinary Atlas edits.
AuthorityChecks can reject a proposed write but cannot authorize reading, execution, publication, or deployment.
Interoperability requires stable Check syntax and evaluation output without turning project-specific policies into a generic validator profile.
The portable contract defines Check files and a versioned evaluation result so tools can exchange policy outcomes. Each project still supplies its evaluator and evidence. Structural and resolved validators cannot report a project Check as passed merely because its Markdown shape is valid.
Conformance evidenceStable Check syntax and evaluation output let consumers exchange compliance evidence without importing project policy into format validity.
Extension boundaryProject-specific Check meaning remains an extension evaluated separately from standard validator profiles.
Active required Checks make repository policy explicit and fail closed, while their evaluators must state exactly what automation can prove.
A policy cannot claim semantic quality when its evaluator only counts files or checks for nonempty prose. Each Check pass reported by the Meta-Atlas evaluator includes nonempty evidence tied to the exact requirement, baseline, change set, subjects, and Check revision. Meta-Atlas Checks are written around measurable invariants, and any judgment outside those invariants remains a documented human review rather than an automated pass.
Contract changeActive required Checks make project policy part of the reviewed contract chain rather than an informal convention.
Claim disciplineEach evaluator must bound its pass claim to inspected evidence so compliance is not mistaken for truth.
Security and authorityFail-closed evaluation must still operate only within caller-granted authority.
The dedicated evaluator reports exact subjects, revisions, evidence, and fail-closed outcomes for Meta-Atlas policy after resolved validation succeeds.
The Meta-Atlas evaluator registers each active policy explicitly. An unknown active Check returns unable, draft or retired policy returns not-applicable, and an active required Check must pass before the aggregate result is compliant. The evaluator’s measurable claims are narrower than human semantic review.
Self-hostingThe dedicated evaluator makes Meta-Atlas local policy executable after the standard model validates.
Repository gatesSubject revisions, evidence, and fail-closed outcomes let the release gate verify policy at the reviewed revision.