Implement HARP and CPL milestones through v0.5.11
This commit is contained in:
@@ -2,6 +2,8 @@
|
||||
|
||||
Status: **Normative traceability and handoff gate**
|
||||
|
||||
Document release: **Thinkloom 0.5.1**
|
||||
|
||||
Stage 1 is complete only when every item below is represented without contradiction in the normative specification and state-machine companion. This checklist also defines the minimum Stage 2 and later implementation test handoff.
|
||||
|
||||
## 1. Normative specification gate
|
||||
@@ -9,6 +11,16 @@ Stage 1 is complete only when every item below is represented without contradict
|
||||
| Requirement | Normative location | Status |
|
||||
|---|---|---|
|
||||
| Correct tamper-evident claim and trust limitation | Specification §§3, 26 | Complete |
|
||||
| CPL is the product name for the one canonical ledger, not a second ledger | Specification §3.1 | Complete |
|
||||
| HARP is a non-authoritative reproducible projection bound to one exact deposit | Specification §§3.1, 15.2–15.4 | Complete |
|
||||
| Cryptographic verification is limited to integrity, not identity or authorship | Specification §§3, 15.4 | Complete |
|
||||
| Product and UI terms have one normative meaning | Specification §§3.1–3.2 | Complete |
|
||||
| Copyrightability, originality, ownership, and authorship conclusions are prohibited | Specification §§3.1–3.2, 15.3 | Complete |
|
||||
| Recorded origin, transformation, selection/arrangement, evaluation, and suggested treatment remain independent | Specification §§3.1, 10, 15.3 | Complete |
|
||||
| Deposit digest, revision, and stable segment ID outrank derived page locators | Specification §15.2 | Complete |
|
||||
| Post-deposit editing makes current-work HARP applicability stale without falsifying historical integrity | Specification §15.2; State Machines §12 | Complete |
|
||||
| Suggested registration language is editable and explicitly approved | Specification §15.3; State Machines §12 | Complete |
|
||||
| Initial U.S. literary-work Standard Application policy profile | Specification §15.5 | Complete |
|
||||
| Authority hierarchy | Specification §4 | Complete |
|
||||
| Self-contained repository boundaries | Specification §5 | Complete |
|
||||
| Stable IDs and contiguous event sequences | Specification §6 | Complete |
|
||||
@@ -50,7 +62,7 @@ Stage 1 is complete only when every item below is represented without contradict
|
||||
| Pre-durable-write secret filtering | Specification §21 | Complete |
|
||||
| No audio retention | Specification §21 | Complete |
|
||||
| Sanitization versus emergency purge | Specification §22; State Machines §10 | Complete |
|
||||
| Explicit legacy preview-project policy | Specification §23 | Complete |
|
||||
| Explicit v0.5.x preview-project and CPL-marker boundary | Specification §23; State Machines §11 | Complete |
|
||||
| Stage 2 formal schema inventory | Specification §24 | Complete |
|
||||
| Migration deferred until after 1.0.0 | Specification §§23–24, 26 | Complete |
|
||||
|
||||
@@ -79,9 +91,15 @@ Required outputs:
|
||||
- Versioned assertion lifecycle, reason-code, confidence-dimension, evidence-class, and boundary-kind registries.
|
||||
- Assertion self-digest, dependency invalidation, superseding evaluation, and consumer-decision vectors.
|
||||
- Invalid fixtures proving unknown provenance, generation, compatibility, or confidence cannot validate as exact.
|
||||
- Additive composition schemas for composition operations, expression segments, contribution maps, deposit snapshots, registration policy profiles, human-authorship records, and HARP export manifests.
|
||||
- Versioned registries for composition-operation kinds, recorded-origin kinds, transformation relationships, contribution-map layers, suggested registration treatment, HARP limitation/explanation codes, and composition assertion predicates.
|
||||
- Fixtures proving unknown identity, origin, generation, or lineage cannot validate as an exact HARP classification.
|
||||
- Compatibility declarations preserve existing v0.4 assertion semantics and identify the v0.6 runtime target; project-format conformance requires the exact marker introduced by Milestone 4 / 0.5.4.
|
||||
|
||||
Stage 2 must preserve the distinction between the provenance schema version and the Thinkloom application version.
|
||||
|
||||
Thinkloom 0.5.2 fulfills this Stage 2 handoff with 47 schemas, 14 registries, exhaustive schema fixtures, and deterministic composition, contribution-map, deposit, HARP, staleness, and export-manifest vectors. This is schema-package completion only; CPL runtime conformance remains targeted to Thinkloom 0.6.0.
|
||||
|
||||
## 3. Durable-boundary fault-injection matrix
|
||||
|
||||
The native implementation and test harness MUST support deterministic termination or injected failure after:
|
||||
@@ -122,6 +140,8 @@ For each boundary, tests MUST prove one of:
|
||||
4. Recovery quarantines it without presenting false success.
|
||||
5. Authoritative contradiction is reported and editing remains blocked.
|
||||
|
||||
Thinkloom 0.5.3 fulfills the native CPL writer subset of this matrix through immutable-record durability, ledger append, chain-head advancement, SQLite application, idempotent completion, and segment rotation. Git checkpoint, release, backup, and import-specific injection points remain assigned to their later implementation milestones.
|
||||
|
||||
## 4. Concurrency and idempotency tests
|
||||
|
||||
- Hundreds of concurrent frontend commands serialize without event loss or sequence gaps.
|
||||
@@ -183,6 +203,18 @@ For each boundary, tests MUST prove one of:
|
||||
- Digest and generation changes deterministically invalidate dependent evaluations
|
||||
- Later evaluations supersede current usability without mutating earlier assertion or evaluation records
|
||||
- Derived projections never synthesize exact without an authoritative exact evaluation
|
||||
- Complete, ordered, non-overlapping contribution-map coverage for complex Unicode
|
||||
- Recorded origin remains independent of transformation and selection/arrangement overlays
|
||||
- Paste/import never defaults to recorded direct human input
|
||||
- Human revision of accepted AI output retains the AI preimage and later human operations
|
||||
- Coverage statements name their denominator and never express a human or AI percentage
|
||||
- Page locators change only with an identified layout profile and never replace stable segment identity
|
||||
- Identical canonical inputs produce byte-identical HARP and contribution-map content
|
||||
- Every HARP statement traces to its CPL event, record, assertion, evaluation, or user approval
|
||||
- Unknown or unattested boundaries remain visible and cannot validate as exact
|
||||
- Any post-deposit edit or restore deterministically makes current-work HARP applicability stale
|
||||
- Historical HARP integrity remains independently verifiable for its unchanged exact deposit
|
||||
- Policy-profile updates do not rewrite an existing HARP
|
||||
|
||||
## 7. Privacy, secret, and encryption tests
|
||||
|
||||
@@ -238,17 +270,25 @@ For each boundary, tests MUST prove one of:
|
||||
- Git-only damage yields warning when authoritative evidence remains valid.
|
||||
- Missing authoritative records yield `FAILED`.
|
||||
- Unsafe archive structure yields `UNSAFE`.
|
||||
- UI uses **HARP integrity verified**, never **authorship verified**.
|
||||
- UI visibly separates evidence facts, declarations, recorded origin, transformations, selection/arrangement, evaluations, suggestions, and Office determinations.
|
||||
- Prohibited-phrase tests reject human/AI percentages, authorship or originality scores, and legal-conclusion claims.
|
||||
- Registration suggestions remain editable and generation is blocked until the exact strings receive explicit approval.
|
||||
- A stale HARP shows both current-work staleness and historical deposit verification status.
|
||||
|
||||
## 10. Legacy 1.0 behavior tests
|
||||
## 10. Legacy preview/CPL boundary tests
|
||||
|
||||
- Known preview markers are detected without modifying the project.
|
||||
- Normal opening and editing are refused.
|
||||
- Show Project Folder remains available.
|
||||
- Raw archival ZIP preserves the selected legacy tree without conversion.
|
||||
- The archive is labeled as unverified and unconverted.
|
||||
- No 1.0 provenance verification or evidence report is offered.
|
||||
- No CPL 1.0 provenance verification, HARP, or CPL evidence report is offered.
|
||||
- Legacy Git history remains unchanged.
|
||||
- No migration schema or implied migration success appears in 1.0.
|
||||
- No migration schema or implied migration success appears before/at 1.0.0.
|
||||
- A v0.5.x project or `schemaVersion: 1.0` field cannot satisfy the CPL marker check.
|
||||
- No preview project can invoke CPL verification or HARP generation.
|
||||
- Only the exact supported CPL marker may proceed to recovery, and the marker alone does not establish conformance.
|
||||
|
||||
## 11. Stage 1 disposition
|
||||
|
||||
@@ -259,4 +299,4 @@ Stage 1 is **complete** when:
|
||||
- The Stage 2 schema work uses this checklist as its acceptance boundary.
|
||||
- Any future architectural change is recorded as a versioned normative amendment rather than an informal implementation choice.
|
||||
|
||||
Completion of Stage 1 does not claim implementation conformance and does not change the current application version.
|
||||
Completion of the 0.5.1 normative amendment did not claim runtime implementation or CPL project conformance. Thinkloom 0.5.3 supplies the native service and its core writer fault-injection suite. Thinkloom 0.5.4 completes the project-format boundary: exact-marker projects must pass structure, recovery, and native verification gates, while unmarked preview projects remain untouched and preservation-only. Thinkloom 0.5.5 then routes Phase 1 through typed canonical commands, reconstructs the ideation UI by ledger replay, and records provider intent before I/O with response or failure afterward. Thinkloom 0.5.6 captures manuscript transactions through the shared TipTap path, preserves scalar-level expression lineage, and deterministically replays the manuscript from immutable composition commands. Thinkloom 0.5.7 freezes exact deposit revisions and deterministically projects complete scalar contribution maps with structural locators, independent assertions, current evaluations, and visible evidence boundaries. Thinkloom 0.5.8 then generates the complete explicitly approved HARP report set without LLM classification or legal conclusions and deterministically marks it stale after manuscript, deposit, policy, assertion, or dependency changes. Thinkloom 0.5.9 exposes that evidence through native-verifier-backed CPL exploration and a gated HARP preparation workflow in which every evidentiary statement traces through assertions, evaluations, and underlying records. Thinkloom 0.5.10 creates the six separate HARP export artifacts, discloses and hash-binds every sanitized omission category, verifies retained evidence against CPL/HARP/deposit bindings, and preserves the source chain without claiming sanitized completeness. Thinkloom 0.5.11 completes the executable verification matrix, origin-preserving arrangement checks, native release gate, prohibited-wording scans, and packaged Windows executable/MSI/NSIS end-to-end gate.
|
||||
|
||||
@@ -1,11 +1,20 @@
|
||||
# Thinkloom provenance specification
|
||||
|
||||
This directory contains the approved normative specification and formal Stage 2 contract for the Thinkloom 1.0 provenance subsystem.
|
||||
This directory contains the Thinkloom 0.5.1 normative HARP/CPL specification, the additive Thinkloom 0.5.2 formal schema package, the Thinkloom 0.5.3 modular native CPL service record, the Thinkloom 0.5.4 conforming project-boundary record, the Thinkloom 0.5.5 typed Phase 1 routing record, the Thinkloom 0.5.6 manuscript composition-lineage record, the Thinkloom 0.5.7 contribution-map projection record, the Thinkloom 0.5.8 deterministic HARP-generation record, the Thinkloom 0.5.9 connected HARP/CPL interface record, the Thinkloom 0.5.10 export/privacy/security record, and the Thinkloom 0.5.11 executable verification-matrix record.
|
||||
|
||||
- [Stage 1 Normative Specification](STAGE-1-NORMATIVE-SPECIFICATION.md)
|
||||
- [State Machines and Recovery Protocols](STATE-MACHINES.md)
|
||||
- [Stage 1 Completion Checklist](COMPLETION-CHECKLIST.md)
|
||||
- [Stage 2 Completion and Verification](STAGE-2-SCHEMA-PACKAGE.md)
|
||||
- [Stage 2 JSON Schema package](../../schemas/provenance/v1/README.md)
|
||||
- [Stage 3 Native CPL Service](STAGE-3-NATIVE-CPL-SERVICE.md)
|
||||
- [Stage 4 Conforming Project Boundary](STAGE-4-CONFORMING-PROJECT-BOUNDARY.md)
|
||||
- [Stage 5 Phase 1 CPL Routing](STAGE-5-PHASE-1-CPL-ROUTING.md)
|
||||
- [Stage 6 Manuscript Composition and Lineage](STAGE-6-MANUSCRIPT-COMPOSITION-LINEAGE.md)
|
||||
- [Stage 7 Contribution-Map Projection](STAGE-7-CONTRIBUTION-MAP-PROJECTION.md)
|
||||
- [Stage 8 Deterministic HARP Generation](STAGE-8-HARP-GENERATION.md)
|
||||
- [Stage 9 HARP and CPL User Interfaces](STAGE-9-HARP-CPL-USER-INTERFACES.md)
|
||||
- [Stage 10 Export, Privacy, and Security](STAGE-10-EXPORT-PRIVACY-SECURITY.md)
|
||||
- [Stage 11 Verification Matrix](STAGE-11-VERIFICATION-MATRIX.md)
|
||||
|
||||
Thinkloom 0.4.0 includes the 40-schema Draft 2020-12 package, versioned assertion registries, valid and invalid fixtures, and deterministic conformance vectors. The native writer does not yet implement this contract and must not be represented as conforming until the later implementation and fault-injection stages are complete.
|
||||
Thinkloom 0.5.11 makes the complete milestone verification matrix executable, preserves origin during selection/arrangement moves, blocks release finalization unless native verification is complete and safe, scans shipped wording for prohibited scores and legal conclusions, and verifies the packaged Windows executable plus MSI and NSIS artifacts. The six 0.5.10 export artifacts and the read-only boundary for unmarked preview projects remain unchanged.
|
||||
|
||||
@@ -1,17 +1,21 @@
|
||||
# Thinkloom Stage 1 Normative Provenance Specification
|
||||
|
||||
Status: **Approved architecture baseline for formal schema work**
|
||||
Target: **Thinkloom 1.0.0**
|
||||
Provenance schema family: **1.0**
|
||||
Document release: **Thinkloom 0.5.1**
|
||||
|
||||
Runtime conformance target: **Thinkloom 0.6.0; project-format conformance 1.0**
|
||||
|
||||
Provenance schema family: **1.0**
|
||||
|
||||
Migration support: **Deferred until after Thinkloom 1.0.0**
|
||||
|
||||
## 1. Purpose and precedence
|
||||
|
||||
This specification defines the authority, persistence, integrity, privacy, recovery, verification, backup, and release contracts for Thinkloom provenance.
|
||||
This specification defines the authority, persistence, integrity, privacy, recovery, verification, backup, release, Composition Provenance Ledger (CPL), and Human Authorship Record of Provenance (HARP) contracts for Thinkloom provenance.
|
||||
|
||||
It supersedes the provenance-specific transaction order, single-ledger layout, mutable-record assumptions, live-database snapshot method, and release-binding sequence in the earlier MVP architecture and implementation plans. It does not supersede their product requirements, native Tauri boundary, preview-first generation model, user-control requirements, accessibility requirements, or prohibition on retained audio.
|
||||
|
||||
Thinkloom 0.4.0 includes the formal Stage 2 schemas, canonical assertion envelopes, and verification vectors, but its native writer is not represented as conforming to this specification. Full conformance begins only after the native implementation and required fault-injection tests are complete.
|
||||
Thinkloom 0.5.1 includes this normative HARP/CPL amendment and preserves the existing formal Stage 2 schemas, canonical assertion envelopes, and verification vectors, but its native writer is not represented as CPL-conforming. Full conformance begins only after the native implementation and required fault-injection tests are complete.
|
||||
|
||||
## 2. Normative language
|
||||
|
||||
@@ -27,25 +31,61 @@ Thinkloom provenance is:
|
||||
|
||||
> A local, transactionally coordinated, tamper-evident creative-process record with configurable retention, native verification, recoverable storage, and reproducible release manifests.
|
||||
|
||||
The correct HARP/CPL product claim is:
|
||||
|
||||
> A Human Authorship Record of Provenance (HARP) is a reproducible evidence projection for an exact deposit, backed by cryptographically verifiable integrity evidence in Thinkloom's Composition Provenance Ledger (CPL).
|
||||
|
||||
Thinkloom MUST NOT claim that local provenance is tamper-proof, an independently trusted timestamp, conclusive legal proof, or a quantitative measure of human versus AI authorship.
|
||||
|
||||
Cryptographic verification establishes only the integrity and internal linkage of the retained bytes within the verifier's stated scope. It MUST NOT, without separately identified evidence, be represented as verification of a person's identity, the truth of a user declaration, legal authorship, originality, copyrightability, ownership, or registrability. A signature or local key proves control of that key; it proves identity only when the key has a separately verified identity binding.
|
||||
|
||||
The strongest valid claim without an external anchor is:
|
||||
|
||||
> The system can detect changes relative to a previously retained chain head, signed release, or external anchor.
|
||||
|
||||
### 3.1 Normative product terms
|
||||
|
||||
The following meanings are exclusive and binding throughout product copy, schemas, reports, tests, and implementation:
|
||||
|
||||
- **Composition Provenance Ledger (CPL)** is the product-facing name for the single canonical provenance ledger defined by §§12–13. CPL is not a new ledger, side ledger, report, database, or replacement for the existing ledger. A conforming project has one CPL whose events bind immutable records, assertions, and evaluations under §4.
|
||||
- **CPL record** is an immutable authoritative record referenced by a CPL event. The term does not include SQLite rows, UI state, derived indexes, generated reports, or uncommitted temporary data.
|
||||
- **Deposit** is the exact file selected by the user for a registration submission or other declared evidentiary purpose and frozen in a deposit snapshot. A manuscript revision, editor state, export recipe, or filename alone is not a deposit.
|
||||
- **Human Authorship Record of Provenance (HARP)** is a non-authoritative, deterministic, reproducible projection of CPL records and evaluations bound to one exact deposit. The word “Authorship” in the product name describes the subject of the evidence record; it is not a Thinkloom determination that any expression is legally authored, original, or copyrightable.
|
||||
- **Recorded origin** describes what the CPL records about how expression entered the composition. It is an evidence classification, not a legal conclusion.
|
||||
- **Transformation relationship** describes how expression changed or derived from earlier expression.
|
||||
- **Selection/arrangement overlay** describes recorded relationships among surviving expression or structural units. It is independent of their recorded origin and MUST NOT be encoded as a text-origin category.
|
||||
- **Suggested registration treatment** is editable application language produced under a versioned policy profile. It is neither an evidence fact nor a legal determination.
|
||||
- **Legal determination** includes copyrightability, originality, authorship, ownership, and registrability. Thinkloom and HARP do not make these determinations.
|
||||
|
||||
No second meaning, abbreviation expansion, or competing product label MAY be used for CPL or HARP in a conforming product surface.
|
||||
|
||||
### 3.2 Prohibited claims and required UI terminology
|
||||
|
||||
Thinkloom, CPL, HARP, exports, and marketing MUST NOT state or imply:
|
||||
|
||||
- A “human percentage,” “AI percentage,” authorship score, originality score, copyrightability score, or equivalent quantitative legal proxy
|
||||
- “Copyright verified,” “copyrightable,” “originality proven,” “proven human author,” “legally human-authored,” “registration-ready,” “Copyright Office approved,” or “authorship certified”
|
||||
- That typing time, edit count, word count, retained-word ratio, prompt count, or any other activity metric determines originality or authorship
|
||||
- That a paste, import, self-declaration, cryptographic signature, or successful integrity check by itself proves identity or human authorship
|
||||
- That `VERIFIED` or `exact` means anything beyond the explicitly named integrity or evidentiary scope
|
||||
|
||||
Product surfaces MUST distinguish and label these categories: **Evidence fact**, **User declaration**, **Recorded origin**, **Transformation relationship**, **Selection/arrangement overlay**, **Evidentiary evaluation**, **Suggested registration language**, and **Copyright Office determination**. The UI MAY use “integrity verified” only with the verified scope and chain head visible. It MUST use “self-declared identity” unless stronger identity evidence and its verification method are present.
|
||||
|
||||
## 4. Authority hierarchy
|
||||
|
||||
The following hierarchy is binding:
|
||||
|
||||
1. **Immutable filesystem records, canonical provenance assertions, point-in-time assertion evaluations, and the provenance ledger** are authoritative evidence when bound by ledger references.
|
||||
1. **Immutable filesystem records, canonical provenance assertions, point-in-time assertion evaluations, and the canonical provenance ledger (product name: CPL)** are authoritative evidence when bound by CPL event references.
|
||||
2. **Canonical publication files and manuscript revisions** are authoritative publication content when bound by ledger references.
|
||||
3. **Release manifests** are authoritative bindings for a completed release.
|
||||
4. **SQLite** stores operational state, UI state, write intents, idempotency indexes, and rebuildable query indexes.
|
||||
5. **Git** stores meaningful milestone history and release state but is not the provenance authority.
|
||||
6. **Derived indexes and generated reports** are disposable, reproducible caches or projections.
|
||||
6. **Derived indexes, contribution maps, HARP documents, and generated reports** are disposable, reproducible projections. They are non-authoritative even when their bytes and source bindings verify.
|
||||
|
||||
SQLite MUST NOT be the only location of an evidentiary fact. A valid ledger MUST take precedence over contradictory SQLite state. Git failure MUST NOT invalidate an otherwise valid provenance ledger.
|
||||
|
||||
A HARP MUST NOT add, promote, or repair an evidentiary fact. Every factual HARP statement MUST trace to a CPL record, assertion, evaluation, or explicit user declaration bound by a CPL event. If the required basis is unknown, unattested, stale, degraded, or unverified, the HARP MUST preserve that boundary rather than infer a favorable classification.
|
||||
|
||||
## 5. Repository boundaries
|
||||
|
||||
A conforming 1.0 project SHOULD organize authoritative and operational data under these boundaries:
|
||||
@@ -60,7 +100,8 @@ publication-project/
|
||||
│ ├── invocations/
|
||||
│ ├── prompt-templates/
|
||||
│ ├── sources/
|
||||
│ └── transformations/
|
||||
│ ├── transformations/
|
||||
│ └── composition/
|
||||
├── provenance/
|
||||
│ ├── schema/
|
||||
│ ├── ledger/active/
|
||||
@@ -69,7 +110,9 @@ publication-project/
|
||||
│ ├── integrity/
|
||||
│ └── report-config/
|
||||
├── releases/
|
||||
├── deposits/
|
||||
├── reports/
|
||||
│ └── harp/
|
||||
├── assets/
|
||||
├── .app/
|
||||
│ ├── state.sqlite
|
||||
@@ -85,7 +128,7 @@ Large PDFs, ZIP packages, and regenerable binaries SHOULD remain outside ordinar
|
||||
|
||||
## 6. Identifiers and event ordering
|
||||
|
||||
Stable sortable identifiers SHOULD use ULIDs with type prefixes, including `event_`, `record_`, `intent_`, `turn_`, `session_`, `invocation_`, `revision_`, `fragment_`, `checkpoint_`, `release_`, `assertion_`, and `evaluation_`.
|
||||
Stable sortable identifiers SHOULD use ULIDs with type prefixes, including `event_`, `record_`, `intent_`, `turn_`, `session_`, `invocation_`, `revision_`, `segment_`, `deposit_`, `harp_`, `policy_`, `fragment_`, `checkpoint_`, `release_`, `assertion_`, and `evaluation_`.
|
||||
|
||||
Identifiers MAY be allocated before an operation commits. Abandoned identifiers MUST NOT be reused.
|
||||
|
||||
@@ -187,6 +230,16 @@ Supported coordinate systems MUST be explicit, such as `utf8_byte`, `unicode_sca
|
||||
|
||||
Meaningful manual editing MUST be grouped into edit transactions rather than keystroke events. A transaction SHOULD close on focus loss, configured idle interval, section change, AI operation, checkpoint, phase change, document close, explicit save, or milestone.
|
||||
|
||||
Composition provenance MUST keep these dimensions independent:
|
||||
|
||||
1. Recorded origin
|
||||
2. Transformation relationship
|
||||
3. Selection/arrangement overlay
|
||||
4. Evidentiary evaluation
|
||||
5. Suggested registration treatment
|
||||
|
||||
Recorded-origin values MUST distinguish at least recorded direct human input, human expressive input mediated by transcription, accepted AI output, imported or pasted material, system restoration, and unattested expression. Paste or import MUST NOT default to recorded direct human input. Human modification of AI-origin material MUST retain the AI preimage lineage and the later human operations; it MUST NOT rewrite the earlier origin as human. Unknown identity, generation, origin, or lineage MUST remain unknown or unattested and MUST NOT validate as an exact classification.
|
||||
|
||||
## 11. Retention, export, and encryption policies
|
||||
|
||||
These are independent settings:
|
||||
@@ -199,7 +252,7 @@ default_export_profile: full | sanitized
|
||||
|
||||
### 11.1 Minimal retention
|
||||
|
||||
Minimal provenance is the REQUIRED default for Thinkloom 1.0. It retains final user-approved input, operation purpose, prompt-template identity/hash, input references/hashes, provider/model identity, accepted generated text, disposition metadata, manuscript lineage, checkpoints, and releases.
|
||||
Minimal provenance is the REQUIRED default for a CPL 1.0-conforming project. It retains final user-approved input, operation purpose, prompt-template identity/hash, input references/hashes, provider/model identity, accepted generated text, disposition metadata, manuscript lineage, checkpoints, and releases.
|
||||
|
||||
It MUST NOT retain raw speech hypotheses, complete provider-facing prompts, complete supplied context, unaccepted raw model responses, or provider transport metadata.
|
||||
|
||||
@@ -357,6 +410,8 @@ Assertion evaluation statuses are:
|
||||
|
||||
Every evaluation MUST assess these dimensions independently: `integrity`, `identity`, `chronology`, `derivation`, `authorship`, and `completeness`. Dimension values are `exact`, `degraded`, `unverified`, or `not_applicable`. Numeric confidence scores and human-versus-AI percentages MUST NOT be used.
|
||||
|
||||
For compatibility with the existing v0.4 assertion registry, the wire-level dimension name `authorship` is retained. In this specification it means only the sufficiency of recorded evidence for the assertion's explicitly bounded authorship-related predicate. It MUST NOT be displayed or interpreted as legal authorship, copyrightability, originality, or a HARP conclusion; an `exact` value means only that the retained evidence satisfies that declared predicate and scope.
|
||||
|
||||
An `exact` evaluation MUST have no uncertainty boundary, MUST contain valid results for every non-shadow dependency, and MUST contain no `degraded` or `unverified` confidence dimension. Shadow evidence never contributes authority and MAY remain unevaluated without changing exactness. A non-exact evaluation MUST identify the exact boundary, affected dimensions, dependencies when applicable, and a stable reason code. Unknown provenance, source generation, compatibility, or confidence MUST NOT silently produce an `exact` evaluation.
|
||||
|
||||
Evidence classes are `mandatory_live`, `mandatory_retained`, `advisory`, and `shadow`. Missing or incompatible mandatory evidence prohibits `exact`. Advisory or shadow evidence MAY degrade completeness or another named dimension but MUST NOT silently change an authoritative assertion.
|
||||
@@ -365,6 +420,78 @@ Assertion and evaluation reason codes, lifecycle phases, statuses, dimensions, e
|
||||
|
||||
Derived indexes and reports MAY project assertions and the latest applicable evaluations, but remain non-authoritative consumers. They MUST NOT synthesize an `exact` result when no valid authoritative evaluation exists.
|
||||
|
||||
### 15.2 Deposit snapshots and authoritative locators
|
||||
|
||||
A HARP MUST bind one immutable deposit snapshot containing at least:
|
||||
|
||||
- Deposit ID and deposit-snapshot schema version
|
||||
- Exact deposit-file digest and byte length
|
||||
- Deposit media type and sanitized display name
|
||||
- Bound manuscript revision ID and revision digest
|
||||
- CPL chain head digest and event sequence used for the projection
|
||||
- Layout-profile ID and digest when page locators are emitted
|
||||
- Creation timestamp, application version, and schema versions
|
||||
|
||||
The deposit revision, deposit digest, and stable expression-segment ID are authoritative locators. Chapter, paragraph, line, and page numbers are derived locators. A page number MUST identify its layout profile and MUST NOT be used as the sole identity of expression or as an authoritative range boundary.
|
||||
|
||||
Freezing a deposit does not freeze the working manuscript. Any edit or restoration after the bound deposit snapshot, or any change to the selected deposit bytes, creates a newer dependency state and MUST make the HARP `stale` for the current work. Staleness does not falsify or invalidate a previously verified historical HARP for its exact bound deposit; the UI MUST show both facts. A stale HARP is immutable and MUST be regenerated from a new deposit snapshot rather than updated in place.
|
||||
|
||||
### 15.3 HARP content and generation
|
||||
|
||||
HARP generation MUST be deterministic and MUST NOT use an LLM to classify authorship, decide originality or copyrightability, fill an evidence gap, or formulate a legal conclusion. Identical canonical inputs, policy profile, generator version, and sanitization profile MUST produce byte-identical machine-readable HARP content.
|
||||
|
||||
A canonical HARP MUST include:
|
||||
|
||||
- HARP ID, schema version, application version, and generator version
|
||||
- Exact deposit binding required by §15.2
|
||||
- CPL chain head and sequence used for projection
|
||||
- A complete contribution-map coverage statement with an explicit denominator and coordinate unit
|
||||
- Recorded-origin, transformation, and selection/arrangement layers kept separate
|
||||
- Current applicable assertion evaluations and visible exact, degraded, stale, unverified, unknown, and unattested boundaries
|
||||
- AI systems and models recorded as used for included expression, with unavailable identity represented as unknown
|
||||
- Representative transformations linked to their CPL basis
|
||||
- Suggested `Author Created`, `Material Excluded`, and `New Material Included` language when supported by the selected policy profile
|
||||
- Every user declaration, including author identity, labeled as a declaration and identified as self-declared unless stronger evidence is present
|
||||
- Limitation, sanitization, and omission disclosures
|
||||
- The policy-profile ID, version, source retrieval date, and source digests or stable source references
|
||||
- A verification report and manifest binding every emitted artifact and digest
|
||||
- A clear statement that the U.S. Copyright Office, not Thinkloom, determines copyrightability and registration scope
|
||||
|
||||
Coverage MUST describe only the scope of recorded evidence. For example, it MAY state that a percentage of normalized Unicode scalar positions has recorded origin. It MUST NOT relabel that denominator as “human,” “human-authored,” “original,” or “copyrightable.” Selection and arrangement MUST appear as relationship overlays and MUST NOT change the recorded-origin layer.
|
||||
|
||||
Suggested registration language MUST be generated only after the user selects a deposit and policy profile, reviews the evidence classifications and limitations, edits or accepts the proposed text, and explicitly approves generation. Approval MUST bind the exact approved strings and their source HARP inputs in CPL. Thinkloom MUST NOT submit an application, assert that the language is legally sufficient, or silently replace user-approved language when a policy profile changes.
|
||||
|
||||
### 15.4 HARP verification and traceability
|
||||
|
||||
HARP verification is a scoped integrity operation. It MUST verify artifact hashes, manifest bindings, deposit bytes, CPL source head and records, schema and generator compatibility, policy-profile binding, sanitization disclosures, and deterministic regeneration when the required generator is available.
|
||||
|
||||
Every factual claim and suggested treatment in a HARP MUST expose a trace path to the supporting CPL event, record, assertion, evaluation, and any user approval. A successful verification MUST be labeled **HARP integrity verified** and MUST show the exact deposit digest. It MUST NOT be labeled **authorship verified**.
|
||||
|
||||
The following states are independent and MUST NOT be collapsed:
|
||||
|
||||
- CPL verification status under §15
|
||||
- HARP integrity verification status
|
||||
- HARP applicability: `current` or `stale`
|
||||
- Evidence boundary: `exact`, `degraded`, `stale`, `unverified`, `unknown`, or `unattested`
|
||||
- Policy-profile currency: `current`, `superseded`, or `unavailable`
|
||||
- User approval status for suggested registration language
|
||||
|
||||
### 15.5 Initial U.S. Copyright Office policy profile
|
||||
|
||||
The initial policy profile MUST be a versioned, read-only profile scoped to **United States / literary work / Standard Application**. It MUST identify its effective application scope and MUST refuse to produce application-field suggestions for unsupported jurisdictions, work classes, group registrations, or application types.
|
||||
|
||||
The initial profile MUST cite, at minimum, the following official sources with retrieval date `2026-07-19`:
|
||||
|
||||
- [Copyright Registration Guidance: Works Containing Material Generated by Artificial Intelligence](https://www.copyright.gov/ai/ai_policy_guidance.pdf), effective March 16, 2023
|
||||
- [Copyright and Artificial Intelligence, Part 2: Copyrightability](https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf), January 2025
|
||||
- [Standard Application Help: Author](https://www.copyright.gov/eco/help-author.html)
|
||||
- [Standard Application Help: Limitation of Claim](https://www.copyright.gov/eco/help-limitation.html)
|
||||
- [37 C.F.R. § 202.3](https://www.copyright.gov/title37/202/37cfr202-3.html)
|
||||
|
||||
The profile MUST encode field terminology separately from evidentiary classifications and MUST support suggested text for `Author Created`, `Material Excluded`, `New Material Included`, and, when appropriate, `Note to CO`. The `Author Created` and `New Material Included` suggestions MUST remain mutually consistent. The profile MUST disclose recorded use of AI and MUST support describing human contributions and excluding more-than-de-minimis AI-generated content as directed by the cited guidance, while leaving case-specific judgment and the final wording to the user and the Office. Every suggestion screen and generated worksheet MUST state that the text is suggested, editable, not legal advice, and subject to Copyright Office review.
|
||||
|
||||
Policy rules MUST NOT convert CPL activity metrics or recorded-origin categories into copyrightability conclusions. Prompts, selection/arrangement, and modifications MAY be described as evidence only; their legal sufficiency MUST remain undetermined. A published profile is immutable. A policy update creates a new profile version; it MUST NOT silently change or regenerate an existing HARP. A HARP bound to a superseded profile remains historically reproducible and MUST visibly disclose that profile status.
|
||||
|
||||
## 16. Derived indexes
|
||||
|
||||
Derived indexes MUST be reproducible from authoritative records. Deterministic index content MUST use stable sorting, locale-independent comparison, canonical inputs, fixed schema/configuration, no random identifiers, and no current timestamp.
|
||||
@@ -444,16 +571,28 @@ A purge MAY rewrite affected records, ledger hashes, and Git history only throug
|
||||
|
||||
Ordinary editing MUST NOT invoke purge behavior.
|
||||
|
||||
## 23. Legacy preview projects
|
||||
## 23. Legacy preview projects and CPL conformance boundary
|
||||
|
||||
Thinkloom 1.0 MUST detect known preview/experimental project markers and refuse normal opening or editing. It MUST preserve the original project untouched, explain that migration is deferred, offer Show Project Folder, and permit a byte-preserving raw archival ZIP labeled:
|
||||
Only a project with the exact, supported conformance marker below MAY be treated as CPL-conforming:
|
||||
|
||||
```text
|
||||
Legacy project preservation archive
|
||||
Not verified or converted by Thinkloom 1.0.0
|
||||
```json
|
||||
{
|
||||
"project_format": "thinkloom-cpl",
|
||||
"project_format_version": "1.0",
|
||||
"provenance_conformance": "cpl-1.0"
|
||||
}
|
||||
```
|
||||
|
||||
Thinkloom 1.0 MUST NOT import legacy records into schema 1.0, regenerate or verify their provenance under 1.0 rules, create a 1.0 evidence report, modify their Git history, or present them as migrated. Formal legacy reading, conversion, and migration begin after 1.0.0.
|
||||
The marker is necessary but not sufficient: schema compatibility, required CPL structure, startup recovery, and native verification gates still apply. A `schemaVersion: 1.0` field or any preview-era marker MUST NOT be interpreted as this conformance marker.
|
||||
|
||||
Thinkloom 0.6 and later MUST detect projects created by any v0.5.x release or earlier and other known preview/experimental project markers before any project mutation. It MUST refuse normal opening, editing, provenance regeneration, CPL verification, and HARP generation. It MUST preserve the original project untouched, explain that migration is deferred until after Thinkloom 1.0.0, offer Show Project Folder, and permit a byte-preserving raw archival ZIP labeled:
|
||||
|
||||
```text
|
||||
Legacy preview-project preservation archive
|
||||
Not verified, converted, or CPL-conforming
|
||||
```
|
||||
|
||||
Thinkloom MUST NOT import legacy records into CPL schema 1.0, synthesize CPL events from legacy state, regenerate or verify their provenance under CPL rules, create a HARP or CPL evidence report, modify their Git history, or present them as migrated or partially conforming. Formal legacy reading, conversion, and migration begin only after Thinkloom 1.0.0 and require a future normative migration specification.
|
||||
|
||||
## 24. Formal schema inventory for Stage 2
|
||||
|
||||
@@ -500,9 +639,16 @@ release-manifest.schema.json
|
||||
release-state.schema.json
|
||||
sanitized-export-manifest.schema.json
|
||||
purge-manifest.schema.json
|
||||
composition-operation.schema.json
|
||||
expression-segment.schema.json
|
||||
contribution-map.schema.json
|
||||
deposit-snapshot.schema.json
|
||||
registration-policy-profile.schema.json
|
||||
human-authorship-record.schema.json
|
||||
harp-export-manifest.schema.json
|
||||
```
|
||||
|
||||
Prompt-template, provenance-assertion, and other self-digesting schemas MUST define exact digest identity objects. Migration schemas are deferred until after Thinkloom 1.0.0.
|
||||
Prompt-template, provenance-assertion, contribution-map, registration-policy-profile, human-authorship-record, HARP export-manifest, and other self-digesting schemas MUST define exact digest identity objects. Migration schemas are deferred until after Thinkloom 1.0.0.
|
||||
|
||||
## 25. Required implementation characteristics
|
||||
|
||||
|
||||
@@ -0,0 +1,55 @@
|
||||
# Stage 10 — Export, privacy, and security
|
||||
|
||||
Status: **Complete for Thinkloom 0.5.10**
|
||||
|
||||
Milestone/version rule: **Milestone 10 → 0.5.10**
|
||||
|
||||
## Delivered artifacts
|
||||
|
||||
The native HARP export service creates six separate artifacts from one current, exact-deposit HARP:
|
||||
|
||||
1. registration worksheet;
|
||||
2. human-readable HARP;
|
||||
3. canonical machine-readable HARP;
|
||||
4. exact deposit copy;
|
||||
5. sanitized supporting archive; and
|
||||
6. full private archive.
|
||||
|
||||
The exact machine-readable HARP and deposit remain unchanged private artifacts. User-selected author-name redaction applies only to sanitized human-readable presentations. A stale HARP or a deposit whose bytes no longer match its recorded digest cannot be exported.
|
||||
|
||||
## Sanitized archive boundary
|
||||
|
||||
The sanitized archive is assembled from an allowlist of derived presentation and structural-evidence files. It never copies raw records or ledger segments and excludes the deposit and full machine-readable HARP. Its omission manifest always addresses:
|
||||
|
||||
- private conversations;
|
||||
- rejected model output;
|
||||
- credentials and authorization material;
|
||||
- personal identifiers selected for redaction;
|
||||
- internal paths;
|
||||
- provider metadata not required for disclosure; and
|
||||
- protected source bodies.
|
||||
|
||||
Each omission entry contains its category, action, affected-record count, retained-evidence binding digest, and disclosure digest. The manifest separately hashes the ordered omission-rule set.
|
||||
|
||||
## Verification and completeness
|
||||
|
||||
Before publication, the native verifier reopens the sanitized ZIP and checks:
|
||||
|
||||
- every required omission category is present;
|
||||
- every disclosure digest and the aggregate rules digest recompute;
|
||||
- every retained file exists and matches its byte length and SHA-256 binding; and
|
||||
- the CPL chain head, HARP digest, and deposit digest match the expected source bindings.
|
||||
|
||||
Success is reported as `verified_selective`, never as complete. The manifest declares `selective_disclosed_subset` and states that verification covers disclosed retained evidence only. It does not claim that omitted private history is present or that provenance integrity decides identity or legal authorship.
|
||||
|
||||
Export writes only derived files under `exports/harp/`. It does not append a CPL event, rewrite a record, advance the source chain, or alter the exact deposit. The full private archive carries an explicit sharing warning and includes the exact deposit, private HARP artifacts, records, ledger segments, and generated report material.
|
||||
|
||||
## Acceptance evidence
|
||||
|
||||
- A native integration test generates an exact HARP, creates all six artifacts, and proves the CPL chain head is unchanged.
|
||||
- The test confirms the sanitized ZIP contains no raw records, ledger segments, deposit copy, or exact machine HARP and that selected identity text is absent.
|
||||
- The same test confirms the full private archive retains the deposit, records, and ledger.
|
||||
- Schema vectors validate the selective completeness claim and recompute every omission-disclosure digest.
|
||||
- UI tests cover artifact separation, redaction selection, privacy warnings, omission disclosure, and re-verification.
|
||||
|
||||
Unmarked preview projects retain the preservation-only boundary and cannot use HARP export commands.
|
||||
@@ -0,0 +1,44 @@
|
||||
# Stage 11 — Verification matrix
|
||||
|
||||
Status: **Complete for Thinkloom 0.5.11**
|
||||
|
||||
Milestone/version rule: **Milestone 11 → 0.5.11**
|
||||
|
||||
## Release rule
|
||||
|
||||
Release finalization is a native security boundary. Immediately before changing `project.json`, appending `RELEASE_FINALIZED`, committing, or tagging, Thinkloom runs the authoritative native CPL verifier. Only `VERIFIED` and `VERIFIED_WITH_WARNINGS` may proceed. `INCOMPLETE`, `FAILED`, and `UNSAFE` return `RELEASE_VERIFICATION_BLOCKED` without creating release state. The frontend uses the same five native status values and does not optimistically mark a release finalized.
|
||||
|
||||
## Executable matrix
|
||||
|
||||
| Required scenario | Executable coverage |
|
||||
| --- | --- |
|
||||
| Schema fixtures and deterministic regeneration | `provenance-schema.test.mjs`; generated fixture and vector diff gate |
|
||||
| Canonical JSON, Unicode, timestamps, paths, and JSONL | Schema vector suite plus native canonical and identifier tests |
|
||||
| Duplicate action and concurrent writer behavior | Native idempotency, conflict, OS-lock, and concurrent-preimage tests |
|
||||
| Failure after every durable write phase | Native crash injection for record, ledger, chain-head, SQLite, and segment-rotation boundaries |
|
||||
| Segment rotation and cross-segment verification | Native sealed/active segment linkage and recovery tests |
|
||||
| Manual typing and deletion | Typed Phase 1 replay and native composition deletion test |
|
||||
| Paste/import behavior | Instrumented paste signal and imported-origin replay test |
|
||||
| Human revision of AI-origin material | Native mixed-origin transformation/revision lineage test |
|
||||
| AI transformation of human material | Native AI-acceptance replacement with source lineage test |
|
||||
| Partial AI acceptance | Exact accepted/rejected Unicode scalar disposition test |
|
||||
| Selection and arrangement without changing origin | Origin-preserving native move implementation and mismatch refusal test |
|
||||
| Voice transcription with no audio persistence | Typed transcription record and no-audio path/digest/file tests |
|
||||
| Restore and checkpoint lineage | Restoration replay, checkpoint flush, and immutable record tests |
|
||||
| Unknown and unattested spans | Unverified coverage and boundary tests without negative authorship inference |
|
||||
| Deposit/HARP staleness | Frozen-map and HARP dependency/revision staleness tests |
|
||||
| Complete segment coverage across complex Unicode | Combining mark, modifier, ZWJ, flag, CJK, and CRLF scalar coverage test |
|
||||
| Native verifier/frontend consistency | Shared status-set test plus native and frontend release gates |
|
||||
| Sanitized archive disclosure | Omission-category, retained-file, binding, and selective-scope tests |
|
||||
| Prohibited score/legal wording | Production-source scan for numeric human scores and affirmative legal conclusions |
|
||||
| Packaged Windows end-to-end | Release executable PE check, MSI and NSIS signature/version checks, and hidden launch smoke test |
|
||||
|
||||
`tests/verification-matrix.test.mjs` is the executable index for this table. It fails if a required native or frontend case disappears. `tests/windows-package.test.mjs` is intentionally a post-build Windows gate and is run by `npm run verify:windows-package`.
|
||||
|
||||
## Origin-preserving arrangement
|
||||
|
||||
A `move` operation may only rearrange the exact existing Unicode scalar multiset. Thinkloom moves the existing lineage units, retaining recorded origin, ancestry, lineage references, and prior operation references, while appending the move operation identity. A move that inserts, deletes, or substitutes content is rejected before any CPL event is committed.
|
||||
|
||||
## Interpretation boundary
|
||||
|
||||
The matrix verifies integrity, chronology, replay, origin records, transformation records, coverage, disclosure, and release safety. It does not produce a human-authorship score or determine legal authorship, originality, copyrightability, ownership, or registrability.
|
||||
@@ -1,43 +1,71 @@
|
||||
# Thinkloom Stage 2 Provenance Schema Package
|
||||
|
||||
Status: **Complete for Thinkloom 0.4.0**
|
||||
Schema family: **1.0**
|
||||
Status: **Complete for Thinkloom 0.5.2**
|
||||
|
||||
Schema family: **1.0, additive catalog 1.1**
|
||||
|
||||
Dialect: **JSON Schema Draft 2020-12**
|
||||
|
||||
CPL runtime target: **Thinkloom 0.6.0**
|
||||
|
||||
Runtime conformance: **Not yet implemented**
|
||||
|
||||
## Scope
|
||||
|
||||
Stage 2 formalizes the approved provenance architecture without changing native application behavior. It provides deterministic contracts and verification evidence for the later native-writer implementation. Migration support remains deferred until after Thinkloom 1.0.0.
|
||||
The 0.5.2 package extends the existing provenance schema family with composition-specific records rather than overloading v0.4 assertions or edit transactions. It formalizes the normative HARP/CPL model without changing native application behavior. Existing v0.4 `provenance-assertion` and `assertion-evaluation` instances and semantics remain valid.
|
||||
|
||||
Migration support remains deferred until after Thinkloom 1.0.0. Projects created before the Milestone 4 marker remain preview projects and MUST NOT be represented as CPL-conforming merely because these schemas are present.
|
||||
|
||||
## Package
|
||||
|
||||
The machine-readable package is in [`schemas/provenance/v1`](../../schemas/provenance/v1/README.md). `catalog.json` identifies all 40 schemas, the schema and application versions, compatibility, fixture locations, and the generator.
|
||||
The machine-readable package is in [`schemas/provenance/v1`](../../schemas/provenance/v1/README.md). `catalog.json` identifies all 47 schemas, 14 registries, package/schema/application versions, per-entry introduction and compatibility, fixture locations, the v0.6.0 runtime target, and the generator.
|
||||
|
||||
The seven additive schemas are:
|
||||
|
||||
- `composition-operation.schema.json`
|
||||
- `expression-segment.schema.json`
|
||||
- `contribution-map.schema.json`
|
||||
- `deposit-snapshot.schema.json`
|
||||
- `registration-policy-profile.schema.json`
|
||||
- `human-authorship-record.schema.json`
|
||||
- `harp-export-manifest.schema.json`
|
||||
|
||||
Each schema has:
|
||||
|
||||
- one valid canonical fixture;
|
||||
- invalid cases for every top-level required field and the closed-object policy;
|
||||
- populated nested cases for enum, const, pattern, numeric, string, and array bounds; and
|
||||
- explicit conditional failures for protected records, recovery envelopes, assertion generations, and exact evaluation rules where ordinary keyword mutation is insufficient.
|
||||
- explicit conditional failures for operation/origin consistency and exact-classification identity, generation, origin, lineage, AI-system identity, coverage, and applicability boundaries.
|
||||
|
||||
## Independent registries
|
||||
|
||||
The package adds versioned registries for:
|
||||
|
||||
- composition operation kinds;
|
||||
- recorded origin kinds;
|
||||
- transformation relationships;
|
||||
- contribution-map layers;
|
||||
- suggested registration treatments;
|
||||
- HARP limitation codes;
|
||||
- HARP explanation codes; and
|
||||
- composition assertion predicates: `derived_from`, `generated_by`, `modified_by_human`, `selected_by_human`, `arranged_by_human`, and `included_in_deposit`.
|
||||
|
||||
Recorded origin, transformation, selection/arrangement, evidentiary evaluation, and suggested registration treatment remain independent. A paste cannot default to direct human input, and selection/arrangement cannot alter text origin.
|
||||
|
||||
## Deterministic vectors
|
||||
|
||||
The vector suite covers:
|
||||
In addition to the existing canonicalization, ledger, assertion, privacy, backup, and release vectors, the suite now covers:
|
||||
|
||||
- RFC 8785-compatible serialization after Thinkloom Unicode NFC preprocessing;
|
||||
- prohibited non-finite, undefined, and NFC-colliding values;
|
||||
- exact millisecond UTC timestamps and repository-relative path restrictions;
|
||||
- LF-only canonical JSONL, contiguous events, event self-digests, and cross-segment seals;
|
||||
- prompt-template, protected-record, event, and release self-digest identities;
|
||||
- minimal and full-private retention behavior;
|
||||
- device and recovery key envelopes plus key rotation;
|
||||
- non-mutating sanitized exports and omission-rule disclosure;
|
||||
- deterministic derived indexes;
|
||||
- backup and release manifests plus the release-files Merkle root;
|
||||
- all verification statuses and finding severities;
|
||||
- immutable assertion envelopes and exact self-digest identity;
|
||||
- point-in-time exact, degraded, refused, stale, and unverified evaluations; and
|
||||
- versioned reason, lifecycle, confidence, evidence, boundary, and consumer-decision registries.
|
||||
- all composition-operation origin rules;
|
||||
- exact expression-segment classification boundaries;
|
||||
- refusal of exact HARP classification for unknown origin, identity, generation, lineage, or AI-system identity;
|
||||
- complete ordered non-overlapping Unicode-scalar contribution-map coverage;
|
||||
- byte-stable map generation from different input orders;
|
||||
- contribution-map, policy-profile, HARP, and HARP-manifest self-digest identities;
|
||||
- exact deposit, manuscript revision, CPL head, policy profile, and export-manifest bindings;
|
||||
- HARP staleness after a later manuscript revision without invalidating historical deposit integrity;
|
||||
- explicit approval of editable suggested registration language; and
|
||||
- prohibited human/AI percentage and legal-score fields.
|
||||
|
||||
## Verification
|
||||
|
||||
@@ -47,14 +75,14 @@ Regenerate deterministically:
|
||||
npm run provenance:schema:generate
|
||||
```
|
||||
|
||||
Validate schemas, fixtures, and vectors:
|
||||
Validate schemas, fixtures, registries, and vectors:
|
||||
|
||||
```powershell
|
||||
npm run provenance:schema:test
|
||||
```
|
||||
|
||||
The schema tests are also part of `npm test`. Generated output must be committed with its generator and tests. A clean regeneration is required before changing any formal schema or vector.
|
||||
The schema tests are also part of `npm test`. Generated output must be committed with its generator and tests. A clean second regeneration must produce no changes.
|
||||
|
||||
## Next boundary
|
||||
|
||||
Thinkloom 0.4.0 must not claim native provenance conformance. The next implementation stage replaces the MVP persistence path with the approved single-writer protocol and then executes the durable-boundary fault-injection matrix.
|
||||
Thinkloom 0.5.2 is schema-complete for this milestone but MUST NOT claim native CPL or HARP runtime conformance. Thinkloom 0.5.3 subsequently implemented the native CPL service and its core crash-injection matrix. Thinkloom 0.5.4 then established the exact-marker project boundary; all earlier unmarked projects remain read-only previews.
|
||||
|
||||
@@ -0,0 +1,111 @@
|
||||
# Stage 3 Native CPL Service
|
||||
|
||||
Status: **Complete for Thinkloom 0.5.3**
|
||||
|
||||
Implementation milestone: **3**
|
||||
|
||||
Application release: **Thinkloom 0.5.3**
|
||||
|
||||
Schema family: **Provenance 1.0 with the additive 0.5.2 composition/HARP package**
|
||||
|
||||
Project-format conformance target: **Thinkloom 0.6.0 / CPL 1.0**
|
||||
|
||||
## Outcome
|
||||
|
||||
Thinkloom 0.5.3 replaces frontend and monolithic Rust provenance authority with one modular native Composition Provenance Ledger service. The service creates immutable records, assigns contiguous event sequences, writes canonical ledger events, advances the chain head, maintains rebuildable SQLite indexes, performs recovery, and returns structured native verification reports.
|
||||
|
||||
The implementation is organized under `src-tauri/src/provenance/`:
|
||||
|
||||
```text
|
||||
canonical.rs
|
||||
identifiers.rs
|
||||
records.rs
|
||||
writer.rs
|
||||
ledger.rs
|
||||
recovery.rs
|
||||
verifier.rs
|
||||
composition.rs
|
||||
assertions.rs
|
||||
projections.rs
|
||||
harp.rs
|
||||
export.rs
|
||||
```
|
||||
|
||||
## Canonical identity
|
||||
|
||||
The native canonicalization implementation:
|
||||
|
||||
- Normalizes JSON keys and string values to Unicode NFC.
|
||||
- Rejects NFC key collisions.
|
||||
- Orders object keys using RFC 8785 UTF-16 ordering.
|
||||
- Emits UTF-8 without a BOM and JSONL with LF delimiters.
|
||||
- Applies deterministic JSON number rendering, including normalized exponent signs and negative zero.
|
||||
- Produces lowercase `sha256:` digest strings.
|
||||
- Defines explicit identity objects for records and events, excluding only their respective self-digest fields.
|
||||
|
||||
Native tests reproduce the Stage 2 key-order, NFC, and number vectors. Canonical timestamps use RFC 3339 UTC with exactly millisecond precision. Native identifiers use type prefixes plus a sortable millisecond and per-millisecond sequence component.
|
||||
|
||||
## Single-writer transaction
|
||||
|
||||
Each mutation receives a stable `client_action_id` and executes while holding an exclusive operating-system file lock for that project. The lock is held only for native provenance mutation and recovery; provider calls and Git work remain outside it.
|
||||
|
||||
The writer follows the normative phase sequence:
|
||||
|
||||
```text
|
||||
PREPARED
|
||||
RECORDS_DURABLE
|
||||
LEDGER_APPENDED
|
||||
CHAIN_HEAD_ADVANCED
|
||||
SQLITE_APPLIED
|
||||
COMPLETE
|
||||
```
|
||||
|
||||
Unsafe or abandoned operations finish as `QUARANTINED` or `FAILED`. Immutable records are canonicalized and flushed in same-filesystem staging before atomic movement into `records/`. The event sequence is derived from the verified ledger immediately before append and is never reserved by SQLite.
|
||||
|
||||
Committed action receipts make identical retries return the original event and record references. Reusing the same action ID with a different canonical command digest is an integrity error.
|
||||
|
||||
## Segmented ledger and recovery
|
||||
|
||||
The ledger maintains one active JSONL segment and immutable sealed segments. Default rotation thresholds are 10,000 events or 10 MiB. Each sealed manifest binds its previous segment digest, event range, event count, byte length, file digest, and seal timestamp.
|
||||
|
||||
Recovery runs under the writer lock and can:
|
||||
|
||||
- Remove an unreferenced incomplete active JSONL suffix.
|
||||
- Complete an interrupted segment-manifest move after validating its digest.
|
||||
- Advance a chain head that is behind a complete durable event.
|
||||
- Reconstruct a missing head from the verified final event.
|
||||
- Quarantine staged or final immutable records that have no committed event.
|
||||
- Replay committed actions and rebuild SQLite event, record, and idempotency indexes.
|
||||
- Refuse automatic repair when the head is ahead of the readable ledger or an authoritative contradiction exists.
|
||||
|
||||
## Native verification
|
||||
|
||||
The verifier returns the normative `VERIFIED`, `VERIFIED_WITH_WARNINGS`, `INCOMPLETE`, `FAILED`, or `UNSAFE` status with scoped findings. It checks:
|
||||
|
||||
- Project identity, exact timestamps, contiguous sequences, previous-event links, and event digests.
|
||||
- Active and sealed segment readability and sealed-manifest bindings.
|
||||
- Chain-head agreement with the final readable event.
|
||||
- Safe record paths, canonical record bytes, record identity, and referenced digests.
|
||||
- Registered assertion and evaluation structure when those record types are present.
|
||||
- Rebuildable SQLite index agreement, reported only as a warning when stale or unavailable.
|
||||
|
||||
React no longer creates provenance hashes, chain heads, authoritative events, evidence-package hashes, or a local “valid” result. It supplies a stable action identifier and renders only the native verification report. Browser fallback explicitly refuses to synthesize an evidence package.
|
||||
|
||||
## Verification matrix
|
||||
|
||||
The Rust suite injects deterministic termination after every native writer durability boundary:
|
||||
|
||||
- Write-intent creation.
|
||||
- First staged record write.
|
||||
- Record flush, atomic move, and directory durability step.
|
||||
- Active-segment and sealed-manifest flushes.
|
||||
- Segment and manifest moves and next-active-segment creation.
|
||||
- Ledger append before flush and after flush.
|
||||
- Chain-head temporary write, atomic replacement, and directory durability step.
|
||||
- SQLite application and final completion.
|
||||
|
||||
For every point, recovery proves that the action is absent and retryable, committed and idempotently discoverable, deterministically completed, or quarantined without false success. Separate tests cover concurrent writers, conflicting retries, cross-segment verification, tamper detection, and SQLite reconstruction.
|
||||
|
||||
## Release boundary
|
||||
|
||||
Thinkloom 0.5.3 completes Milestone 3 and provides the native CPL service, but remains a v0.5 preview release. It does not add the unambiguous conforming project marker or convert existing preview projects. Milestone 4, released as 0.5.4 under the milestone/version convention, subsequently established that project boundary. The limitation in this Stage 3 record continues to apply to every unmarked project.
|
||||
@@ -0,0 +1,91 @@
|
||||
# Stage 4 — Conforming project boundary
|
||||
|
||||
Status: **Complete for Thinkloom 0.5.4**
|
||||
|
||||
Milestone/version rule: **Milestone 4 → 0.5.4**
|
||||
|
||||
Project format: **thinkloom-cpl 1.0**
|
||||
Provenance conformance marker: **cpl-1.0**
|
||||
|
||||
## Outcome
|
||||
|
||||
Thinkloom 0.5.4 establishes an unambiguous boundary between newly created CPL projects and every earlier preview project. The opener classifies a selected directory by reading `project.json` and the minimum required structure before it invokes recovery, verification, SQLite, Git, or any other mutating service.
|
||||
|
||||
Only this exact marker is supported:
|
||||
|
||||
```json
|
||||
{
|
||||
"project_format": "thinkloom-cpl",
|
||||
"project_format_version": "1.0",
|
||||
"provenance_conformance": "cpl-1.0"
|
||||
}
|
||||
```
|
||||
|
||||
`schemaVersion: "1.0"`, `schema_version: "1.0"`, an incomplete marker, or a differently versioned marker is not sufficient.
|
||||
|
||||
## New-project contract
|
||||
|
||||
New 0.5.4 projects:
|
||||
|
||||
- serialize the formal snake-case project manifest;
|
||||
- include the exact supported marker;
|
||||
- bind the initial project manifest and provenance policy as immutable CPL records;
|
||||
- initialize `records/`, active and sealed `provenance/ledger/` storage, `reports/`, and operational `.app/` storage;
|
||||
- keep writer locks under `.app/locks/`, same-filesystem staging under `.app/temp/staging/`, recovery quarantine under `.app/recovery/`, and SQLite under `.app/state.sqlite`;
|
||||
- pass CPL recovery and native verification before becoming editable when reopened.
|
||||
|
||||
The marker is necessary but not sufficient. Missing required directories produce `CPL_BLOCKED`; an integrity result other than `VERIFIED` or `VERIFIED_WITH_WARNINGS` also leaves the project unavailable for editing.
|
||||
|
||||
## Classification states
|
||||
|
||||
| Classification | Meaning | Permitted actions |
|
||||
| --- | --- | --- |
|
||||
| `CPL_CONFORMING` | Exact marker, supported schema and required structure; native recovery and verification pass | Normal editable opening |
|
||||
| `LEGACY_PREVIEW_READ_ONLY` | Marker absent, including v0.5 projects with only `schemaVersion: "1.0"` | Explain, Show Project Folder, preservation archive |
|
||||
| `UNSUPPORTED_READ_ONLY` | Invalid, partial, or unsupported marker/manifest | Explain and Show Project Folder |
|
||||
| `CPL_BLOCKED` | Exact marker is present, but structure, schema compatibility, recovery, or integrity gate fails | Explain and Show Project Folder; no editable activation |
|
||||
|
||||
Classification itself is read-only. A read-only selection clears the active editable project so subsequent persistence and provenance commands cannot target either the legacy project or a previously open project by mistake.
|
||||
|
||||
## Legacy preservation
|
||||
|
||||
Thinkloom does not load legacy state into the editor and does not invoke CPL recovery for an unmarked project. The UI exposes only:
|
||||
|
||||
- **Show project folder**; and
|
||||
- **Create preservation archive** for `LEGACY_PREVIEW_READ_ONLY` projects.
|
||||
|
||||
The archive must be saved outside the source project. It stores each source file without content transformation, retains directory and symbolic-link entries, and includes this label:
|
||||
|
||||
```text
|
||||
Legacy preview-project preservation archive
|
||||
Not verified, converted, or CPL-conforming
|
||||
```
|
||||
|
||||
The native implementation inventories the source before and after archive creation. If any entry changes during the operation, it removes the incomplete destination archive and reports a retryable failure. Legacy backup import is explicitly refused.
|
||||
|
||||
## Prohibited legacy behavior
|
||||
|
||||
Before a future post-1.0 migration specification, Thinkloom 0.5.4 does not:
|
||||
|
||||
- add a marker to a legacy project;
|
||||
- convert or import legacy preview data into CPL;
|
||||
- synthesize records or ledger events;
|
||||
- run CPL recovery or represent legacy provenance as verified;
|
||||
- modify Git history;
|
||||
- generate CPL evidence or HARP artifacts.
|
||||
|
||||
## Acceptance evidence
|
||||
|
||||
Native tests prove that:
|
||||
|
||||
- `schemaVersion: "1.0"` without the marker is classified as legacy;
|
||||
- inspection leaves the complete source inventory unchanged;
|
||||
- exact markers remain blocked until the required layout exists;
|
||||
- partial and unsupported markers never enter recovery;
|
||||
- preservation archives reproduce arbitrary binary file bytes while leaving the source inventory unchanged.
|
||||
|
||||
Static application acceptance tests additionally enforce inspection-before-recovery ordering, `.app` operational paths, exact marker constants, legacy-only controls, and the absence of `.thinkloom` runtime storage.
|
||||
|
||||
## Remaining boundary
|
||||
|
||||
Milestone 4 establishes project-format and opener conformance only. Phase 1 typed reconstruction is assigned to Milestone 5 / 0.5.5. Composition transaction lineage, contribution-map generation, HARP generation, dedicated CPL/HARP interfaces, export hardening, and the full release verification matrix remain assigned to later milestones. No HARP or legal conclusion is produced by this milestone.
|
||||
@@ -0,0 +1,62 @@
|
||||
# Stage 5 — Phase 1 CPL routing
|
||||
|
||||
Status: **Complete for Thinkloom 0.5.5**
|
||||
|
||||
Milestone/version rule: **Milestone 5 → 0.5.5**
|
||||
|
||||
## Outcome
|
||||
|
||||
Thinkloom 0.5.5 removes the generic `persist_state` provenance route. Phase 1 now submits typed native commands to the CPL service, and the ideation workspace is reconstructed by replaying canonical `phase1-operation` records in ledger order. SQLite's `phase1_projection` table is a disposable cache and can be rebuilt from the ledger and immutable records.
|
||||
|
||||
The React state object is no longer written as an authoritative record or SQLite recovery source. Canonical Phase 1 replay covers:
|
||||
|
||||
- human typed turns and voice-mediated human turns;
|
||||
- retained assistant responses and their provider invocation identity;
|
||||
- session creation, activation, and title revision;
|
||||
- persona, challenge level, genre, lore, provider context, and cloud-approval changes;
|
||||
- idea creation, merging, selection/status changes, and every idea revision;
|
||||
- human or assistant transcript turns appended to the drafting paper;
|
||||
- manual drafting-paper edits and clearing;
|
||||
- distillation request, response, and accepted disposition;
|
||||
- pasted/imported/external material declarations; and
|
||||
- provider invocation requests, responses, and bounded failures.
|
||||
|
||||
## Record model
|
||||
|
||||
Every Phase 1 event binds exactly one authoritative `phase1-operation` record containing a validated `Phase1Command`. The same event also binds operation-specific evidence records such as `transcript-turn`, `idea-revision`, `drafting-paper-revision`, `invocation-request`, `invocation-response`, `invocation-failure`, `disposition-revision`, and `source-declaration`.
|
||||
|
||||
Typed commands use stable `client_action_id` values and the native writer's existing idempotency, canonicalization, writer lock, staging, ledger, chain-head, and recovery rules. They set `operational_state` to `None`; the former `application-state-snapshot` route is not used by the application.
|
||||
|
||||
## Provider lifecycle boundary
|
||||
|
||||
Before a model request or provider connectivity request performs network I/O, the runtime commits a `ProviderInvocationRequested` command containing:
|
||||
|
||||
- invocation and session identifiers;
|
||||
- purpose and provider context;
|
||||
- canonical digests for prompt template, input, and supplied context; and
|
||||
- the exact request time.
|
||||
|
||||
The CPL write completes and releases the exclusive writer lock before provider I/O begins. A successful call is followed by `ProviderInvocationResponded`; an error or unsuccessful connectivity result is followed by `ProviderInvocationFailed` with a bounded summary. A retained assistant turn separately binds the response to the visible conversation.
|
||||
|
||||
## Voice and external material
|
||||
|
||||
Voice recognition yields a human `transcript-turn` with `input_mode: voice_transcription`. Its companion record fixes `audio_retained` to `false` and `audio_reference` to null. No audio body, path, identifier, or digest is recorded.
|
||||
|
||||
Paste handlers prevent an undeclared state-only insertion and instead commit `ExternalContentDeclared` with the retained text, target, resulting text, and the writer-facing declaration. Paste is recorded as external material; it is not automatically classified as human-authored.
|
||||
|
||||
## Reconstruction and recovery
|
||||
|
||||
`load_phase1_projection` reads canonical ledger events and records. It does not load a serialized React object. Recovery index rebuilding also reconstructs the disposable Phase 1 cache from those canonical inputs. Derived `ideas/ideas.json` and `conversations/sessions.json` files are convenience mirrors, not replay authority.
|
||||
|
||||
Focused native tests prove:
|
||||
|
||||
- typed records reconstruct Phase 1 after deleting the projection cache;
|
||||
- reconstruction does not require `application-state-snapshot`;
|
||||
- a provider request is durable before simulated I/O and another writer can proceed between request and outcome; and
|
||||
- voice transcription retains text without an audio reference or audio digest.
|
||||
|
||||
Static acceptance tests additionally ensure the frontend uses the typed command/projection routes, all required command and evidence families exist, and response/failure recording follows provider I/O.
|
||||
|
||||
## Boundary retained
|
||||
|
||||
This milestone instruments Phase 1 only. Manuscript transaction capture, surviving-expression lineage, partial AI acceptance ranges, contribution maps, HARP generation, and dedicated CPL/HARP interfaces remain assigned to later milestones. Thinkloom 0.5.5 does not generate HARP, infer copyrightability, or convert unmarked preview projects.
|
||||
@@ -0,0 +1,42 @@
|
||||
# Stage 6 — Manuscript composition and lineage
|
||||
|
||||
Status: **Complete for Thinkloom 0.5.6**
|
||||
|
||||
Milestone/version rule: **Milestone 6 → 0.5.6**
|
||||
|
||||
## Delivered boundary
|
||||
|
||||
Thinkloom 0.5.6 makes typed native composition commands the authoritative manuscript history. TipTap/ProseMirror `onUpdate` transactions are coalesced at idle, focus-loss, section-change, AI-operation, checkpoint, phase-change, explicit-save, and document-close boundaries. Paste, drop/move, and restoration have explicit boundary signals as well. The drafting and finalization views use the same structured editor; no finalization textarea can bypass CPL capture.
|
||||
|
||||
Every command supplies the exact prior and resulting manuscript. Native replay rejects stale preimages and no-op commands before an event is committed. A Unicode-scalar prefix/suffix diff derives the changed range without using edit counts, elapsed time, word counts, retained-word ratios, or any other originality heuristic.
|
||||
|
||||
## Recorded origins and lineage
|
||||
|
||||
Inserted expression is classified as one of:
|
||||
|
||||
- recorded direct human input;
|
||||
- human expressive input via transcription;
|
||||
- accepted AI output;
|
||||
- imported or pasted material;
|
||||
- system restoration; or
|
||||
- unattested expression.
|
||||
|
||||
Paste is explicitly mapped to `imported_or_pasted`, never automatically to human authorship. New or legacy manuscript baselines that lack composition evidence are initialized as `unattested`.
|
||||
|
||||
The native projection tracks lineage per normalized Unicode scalar and emits complete, non-overlapping expression spans. Each span carries stable ancestry, lineage references, operation references, origin, exact text, and a content digest. When a writer revises AI-origin text, replacement units reference the deleted AI ancestry and operation chain, preserving both the AI preimage and the later human operation.
|
||||
|
||||
## AI acceptance
|
||||
|
||||
AI acceptance records bind the provider invocation, retained response, accepted scalar ranges, rejected scalar ranges, partial/full disposition, operation, and result manuscript revision. Native validation requires non-empty in-range spans, rejects overlaps, requires complete scalar coverage, and verifies that the partial flag agrees with the rejected disposition.
|
||||
|
||||
## Canonical replay and derived files
|
||||
|
||||
The immutable `composition-command` record is the authoritative replay input. Each edit also emits `composition-operation`, `composition-content`, `manuscript-revision`, and `expression-segment` records; AI acceptance adds `ai-acceptance-disposition`. SQLite's `composition_projection` is disposable and rebuilt from ledger events and canonical records. `manuscript/manuscript.md` is written only from the resulting native projection.
|
||||
|
||||
Composition preparation and its CPL write execute under the same exclusive project writer lock, so concurrent clients cannot commit two edits against the same preimage. The UI additionally serializes composition commands in submission order.
|
||||
|
||||
## Acceptance evidence
|
||||
|
||||
The Rust suite verifies mixed manual, paste, AI, human-revision, and restoration replay; Unicode-scalar partial-AI ranges; rejection of stale preimages without ledger mutation; exactly-one concurrent preimage commits; and idempotent retries with action-ID conflict detection. Static application tests verify the shared editor path, required boundaries and origins, paste classification, AI range bindings, canonical replay, and cache rebuild integration.
|
||||
|
||||
Milestone 6 did not itself produce the contribution-map projection or HARP. The contribution-map projection is delivered by Milestone 7 / 0.5.7; HARP remains assigned to Milestone 8.
|
||||
@@ -0,0 +1,44 @@
|
||||
# Stage 7 — Contribution-map projection
|
||||
|
||||
Status: **Complete for Thinkloom 0.5.7**
|
||||
|
||||
Milestone/version rule: **Milestone 7 → 0.5.7**
|
||||
|
||||
## Delivered boundary
|
||||
|
||||
Thinkloom 0.5.7 adds a deterministic native contribution-map generator over the 0.5.6 composition ledger. Finalizing a release freezes the exact replayed manuscript as an immutable Markdown deposit, binds it to the manuscript revision and pre-projection CPL chain head, and records the deposit snapshot, contribution map, assertions, evaluations, and complete projection bundle as canonical CPL records.
|
||||
|
||||
The native `freeze_contribution_map` and `load_contribution_map` commands also expose the projection independently of the later HARP interface. Repeating a request against the same revision and configuration reuses the existing frozen map instead of creating a time-dependent duplicate.
|
||||
|
||||
## Deterministic coverage
|
||||
|
||||
The generator sorts source spans with bytewise ordering, validates complete source coverage, and normalizes equivalent adjacent source splits before projection. It then splits expression at structural and fixed-layout boundaries while retaining the composition ancestry ID, lineage references, and operation references. Projected ranges are ordered, non-overlapping, and cover every Unicode scalar position in the frozen deposit exactly once.
|
||||
|
||||
Map identity excludes only `contribution_map_sha256`. IDs, configuration, layout profile, segment boundaries, assertions, and map digest are derived from canonical inputs; generation time, locale, database index order, and presentation sorting do not affect the map bytes.
|
||||
|
||||
## Structural locators
|
||||
|
||||
Chapter and paragraph locators are derived from the frozen Markdown structure. Page locators use the recorded layout profile's fixed Unicode-scalar capacity, defaulting to 1,800 positions. Locators are derived metadata: the authoritative anchors remain the deposit digest, manuscript revision, scalar range, and stable segment ancestry.
|
||||
|
||||
## Independent evidence dimensions
|
||||
|
||||
Recorded origin and transformation remain properties of expression lineage. `included_in_deposit`, `selected_by_human`, and `arranged_by_human` are separate assertions; selection and arrangement assertions are emitted only when their explicit request declarations are true. Every emitted assertion has a point-in-time evaluation bound to a chain head and dependency results.
|
||||
|
||||
The map never converts provenance coverage into an originality or human-authorship percentage. Its denominator is explicitly defined as all normalized Unicode scalar positions in the exact frozen deposit. `recorded_positions` counts positions with a recorded origin other than `unattested`.
|
||||
|
||||
## Visible boundaries
|
||||
|
||||
The native projection exposes range-addressed boundaries for:
|
||||
|
||||
- `unattested` expression with no recorded origin;
|
||||
- `degraded` lineage or missing frozen-deposit evidence;
|
||||
- `unverified` CPL or provenance evidence; and
|
||||
- `stale` deposit or manuscript-revision dependencies.
|
||||
|
||||
Loading a frozen map re-evaluates its immutable assertions against current canonical state. A later composition revision makes the map stale without rewriting the frozen map record.
|
||||
|
||||
## Acceptance evidence
|
||||
|
||||
The Rust suite verifies byte-identical maps for reordered canonical inputs, normalization of equivalent source splits, structural and page splitting with stable ancestry, explicit unattested coverage, exact-map reuse, missing-deposit degradation, inconclusive-verification boundaries, and deterministic staleness after a later manuscript revision. Static integration tests verify native commands, release freezing, canonical record types, coverage invariants, locator layers, independent assertions, and all boundary states.
|
||||
|
||||
Milestone 7 does not generate HARP or make copyrightability conclusions. Deterministic HARP generation remains assigned to Milestone 8.
|
||||
@@ -0,0 +1,58 @@
|
||||
# Stage 8 — Deterministic HARP generation
|
||||
|
||||
Status: **Complete for Thinkloom 0.5.8**
|
||||
|
||||
Milestone/version rule: **Milestone 8 → 0.5.8**
|
||||
|
||||
## Delivered boundary
|
||||
|
||||
Thinkloom 0.5.8 adds a deterministic native Human Authorship Record of Provenance generator over the exact frozen deposit and contribution map delivered in 0.5.7. The `generate_harp` command requires explicit approval of the identity declaration, suggested registration language, and sanitization profile. It records that approval before generation, then records the HARP, export manifest, and complete generation bundle as immutable CPL records. `load_harp` reconstructs the latest record and reevaluates its applicability against current canonical state.
|
||||
|
||||
The generator is evidence projection code. It does not call an LLM, classify legal authorship, infer originality, compute a human percentage, or decide copyrightability or registration scope.
|
||||
|
||||
## Generated report set
|
||||
|
||||
Each generation creates a deterministic `reports/harp/{harp_id}/` tree containing:
|
||||
|
||||
- a one-page human-authorship summary;
|
||||
- a visual SVG final-text contribution map;
|
||||
- representative transformation comparisons;
|
||||
- an AI-system and model disclosure;
|
||||
- provenance coverage and limitations;
|
||||
- suggested **Author Created**, **Material Excluded**, **New Material Included**, and **Note to CO** language;
|
||||
- canonical machine-readable `harp.json`;
|
||||
- a verification report;
|
||||
- the canonical contribution map used by the reports;
|
||||
- a supporting archive manifest; and
|
||||
- a schema-valid HARP export manifest.
|
||||
|
||||
Every generated report carries the exact deposit digest, manuscript revision and digest, CPL chain head and sequence, HARP/schema/application versions, policy-profile ID/version/digest/retrieval date, sanitization profile, and a statement that copyrightability remains a U.S. Copyright Office determination.
|
||||
|
||||
## Determinism and disclosure
|
||||
|
||||
HARP identity is derived from canonical immutable dependencies: the deposit, manuscript revision, contribution map, source CPL binding, bundled read-only policy profile, assertion set, declared dependency set, and approved request. Repeating an identical request replays the same approval action and returns the existing byte-identical HARP without adding ledger events.
|
||||
|
||||
Accepted-AI-output segments are joined to recorded invocation requests to disclose provider and model identity. Missing identity is represented as `unknown` and prevents `exact` evidentiary status. Representative transformations are selected by stable operation ID; the `sanitized` profile omits source excerpts while retaining hashes and structural facts.
|
||||
|
||||
Coverage always uses normalized Unicode scalar positions. It describes provenance coverage and is never presented as an authorship percentage.
|
||||
|
||||
## Staleness
|
||||
|
||||
Loading HARP reevaluates its dependencies without rewriting the historical record. The result becomes visibly stale when any of the following changes or becomes unavailable:
|
||||
|
||||
- active manuscript revision;
|
||||
- frozen deposit bytes or digest;
|
||||
- contribution-map digest or classification;
|
||||
- registration policy-profile digest;
|
||||
- immutable assertion set;
|
||||
- assertion or lineage dependency set;
|
||||
- approved HARP request; or
|
||||
- native CPL verification state.
|
||||
|
||||
The historical exact-deposit HARP remains inspectable while its current-work applicability changes to `stale` with deterministic reason codes.
|
||||
|
||||
## Acceptance evidence
|
||||
|
||||
The native Rust suite generates the complete artifact tree from a verified CPL project, verifies exact status, checks idempotent regeneration and stable event count, then edits the manuscript and verifies deterministic staleness. Additional tests mutate each dependency class, validate the bundled policy digest and application compatibility, prohibit model/network/classifier dependencies, verify every report and shared metadata field, and validate every generated Stage 2 schema fixture.
|
||||
|
||||
Milestone 8 supplies the native generator and artifact contract. The guided approval/preview user interface remains assigned to Milestone 9.
|
||||
@@ -0,0 +1,39 @@
|
||||
# Stage 9 — HARP and CPL user interfaces
|
||||
|
||||
Status: **Complete for Thinkloom 0.5.9**
|
||||
|
||||
Milestone/version rule: **Milestone 9 → 0.5.9**
|
||||
|
||||
## Delivered boundary
|
||||
|
||||
Thinkloom 0.5.9 replaces the simplified provenance preview with two connected native-data views. The CPL explorer displays native verification status, the composition timeline and immutable records, final-text expression lineage, assertions and current evaluations, and exact, degraded, stale, or unverified evidence boundaries. When a HARP exists, its statement trace connects each evidentiary or derived statement to the relevant CPL segments, assertions, evaluations, and records. User declarations identify their approval records and explicitly show that assertions and evaluations are not applicable.
|
||||
|
||||
The HARP preparation wizard requires the user to review or create an exact frozen deposit, confirm an identity declaration, inspect AI-system disclosures and contribution classifications, resolve stale evidence or explicitly accept other non-exact boundaries, preview and edit suggested application language, choose a sanitized or full-private supporting archive, and explicitly approve generation. The approval gate resets when approval-relevant inputs change.
|
||||
|
||||
## Evidence-language boundary
|
||||
|
||||
The interface visibly separates:
|
||||
|
||||
- evidence facts read from CPL records;
|
||||
- user declarations recorded at approval;
|
||||
- deterministic derived classifications;
|
||||
- editable suggested application language; and
|
||||
- legal determinations Thinkloom does not make.
|
||||
|
||||
Verification status comes from the native CPL verifier. The frontend does not manufacture a `valid` declaration, derive authorship percentages, or decide authorship, originality, copyrightability, ownership, or registrability.
|
||||
|
||||
## Native projections
|
||||
|
||||
- `load_cpl_explorer` verifies the project and returns a read-only event, record, composition, contribution-map, HARP, and statement-trace projection.
|
||||
- `prepare_harp` returns the current frozen map, recorded AI-system disclosures, immutable policy profile, existing HARP, suggested language, and legal-scope statement without generating an artifact.
|
||||
- `freeze_contribution_map` and `generate_harp` remain the only mutation commands used by the wizard.
|
||||
|
||||
The explorer projection exposes structural identifiers and digests required for tracing; it does not expose protected record bodies as a shortcut for frontend classification.
|
||||
|
||||
## Acceptance evidence
|
||||
|
||||
- Static UI tests cover both views, native command wiring, the evidence categories, the seven preparation steps, explicit approval, and the no-percentage/no-frontend-validity boundary.
|
||||
- A native integration test creates a CPL project, freezes an exact deposit, generates a HARP, verifies the chain, and proves the HARP claim summary reaches non-empty segment, assertion, evaluation, and underlying-record sets.
|
||||
- Identity remains visibly classified as a user declaration: it links to approval records while assertion and evaluation links are explicitly not applicable.
|
||||
|
||||
Unmarked preview projects retain the preservation-only behavior established in 0.5.4 and cannot be represented as CPL-conforming evidence.
|
||||
@@ -52,7 +52,7 @@ The same `client_action_id` with a materially different canonical command digest
|
||||
|
||||
## 2. Startup recovery
|
||||
|
||||
Recovery begins before an editable project becomes active. It obtains the project writer lock and classifies the project:
|
||||
For a project already classified as CPL-conforming under §11, recovery begins before it becomes editable. Recovery obtains the project writer lock and classifies the project:
|
||||
|
||||
```text
|
||||
CLEAN
|
||||
@@ -252,3 +252,59 @@ Content already discarded under minimal retention cannot be recreated. Content a
|
||||
Emergency purge is not ordinary recovery. It requires a separate confirmed state machine that freezes the source, identifies every affected record/reference/index/Git object/export, creates a purge manifest, rewrites retained evidence and Git history, establishes a new chain root, verifies the result, and records the superseded root when safe.
|
||||
|
||||
The UI MUST disclose that earlier copies, backups, releases, and exports cannot be revoked.
|
||||
|
||||
## 11. Project-format and CPL-conformance classification
|
||||
|
||||
Project classification MUST complete without modifying the selected directory and before startup recovery, verification, or any other provenance command.
|
||||
|
||||
```mermaid
|
||||
stateDiagram-v2
|
||||
[*] --> INSPECTING: read marker and minimum structure only
|
||||
INSPECTING --> LEGACY_PREVIEW_READ_ONLY: marker absent or v0.5.x-or-earlier preview
|
||||
INSPECTING --> UNSUPPORTED_READ_ONLY: CPL marker present but unsupported
|
||||
INSPECTING --> CPL_RECOVERY_REQUIRED: exact supported CPL marker
|
||||
CPL_RECOVERY_REQUIRED --> CPL_EDITABLE: recovery and required verification pass
|
||||
CPL_RECOVERY_REQUIRED --> CPL_BLOCKED: incomplete, failed, unsafe, or incompatible
|
||||
LEGACY_PREVIEW_READ_ONLY --> PRESERVATION_ARCHIVE: explicit user request
|
||||
PRESERVATION_ARCHIVE --> LEGACY_PREVIEW_READ_ONLY: byte-preserving archive complete
|
||||
```
|
||||
|
||||
`LEGACY_PREVIEW_READ_ONLY` permits only explanation, Show Project Folder, and a byte-preserving preservation archive. It MUST NOT invoke CPL recovery, synthesize records, generate HARP, or write a marker. A `schemaVersion: 1.0` field is not a CPL marker. Only the exact supported marker in Specification §23 can enter `CPL_RECOVERY_REQUIRED`, and the marker alone never establishes conformance.
|
||||
|
||||
## 12. Deposit and HARP lifecycle
|
||||
|
||||
HARP applicability, HARP integrity verification, CPL verification, evidence-boundary status, policy-profile currency, and user approval are independent state dimensions.
|
||||
|
||||
```mermaid
|
||||
stateDiagram-v2
|
||||
[*] --> WORKING
|
||||
WORKING --> DEPOSIT_FROZEN: select exact file; bind digest and manuscript revision
|
||||
DEPOSIT_FROZEN --> EVIDENCE_PROJECTED: deterministic contribution map
|
||||
EVIDENCE_PROJECTED --> USER_REVIEW: show facts, declarations, boundaries, and suggestions
|
||||
USER_REVIEW --> LANGUAGE_APPROVED: user edits or accepts exact suggested strings
|
||||
LANGUAGE_APPROVED --> GENERATED: generate immutable HARP and manifest
|
||||
GENERATED --> CURRENT: native integrity verification succeeds
|
||||
DEPOSIT_FROZEN --> STALE: manuscript edit or restore
|
||||
EVIDENCE_PROJECTED --> STALE: manuscript edit, restore, or dependency change
|
||||
USER_REVIEW --> STALE: manuscript edit, restore, or dependency change
|
||||
LANGUAGE_APPROVED --> STALE: manuscript edit, restore, or dependency change
|
||||
GENERATED --> STALE: current work or bound dependency changes
|
||||
CURRENT --> STALE: current work or bound dependency changes
|
||||
STALE --> DEPOSIT_FROZEN: select and freeze a new exact deposit
|
||||
```
|
||||
|
||||
### 12.1 Deposit freeze
|
||||
|
||||
Under the writer lock, Thinkloom MUST validate that the project is CPL-conforming, finish meaningful edit transactions, select the exact deposit file, compute its digest and byte length, and bind the manuscript revision, CPL chain head and sequence, and layout profile. It then records the immutable deposit snapshot and CPL event. Page, chapter, paragraph, and line locators are derived; stable expression-segment IDs, revision IDs, and digests remain authoritative.
|
||||
|
||||
### 12.2 Projection and review
|
||||
|
||||
Projection and report rendering occur outside the writer lock from frozen canonical inputs. Before generation, the user MUST be shown unattested, unknown, degraded, stale, and unverified boundaries; self-declared identity status; recorded AI-system disclosures; the policy-profile version; and editable suggested registration language. Selection/arrangement overlays MUST remain separate from recorded origin.
|
||||
|
||||
The transition to `LANGUAGE_APPROVED` requires an explicit user action that binds the exact `Author Created`, `Material Excluded`, `New Material Included`, and optional `Note to CO` strings. Merely opening, previewing, or exporting a draft does not approve them.
|
||||
|
||||
### 12.3 Generation, verification, and staleness
|
||||
|
||||
Under the writer lock, Thinkloom revalidates every frozen dependency and the approval digest before recording the immutable HARP, manifest, and generation event. Native verification then checks the HARP artifact bindings and source CPL scope. Success produces `CURRENT` and the label **HARP integrity verified**, never **authorship verified**.
|
||||
|
||||
Any later manuscript edit or restoration makes the HARP stale for the current work, even when the exact historical deposit and HARP remain byte-valid. A changed deposit, assertion, evaluation dependency, sanitization profile, or other bound input also makes the affected HARP stale. Publishing a new policy profile does not rewrite an existing HARP; its separately reported policy status becomes `superseded`. Regeneration always starts from a new immutable deposit snapshot and never mutates the prior HARP.
|
||||
|
||||
Reference in New Issue
Block a user