fix(psp-1): definition for local availability, renamed 11.9 to extensibility, renamed 5.8 to TAP constraints, the renames avoid overloading "profiles" as a keyword

Author: CMCDragonkai

docs/reference/specifications/psp-1.mdx

@@ -101,6 +101,13 @@ and only when, they appear in all capitals, as shown here.
   delegation chain to a resource domain.
 - **Access PoAR:** The Proof-of-Action receipt written by the enforcing CEP
   (defined in PSP-2).
+- **Local Availability:** An artifact (Grant, revocation state, lattice
+  snapshot, comparator or other evaluation input) is "locally available" at
+  enforcement if it can be accessed by the CEP without network I/O, within
+  TAP-defined resource bounds, at the moment verification begins.
+  Pre-enforcement resolution (governed by TAP) MAY populate local storage before
+  verification starts. During Program evaluation, any missing required input
+  MUST cause denial.
 - **TAP (Threat and Acceptance Policy):** The acceptance policy that governs
   time discipline, chain depth and anchoring requirements, resolver/mirroring
   allowances, replay defenses, and other deployment-specific constraints used by
@@ -536,14 +543,15 @@ action in A over any resource in R"). Use PairSet when the matrix is irregular.
 - CEPs MUST verify subset relations hop-by-hop along the delegation chain using
   the same normalization and comparators; failures or unknowns MUST cause deny.
 
-### 5.8 Specification Profiles
+### 5.8 TAP constraints
 
-This specification standardizes exactly three Declaration kinds: PairSet,
-ActionSet, ResourceSet. Specification Profiles MAY further constrain their usage
-(e.g., disallow ResourceSet for certain actions) or prescribe default
-comparators per scheme. A CEP MUST deny if a Program references a declaration
-kind not supported by the active profile or if a required comparator is not
-available.
+PSP-1 standardizes exactly three declaration kinds: PairSet, ActionSet and
+ResourceSet. Deployments may impose additional acceptance rules via their Threat
+& Acceptance Policy (TAP). For example, a TAP MAY disallow certain declaration
+kinds for particular actions or restrict which resource schemes are acceptable.
+When TAP forbids a declaration kind or a required scheme comparator is
+unavailable, the CEP MUST deny. These TAP constraints do not alter the semantics
+defined in this specification.
 
 ## 6. Semantic Pinning
 
@@ -1245,16 +1253,17 @@ A CEP MUST deny if any of the following holds:
     `{ ("secret:read","vault:.../team/*"), ("secret:derive","vault:.../svcX") }`
   - Child PairSet = `{ ("secret:read","vault:.../team/appA") }` (valid subset).
 
-### 11.9 Profiles
-
-- Profiles MAY introduce additional declaration kinds or builtins, but MUST
-  preserve monotonicity, purity, bounded evaluation, and pinned semantics
-  (`builtinsId`) with chain-wide compatibility. When a profile introduces new
-  declaration kinds (e.g., a PolicyBundle), child bundles MUST be subsets of
-  parent bundles under the registry-defined comparator for that kind.
-- Anchoring mechanics and acceptance policies are TAP-governed. PSP-1 is
-  agnostic to how anchors are established; CEPs enforce anchoring only when TAP
-  declares an applicable method for the resource domain.
+### 11.9 Extensibility
+
+Future Polykey Standard Proposals MAY introduce additional declaration kinds or
+builtins. Such extensions MUST preserve the core invariants of PSP-1:
+monotonicity, purity, bounded evaluation and pinned semantics (`builtinsId`)
+with chain-wide compatibility. When a new specification introduces a declaration
+kind (for example, a policy bundle), derived grants MUST ensure that child
+bundles are subsets of parent bundles under the registry-defined comparator for
+that kind. Anchoring mechanics and acceptance policies remain TAP-governed; this
+specification remains agnostic to how anchors are established, and CEPs enforce
+anchoring only when TAP declares an applicable method for the resource domain.
 
 ## 12. Revocation and Rotation