wip: additional PSP

docs/reference/specifications/PSP-0.mdx

@@ -0,0 +1 @@
+Always use camelCase for field names. See our prettier configuration.

docs/reference/specifications/PSP-2 - Receipt Model.mdx

@@ -0,0 +1 @@
+# PSP-2 - Receipt Model

docs/reference/specifications/PSP-3 - Sigchain and Envelope.mdx

@@ -0,0 +1,66 @@
+# PSP-3 - Sigchain and Envelope
+
+Provided by the Envelope (per SIGCHAIN-01):
+
+- jti (JWT ID): The primary, unique identifier for this claim on its sigchain
+  (e.g., an IdSortable/UUIDv7).
+- iss (Issuer): The DID of the Principal (P) issuing the Grant.
+- sub (Subject): The DID of the Subject (S) receiving the Grant.
+- exp (Expiration Time): The timestamp after which the Grant is invalid.
+- iat (Issued At) / nbf (Not Before): Timestamps for issuance and validity start
+  time.
+- prevClaimId / prevDigest: Linkage to the previous claim on the sigchain, as
+  defined by SIGCHAIN-01.
+- Signatures: At least one valid signature per SIGCHAIN-01 (e.g., JWS with
+  protected headers). Multiple signatures are allowed.
+- Canonical digest: A content-addressed hash of the canonicalized claim MUST be
+  derivable per SIGCHAIN-01 for stable cross-references (e.g., grant_ref).
+  Implementations MAY materialize/store it; it is not a payload field.
+
+Provided by the Grant Payload (PCAP-01):
+
+- typ (Type): A string identifying the claim type. For a Grant, this MUST be
+  "ClaimGrant".
+- action: A single verb string (e.g., "deploy:to_env").
+- resource: A single resource identifier (e.g., a URI).
+- bind: The Bind object containing capability constraints.
+
+Normative rules:
+
+- Grants MUST be written on the issuer's (P's) sigchain.
+- The envelope MUST include iss, sub, exp, and a valid signature per
+  SIGCHAIN-01; Presentations beyond exp are invalid.
+- payload.typ MUST be "ClaimGrant".
+- A Grant MUST carry exactly one action (verb) and exactly one resource.
+- action MUST reference a registered verb; for attenuation, child.action MUST
+  equal parent.action unless the verb registry defines a subset sub-verb
+  accepted by TAP.
+- resource MUST conform to a registered scheme; for attenuation, resource.child
+  MUST be a subset of resource.parent per the scheme's subset relation.
+- bind MUST be enforceable by CEPs and MUST be included as a bind_snapshot in
+  the Access PoAR (PRSC-01).
+- Required Bind dimensions declared by the verb's registry entry (e.g., nbf/exp,
+  channel, policyRef) MUST be present; otherwise the CEP MUST deny.
+- Unknown verbs, unknown resource schemes, or unresolvable scheme comparators
+  MUST cause deny.
+- CEPs MUST check revocation status (see Revocation) before enforcement.
+- Presentations MUST reference the Grant via its canonical digest (grant_ref)
+  derived per SIGCHAIN-01.
+
+Recommended fields:
+
+- aud: DID or array of DIDs of acceptable enforcers (e.g., `"did:pk:P"` or
+  `["did:pk:P","did:pk:R"]`)
+- purpose: semantic hash or descriptor of intent (e.g., `"sha256:artifact-H"`,
+  `"door-visit-123"`)
+- context: structured k/v describing runtime context (e.g.,
+  `{"pod":"runner-xyz","ns":"ci"}`)
+- nbf, exp: NumericDate (Unix seconds) defining the enforceable window; if the
+  envelope also carries nbf/exp, CEPs MUST enforce the intersection
+- ttl: maximum Presentation lifetime in seconds (e.g., 120)
+- maxUses: optional counter for total uses (enforced only by stateful CEPs)
+- geofence / net: optional constraints (e.g., CIDR, region, location)
+- channel: required channel-binding profile id (e.g., "tls_exporter:v1",
+  "dpop:v1")
+- policyRef: OPTIONAL content-addressed “affordance bundle” for mediated flows
+  (e.g., Allowed-Surface); structure/enforcement in CEP/BA spec

docs/reference/specifications/PSP-4 - Registries.mdx

@@ -0,0 +1 @@
+# PSP-4 - Registries

docs/reference/specifications/PSP-5 - CEP and Bridge Adapter.mdx

@@ -0,0 +1 @@
+# PSP-5 - CEP and Bridge Adapter

docs/reference/specifications/PSP-6 - TAP and RAM.mdx

@@ -0,0 +1 @@
+# PSP-6 - TAP and RAM

docs/reference/wedges/README.md

@@ -0,0 +1,92 @@
+# Wedge Portfolio
+
+Trust Graphs
+
+Multiplayer Utility - the layer 5 software-system.
+
+> The Artifact is Everything: The core gap in the market is not another
+> dashboard or security agent. The gap is the lack of signed, time-anchored,
+> portable, and settlement-grade receipts. Your competitors are building USB
+> agents, but they are still thinking in terms of "logs," not "evidence." This
+> is your key differentiator. The Wedge is Real and It's Top-Down: Your initial
+> intuition was right, but your time at SEMICON and analyzing the OT landscape
+> has confirmed a critical detail: the adoption of "Receipt Rails" in high-value
+> industrial sectors will be driven top-down by compliance and standards, not
+> bottom-up by individual developers. The key is to align with emerging
+> standards like ISA/IEC 62443 and SEMI E187/E188 and sell to the Tier-1 fabs,
+> OSATs, and utilities who are forced to comply. The "singleplayer utility" is
+> selling them a tool that makes this compliance auditable and less painful.
+
+- Blockchain Wallet Reputation
+- Email Sender Reputation
+- Sayari Supply Chain Trust
+- DevOps Authority Tracing
+
+- Energy DR/curtailment
+  - Verifier: utility/auditor/insurer
+  - Value: kW×Δt “receipts” → faster payouts, lower disputes
+  - T1R: 4–8 weeks (site + meter/EMS hookup)
+- Fisheries/cold-chain
+  - Verifier: export compliance, buyer’s QA, insurer
+  - Value: catch + temperature receipts → export finance, fewer chargebacks
+  - T1R: 6–10 weeks (boat + sensor pack + buyer)
+- Disaster logistics corridors (UAV/USV + mesh)
+  - Verifier: NGO/agency auditors
+  - Value: movement/hand-off receipts → audit time −50%
+  - T1R: 4–8 weeks (pilot corridor + NGO)
+- Informal delivery fleets (motorbike)
+  - Verifier: micro-insurer/financier
+  - Value: delivery/outcome receipts → eligibility for insurance/credit
+  - T1R: 4–6 weeks (fleet partner + phone app)
+- Reverse logistics (RMA)
+  - Verifier: finance/audit/ERP; sustainability reporting
+  - Value: RMA state-machine “receipts rail” → refunds/chargebacks clarity,
+    refurb analytics
+  - T1R: 4–8 weeks (one brand + 3PL)
+- Internal HR compliance (Fair Work–style dispute trail)
+  - Verifier: regulator/tribunal; corporate audit
+  - Value: standardized settlement-grade artifacts for legal discovery → faster
+    resolution -> prevents "lack of documentation" - because process is
+    admin-heavy
+  - T1R: 4–6 weeks (one HR/legal team)
+
+---
+
+DevOps authority tracking - this is like SSO (and that user onramp/offramp)
+extended to the entire devops enterprise resources
+
+I need a way to "write down" or audit log a change to authority.
+
+I just changed my GitHub CI/CD NIXPKGS_PRIVATE_PAT to a new one.
+
+Why?
+
+Because after offboarding an employee, it turns out that while she was
+responsible for setting up infrastructure, she had injected her own PAT there.
+And it worke while her account was active.
+
+After offboarding her accounts, the CI/CD failed. It failed (late) rather than
+(early) because we don't early warning that a particular token that is used
+somewhere is now invalid because of a state change somewhere else (this the
+action at a distance problem, or cache-coherency/state-sync/foreign-key
+integrity problem applied to configuration/and secrets).
+
+To fix this, I generated a new token - but I had to:
+
+1. Figure why it was failing?
+2. Trace to the root cause that was due to an invalid token.
+3. Backtrack through business-tacit-knowledge realising that she was responsible
+   for this technology domain, and therefore maybe it was her token.
+4. Figure out how to "recreate" this token - because it's not 100% clear what
+   exactly this token was capable of.
+5. Inferring from the name, it's a token designed to access only a single
+   repository with read-only permissions of the contents.
+6. Therefore, replacing it with a token that has that exact authority - but
+   under a new more durable principal rather than any single user's account.
+7. But now we have a repeat problem. The point problem is fixed, but a long term
+   problem remains. There is no audit log, and this problem can happen again.
+   The token will expire eventually and we will have this problem again.
+
+An audit log is not enough. I could write it into a log. But it's not
+composable, not automated, not open. It's not "connected" the Source of
+Authority, the User of Authority and Target of Authority.

sidebars.ts

@@ -104,6 +104,11 @@ const sidebars: SidebarsConfig = {
           },
           items: [
             'reference/specifications/PSP-1 - Capability Model and Grammar',
+            'reference/specifications/PSP-2 - Receipt Model',
+            'reference/specifications/PSP-3 - Sigchain and Envelope',
+            'reference/specifications/PSP-4 - Registries',
+            'reference/specifications/PSP-5 - CEP and Bridge Adapter',
+            'reference/specifications/PSP-6 - TAP and RAM',
           ],
         },
         {