Point
Context does not authorize actions
A Point, Reference, relation, or Check can establish relevance and policy but cannot grant access, publication, deployment, or execution authority.
- Posture
- asserted
- Lifecycle
- active
Mapped context can say that a file, service, deployment, credential, or external source is relevant. A Check can say what evidence an authorized change must produce. Neither statement grants permission to inspect, modify, retrieve, publish, deploy, or execute the named target.
Every processor and integration must receive operational authority independently from its caller and environment. External URIs remain identifiers unless another authorized component retrieves them. Local inspection remains bounded, and ambiguous or incomplete access fails closed rather than being inferred from semantic importance.
AuthorityRelevance and policy edges stop at interpretation; operational permissions must come from the caller and surrounding system.
Ecosystem growth must not normalize integrations that infer credentials, retrieval consent, publication rights, or execution permission from Atlas records.
Each host defines its own capability and rights boundary. A portable Atlas can describe external services and sources, but an integration must request access independently and must preserve third-party terms instead of treating a citation or CC0 project license as blanket permission.
IntegrationTool integrations must obtain credentials and operation consent from their caller rather than infer them from relevance.
Commons and rightsReuse rights over Atlas material do not imply permission to retrieve, republish, or execute referenced material.
Security and release policy must preserve the separation between semantic importance, project policy, and externally granted operational capability.
Reviewers must reject wording or tooling that treats a Point direction as an executable instruction, a Reference as retrieval consent, or Check compliance as deployment approval. These boundaries remain requirements even when an operation would be convenient or the target is inside the same repository.
Security and authoritySecurity policy keeps semantic relevance, compliance policy, and operational capability as separate sources.
Release stewardshipRelease approval cannot convert Atlas context into publication, deployment, or credential authority.
Included processors stay within bounded local reads, while deployment remains a separate operator-authorized application.
The processors treat Atlas data as input to parsing and model construction only. Outside-boundary relative References are reported without being read, external URIs remain strings, and incomplete inspection prevents a conformance result rather than triggering a broader access attempt. The separate Cloudflare application runs only when an operator invokes its local or deployment command and supplies any required credentials independently.
Reference validatorLocal-only parsing and no external retrieval or execution keep the reference processor inside its validation authority.
Absent and planned toolsThe explicit Cloudflare application keeps deployment authority outside Atlas records and processing tools.
Core semantic records do not establish publication eligibility; only an explicit profile selects source units, while operations remain build-authorized.
A Point can identify relevant material without making that material publishable. Publication eligibility begins only when a profile names the exact source record or registered Resource.
The profile does not supply file access, retrieval, credentials, deployment authority, or proof of enforcement. A portal build must receive those capabilities from its own environment and must keep its generated corpus inside the selected boundary.
Current publication boundaryThe current profile contract adds source eligibility without adding publication fields or operations to core context.
Non-disclosureCompilation, retrieval, serving, and deployment remain responsibilities of the build environment rather than semantic records.