| # THE SNAPKITTY METHOD |
|
|
| ## PUBLIC BY DEFAULT. SOVEREIGN BY CONSTRUCTION. |
|
|
| > **Nothing needs to be hidden if the boundary between public knowledge and sovereign execution is formally defined.** |
|
|
| --- |
|
|
| ## The Boundary |
|
|
| ``` |
| CODE → PUBLIC |
| PROOF → PUBLIC |
| SPEC → PUBLIC |
| TESTS → PUBLIC |
| HISTORY → PUBLIC |
| PROVENANCE → PUBLIC |
| |
| AUTHORITY → SOVEREIGN |
| STATE → SOVEREIGN |
| SECRETS → SOVEREIGN |
| EXECUTION → AUTHORIZED |
| ``` |
|
|
| The source is public. The **state, credentials, execution authority, and deployment boundaries** remain sovereign. |
|
|
| This is not: *"Here is the fake public version."* |
|
|
| This is: **"Here is the machine. You don't own the state it operates on."** |
|
|
| --- |
|
|
| ## No Stubs. Proofs Instead. |
|
|
| If something can be published safely → publish the **real implementation**. |
|
|
| If something cannot be published → publish the **formal boundary** describing what it is allowed to do. |
|
|
| No theatrical fake API. No TODO implementations. No repository whose only purpose is to look open. |
|
|
| --- |
|
|
| ## Cryptographic Provenance |
|
|
| Every artifact carries a cryptographic provenance record: |
|
|
| ``` |
| ARTIFACT → HASH → SEAL → COMMIT → VERIFICATION → IMMUTABLE PROVENANCE |
| ``` |
|
|
| The repository is an evidence trail. Not merely a source-code dump. |
|
|
| ``` |
| SHA-256 · Merkle relationships · Ed25519 signatures · WORM records · reproducible builds · formal verification |
| ``` |
|
|
| The objective is not: *"This code exists."* |
|
|
| It is: **"This artifact existed in this state, was produced through this transformation, and can be independently verified."** |
|
|
| --- |
|
|
| ## Automated Provenance Pipeline |
|
|
| ``` |
| COMMIT → SCHEMA CHECK → SECRET CHECK → LICENSE CHECK → PROVENANCE CHECK |
| → TEST → FORMAL VERIFICATION → SEAL → PUBLISH |
| ``` |
|
|
| A failed invariant stops publication. The system does not negotiate with the failure. |
|
|
| ``` |
| INVARIANT FAILED → NO → NO SEAL → NO RELEASE |
| ``` |
|
|
| --- |
|
|
| ## AI Agents — Constrained Builders |
|
|
| Agents operate inside explicit boundaries: |
|
|
| ``` |
| INPUT → AGENT → PROPOSED CHANGE → TEST → STATIC ANALYSIS |
| → FORMAL CHECK → HUMAN / POLICY GATE → CRYPTOGRAPHIC SEAL → MERGE |
| ``` |
|
|
| An agent cannot declare its own output correct. It must satisfy an external constraint. |
|
|
| > **An agent may propose state transitions. It may not unilaterally define truth.** |
|
|
| --- |
|
|
| ## The Zero-Sorry Boundary |
|
|
| ``` |
| THEOREM → LEAN 4 → PROOF → ZERO SORRY → VERIFIED ARTIFACT |
| ``` |
|
|
| The repository contains the proof. The verifier independently executes the proof. |
|
|
| Instead of: *"Trust the developer."* |
|
|
| The architecture moves toward: **"Verify the invariant."** |
|
|
| --- |
|
|
| ## Public Code ≠ Public Authority |
|
|
| ``` |
| Open Source ≠ Open Authority |
| Public Code ≠ Public Control |
| ``` |
|
|
| A public repository exposes architecture, algorithms, interfaces, schemas, tests, proofs, build systems, and documentation — without exposing credentials, deployment authority, operational state, or execution control. |
|
|
| That is the central SnapKitty architectural boundary. |
|
|
| --- |
|
|
| ## The Principle |
|
|
| > **Don't hide the machine.** |
| > |
| > **Make the machine verifiable.** |
| > |
| > **Keep control at the execution boundary.** |
|
|
| **PUBLIC SUBSTRATE. SOVEREIGN STATE. FORMAL CONSTRAINTS. CRYPTOGRAPHIC PROVENANCE. ZERO-SORRY WHERE PROVABLE.** |
|
|
| --- |
|
|
| ## Trust |
|
|
| **Bel Esprit D'Accord Irrevocable Trust (EIN 42-697643)** |
| SnapKitty Collective Limited (FLP) |
| Operators: Ahmad Ali Parr · Jessica Westerhoff |
| Web: https://github.com/SNAPKITTYWEST |
|
|
| `Ω = TRUST ∧ CODE` |
|
|
