fix(psp-1):

- changed `langVersion` to be `cpl/0` only
- changed `lease_status` to `leaseStatus`
- lease freshness is governed by TAP
- no more mentions about the contents of PoAR and DenyReceipts

Author: CMCDragonkai

docs/reference/specifications/psp-1.mdx

@@ -390,8 +390,9 @@ reference these facts by name.
   - ctx: `Map<Str, Term>` - runtime context (e.g.,
     `{"ns":"prod","pod":"runner-42"}`).
 - Optional environment facts (TAP-gated)
-  - lease_status - opaque assurance/freshness input for lease checks (no I/O in
-    the builtin).
+  - leaseStatus - optional TAP-provided evidence used to assess upstream
+    lease/credential freshness. Semantics are TAP-defined; no network I/O occurs
+    during evaluation.
   - TAP MAY require additional environment facts (e.g., provenance labels,
     jurisdiction tags, or digest references) and define how they are obtained
     and verified. PSP-1 does not enumerate these; Programs assert them via
@@ -574,10 +575,11 @@ or a scheme comparator evolved.
 
 ### 6.2 What MUST be pinned
 
-A Grant **MUST** include the following identifiers in its `pins` map. Each
+A Grant MUST include the following identifiers in its `pins` map. Each
 identifier references an immutable snapshot in a registry (see PSP-4):
 
-- **`langVersion`** - the CPL/0 edition string (e.g., `cpl/0@1`).
+- **`langVersion`** - the CPL/0 language generation. For this specification the
+  value MUST be `cpl/0`.
 - **`builtinsId`** - a content-addressed snapshot of the builtin operators in
   use (including each opcode's semantics, type signatures, tightening rules, and
   resource bounds).
@@ -634,7 +636,7 @@ denial.
 
 ### 6.5 Fail-closed conditions
 
-A CEP **MUST** deny if any of the following holds:
+A CEP MUST deny if any of the following holds:
 
 - `builtinsId` is missing, unknown, or cannot be loaded.
 - The Program uses `channelGeq` but `channelLatticeId` is missing or unknown.
@@ -814,10 +816,10 @@ A conforming Grant MUST satisfy all of the following.
      - The bytes for every referenced declaration MUST be bundled in the Grant
        payload; no network fetches at evaluation.
    - `pins`: Registry pins that fix semantics across CEPs and time:
-     - `langVersion`: The CPL/0 language version string (e.g., `"cpl/0@1"` -
-       string form defined in PSP-4).
-     - `builtinsId`: Content-addressed identifier of the Builtins registry
-       snapshot used by the Program.
+   - `langVersion`: The CPL/0 language generation. In this specification the
+     value MUST be `"cpl/0"` when present. The string form is defined in PSP-4.
+   - `builtinsId`: Content-addressed identifier of the Builtins registry
+     snapshot used by the Program.
    - `channelLatticeId`: REQUIRED only if the Program uses `channelGeq`. It MUST
      be omitted if the Program does not call `channelGeq`. When present, it pins
      the channel lattice used to interpret `>=`.
@@ -915,7 +917,7 @@ names.
     "resources:cid:Qr...": "..." // canonical bytes of ResourceSet (if used)
   },
   "pins": {
-    "langVersion": "cpl/0@1",
+    "langVersion": "cpl/0",
     "builtinsId": "cid:builtins@YYYYMMDD",
     "channelLatticeId": "cid:lattice@1", // REQUIRED iff Program uses `channelGeq`
     "schemesSnapshotId": "cid:schemes@YYYYMMDD" // REQUIRED: pinned manifest of scheme comparators
@@ -973,12 +975,12 @@ Grants and transient proof-of-use.
     early (now < iat), subject to TAP clock discipline.
   - If the Program contains ttlOk or withinTime literals, the CEP MUST enforce
     them using iat/now/exp as appropriate.
-  - Effective lifetime: When both `[iat, exp)` and `ttlOk` appear, both MUST
-    pass at the captured `now`. The effective acceptance window is the
-    intersection of these constraints.
-  - If the Grant envelope carries a validity window (not_before/not_after) per
-    PSP-3, the CEP MUST enforce it and, where both apply, MUST enforce the
-    intersection with the Presentation's lifetime.
+  - Effective lifetime: The CEP MUST enforce the intersection of all applicable
+    time windows at the captured `now`. Specifically, the Presentation window
+    `[iat, exp)`, any Grant envelope validity window (`not_before`/`not_after`
+    per PSP-3), and any Program time literals such as `ttlOk` or `withinTime`
+    MUST all succeed. If any one of these constraints fails at `now`,
+    enforcement MUST deny.
   - If the Program does not constrain Presentation lifetime via ttlOk, TAP MAY
     impose a default maximum Presentation TTL.
 - Context
@@ -1133,7 +1135,10 @@ additional discussion of the risks mitigated by syntactic attenuation.
   - issuer(child) MUST equal subject(parent).
   - Each Grant in the chain MUST be written on its issuer's sigchain with valid
     signatures per PSP-3.
-  - prev linkage MUST form a simple path leaf->root; the CEP MUST reject cycles.
+  - All required parent Grants MUST be locally available at enforcement;
+    otherwise the CEP MUST deny. (Pre-enforcement acquisition is TAP-governed.)
+  - `prev` linkage MUST form a simple path from leaf to root; the CEP MUST deny
+    if any digest repeats (cycle detection).
 - Depth and anchors (TAP-governed)
   - TAP MAY set a maximum delegation depth H; the CEP MUST deny when exceeded.
   - Anchoring of the root issuer for the target resource domain (when
@@ -1297,8 +1302,8 @@ remain pure; no network I/O occurs during Program evaluation.
   lease rotation), upstream rotation (leases, credentials, keys) is governed by
   TAP.
 - The CEP MUST enforce any time/freshness constraints asserted by the Program
-  (e.g., withinTime, ttlOk) and any TAP-approved environment facts (e.g.,
-  lease_status) presented at enforcement.
+  (e.g., `withinTime`, `ttlOk`) and any TAP-approved environment facts (e.g.,
+  `leaseStatus`) presented at enforcement.
 - An Access PoAR MAY include a leaseRef/freshness pointer or similar evidence as
   defined by PSP-2. PSP-1 does not mandate an on-wire format for rotation
   artifacts.
@@ -1371,6 +1376,12 @@ Preconditions (TAP-governed, outside evaluation)
      and Presentation windows apply, enforce their intersection; else deny.
    - Check revocation state for the leaf Grant per PSP-3/TAP (locally
      available). If revoked or indeterminate per TAP freshness policy, deny.
+   - If enforcement relies on an upstream lease, credential, or secret from a
+     non-native Source of Authority (e.g., a Bridge/Adapter flow), the CEP MUST
+     evaluate freshness per TAP using only locally available evidence (e.g., a
+     TAP-approved environment fact such as `leaseStatus`). If freshness cannot
+     be established per TAP policy, the CEP MUST deny. PSP-1 does not define the
+     format or acquisition of such evidence.
 4. Verify delegation chain (if applicable)
    - Ensure all required parent Grants are locally available; else deny.
    - For each hop child -> parent:
@@ -1403,7 +1414,7 @@ Preconditions (TAP-governed, outside evaluation)
    - enforcer: Str (CEP identifier/audience)
    - channel: Str (live session profile)
    - ctx: `Map<Str, Term>` (runtime context)
-   - Optional TAP-approved freshness facts (e.g., lease_status), if present
+   - Optional TAP-approved freshness facts (e.g., `leaseStatus`), if present
    - Normalize env.resource using the same scheme comparator semantics used for
      declaration canonicalization; normalization failure -> deny.
 6. Load Program and Declarations from the leaf Grant
@@ -1423,30 +1434,22 @@ Preconditions (TAP-governed, outside evaluation)
      - presenterIs (if used)
    - Enforce type checks; ill-typed literals -> deny.
    - Enforce resource bounds (CPU/steps/memory). Exceeding limits MUST result in
-     deny. (The enforcing CEP SHOULD use an appropriate reason code from the
-     PSP-2 registry to indicate a resource limit or deadline breach.)
+     deny.
    - Unknown builtin, unknown lattice, or unknown scheme comparator required by
      the Program -> deny.
    - Context superset: ctx MUST include all required ctxEq(k, v) literals with
      equal values; else deny.
 8. Decision and receipts (placement-agnostic)
-   - On success:
-     - Allow enforcement per placement/mode (mediate/derive/reveal are defined
-       outside PSP-1).
-     - The enforcing CEP MUST record a decision event for the authorization
-       outcome. If the CEP implements PSP-2 receipts, the enforcing CEP MUST
-       emit an Access PoAR to record the decision. PoARs MUST include
-       `programId`, declaration CIDs, pins (including `schemesSnapshotId`), a
-       minimal evaluation trace (which check/query passed), revocation/freshness
-       decision context, comparator fingerprints, and the enforcer measurement
-       (`adapterRef`).
-   - On failure:
-   - The enforcing CEP MUST record a decision event for the authorization
-     outcome. If the CEP implements PSP-2 receipts, the enforcing CEP MUST emit
-     a DenyReceipt. DenyReceipts MUST include a reason code from the PSP-2
-     registry. As with PoARs, DenyReceipts SHOULD avoid disclosing sensitive
-     detail and SHOULD record enough context for auditors to reconstruct the
-     decision.
+   - Allow enforcement per placement/mode (mediate/derive/reveal are defined
+     outside PSP-1).
+   - The enforcing CEP MUST record a decision event (allow or deny) for every
+     enforcement.
+   - If the implementation supports PSP-2 receipts, it MUST additionally emit
+     the appropriate receipt:
+     - Access PoAR on allow.
+     - DenyReceipt on deny.
+   - The structure and required fields of these receipts are defined in PSP-2.
+     PSP-1 does not define receipt contents.
 
 ### 13.3 Execution Constraints
 
@@ -1461,8 +1464,7 @@ Preconditions (TAP-governed, outside evaluation)
 - Deadlines and budgets
   - The CEP MUST enforce bounded evaluation (CPU/steps/memory). If TAP sets a
     per-request deadline, the CEP MUST abort and deny when the deadline is
-    reached. The enforcing CEP SHOULD log an appropriate reason code as defined
-    by the PSP-2 registry.
+    reached.
 - Closed-world inputs
   - All required inputs (leaf Grant, parent Grants, revocation state) MUST be
     locally available at the start of enforcement; otherwise the CEP MUST deny.
@@ -1554,8 +1556,7 @@ across delegation, and (d) TAP-governed acceptance and deployment hygiene.
 
 - Resource budgets
 - CEPs MUST enforce CPU/steps/memory limits for Program evaluation. Exceeding
-  limits MUST result in deny. The enforcing CEP SHOULD log an appropriate reason
-  code from the PSP-2 registry to indicate a resource or deadline violation.
+  limits MUST result in deny.
 - Input bounds
   - Programs and Declarations MUST remain finite. CEPs SHOULD bound sizes of
     `programBytes`, declaration tables, and `ctx` to mitigate memory/CPU
@@ -1612,9 +1613,9 @@ across delegation, and (d) TAP-governed acceptance and deployment hygiene.
     timing variations in hot paths (especially channelBinding and signature
     checks).
 - Error reporting
-  - When a receipt is emitted, implementations SHOULD include a reason code from
-    the registry defined in PSP-2. Avoid leaking sensitive detail in free-form
-    error messages; audit context belongs in receipts as specified by PSP-2.
+  - Free-form error messages SHOULD NOT leak sensitive details. PSP-1 does not
+    define receipt formats; if receipts are used, their structure is defined by
+    PSP-2.
 
 ### 14.10 Placement-Specific Guidance
 
@@ -1685,7 +1686,7 @@ Declarations (PairSet; canonicalized and content-addressed)
 
 Pins
 
-- `langVersion`: "cpl/0@1"
+- `langVersion`: "cpl/0"
 - `builtinsId`: "cid:builtins@2025-09-01"
 - `channelLatticeId`: "cid:channel-lattice@v1" (required because `channelGeq` is
   used)
@@ -1701,7 +1702,7 @@ Grant (payload only, non-normative)
     "pairs:bafyPairsDev1": "<PairSet-bytes>"
   },
   "pins": {
-    "langVersion": "cpl/0@1",
+    "langVersion": "cpl/0",
     "builtinsId": "cid:builtins@2025-09-01",
     "channelLatticeId": "cid:channel-lattice@v1",
     "schemesSnapshotId": "cid:schemes@2025-09-01"
@@ -1787,7 +1788,7 @@ Declarations (PairSet; canonicalized and content-addressed)
 
 Pins
 
-- `langVersion`: "cpl/0@1"
+- `langVersion`: "cpl/0"
 - `builtinsId`: "cid:builtins@2025-09-01"
 - `channelLatticeId`: "cid:channel-lattice@v1"
 - `schemesSnapshotId`: "cid:schemes@2025-09-01"
@@ -1802,7 +1803,7 @@ Grant (payload only, non-normative)
     "pairs:bafyPairsDbMint1": "<PairSet-bytes>"
   },
   "pins": {
-    "langVersion": "cpl/0@1",
+    "langVersion": "cpl/0",
     "builtinsId": "cid:builtins@2025-09-01",
     "channelLatticeId": "cid:channel-lattice@v1",
     "schemesSnapshotId": "cid:schemes@2025-09-01"
@@ -1858,9 +1859,9 @@ CEP evaluation outline
 - Presentations remain small; do not embed Grant bodies in PSP-1 core. If
   parents aren't local at enforcement, deny (TAP defines pre-enforcement
   hydration or profile-level stapling).
-  - Receipts: PoAR should capture enough to audit the decision (`programId`,
-    declaration CIDs, pins, minimal trace), plus derivation metadata (tokenRef),
-    but never the token itself.
+- Receipts: PoAR should capture enough to audit the decision (`programId`,
+  declaration CIDs, pins, minimal trace), plus derivation metadata (tokenRef),
+  but never the token itself.
 
 ### Example 3: Physical Access - Open a door lock
 
@@ -1894,7 +1895,7 @@ Declarations (PairSet; canonicalized and content-addressed)
 
 Pins
 
-- `langVersion`: "cpl/0@1"
+- `langVersion`: "cpl/0"
 - `builtinsId`: "cid:builtins@2025-09-01"
 - `channelLatticeId`: "cid:channel-lattice@v1"
 - `schemesSnapshotId`: "cid:schemes@2025-09-01"
@@ -1909,7 +1910,7 @@ Grant (payload only, non-normative)
     "pairs:bafyPairsDoor1": "<PairSet-bytes>"
   },
   "pins": {
-    "langVersion": "cpl/0@1",
+    "langVersion": "cpl/0",
     "builtinsId": "cid:builtins@2025-09-01",
     "channelLatticeId": "cid:channel-lattice@v1",
     "schemesSnapshotId": "cid:schemes@2025-09-01"
@@ -1947,8 +1948,7 @@ CEP evaluation outline (resource-side CEP, OT-aware)
    - ttlOk(iat,now,60): true
    - ctxEq("visitorId","door-visit-123"): true
 7. Allow within tight deadline; emit a PoAR if receipts are used (see PSP-2). If
-   a TAP-imposed deadline is exceeded, deny (an appropriate reason code from the
-   PSP-2 registry SHOULD be used).
+   a TAP-imposed deadline is exceeded, deny.
 
 Delegated child (illustrative; equality permitted)
 
@@ -2056,7 +2056,7 @@ the exact set via `builtinsId`.
 `withinTime(now, nbf, exp)` or `inPairSet(action, resource, "cid")`). Builtins
 are **pure, deterministic, and resource-bounded**; they perform no network I/O
 and return Booleans. A Grant's `builtinsId` pins a content-addressed snapshot of
-the builtin catalog. CEPs **MUST** deny on unknown operators or ill-typed
+the builtin catalog. CEPs MUST deny on unknown operators or ill-typed
 invocations.
 
 **Builtin operations summary**
@@ -2228,7 +2228,6 @@ Expected: Chain acceptance; allow only if `now < iat+60` and `ctx.ns="prod"`.
 Setup: Parent has two Checks (AND); Child omits one parent Check.
 
 Expect: Chain verification MUST fail due to a syntactic attenuation violation.
-(Reason code per the PSP-2 registry.)
 
 Inputs (sketch):
 
@@ -2237,7 +2236,7 @@ Parent: (all ( (any (and (ctxEq "ns" "prod")))  (any (and (channelGeq channel "m
 Child:  (all ( (any (and (ctxEq "ns" "prod"))) )) ; second Check missing
 ```
 
-Expected: Deny with an appropriate reason code from the PSP-2 registry.
+Expected: Deny.
 
 #### Example 4 Time Boundaries - half-open edges
 
@@ -2265,8 +2264,7 @@ Expected: Allow (assuming other literals hold); deny if normalization fails.
 Setup: Parent pins `schemesSnapshotId = S1`; Child pins `schemesSnapshotId = S2`
 where `S2 != S1`.
 
-Expect: Deny at chain verification due to a pin mismatch (reason code per the
-PSP-2 registry).
+Expect: Deny at chain verification due to a pin mismatch.
 
 ## 17. References