Skip to content

Latest commit

 

History

History
191 lines (152 loc) · 17.7 KB

File metadata and controls

191 lines (152 loc) · 17.7 KB

Proofpress FAQ

Is this just Git blame or Git for docs?

No. Git remains the source of history for code and repositories. Proofpress is for Markdown and static HTML knowledge artifacts: it records accepted changes, stated reasons, consequential rejections, and their relationship to the artifact.

On GitHub, the file and its portable capsule travel through ordinary commits and pull requests. Outside Git, the raw file can carry the same public history. Proofpress does not replace Git.

Is Proofpress C2PA for knowledge work?

That is a useful architectural analogy, not a compatibility claim. The C2PA Content Credentials specification defines a standardized, cryptographically verifiable model for asset provenance using assertions, content bindings, claims, and signatures. Proofpress applies the "provenance travels with the artifact" idea to admitted decision lineage in knowledge artifacts. V1 does not claim C2PA interoperability, cryptographic signing, authenticated authorship, or complete capture.

What is actually verifiable?

The engine computes changes from the artifact and deterministically checks whether recorded change claims match that diff. It also checks capsule integrity, event relationships, and drift from the recorded head.

Reasons, rejected directions, and actor identities are attributed context unless backed by stronger evidence. Their presence in the ledger does not make them independently proven facts.

What is the trust model?

Proofpress makes captured history inspectable and checkable. It does not make every statement true, prove every identity, or guarantee that every relevant conversation was captured.

Actor roles include an attribution basis such as environment-attested, harness-attested, self-asserted, or unknown. Missing or unattributable history should remain visible instead of being guessed.

What if somebody tampers with the capsule or replaces the file?

The capsule's internal integrity checks detect accidental body drift and inconsistent rewrites of its recorded events. Proofpress V1 does not provide cryptographic signing or an external trusted checkpoint.

A future signature layer could authenticate that a trusted key signed a particular capsule and make third-party alteration or forgery detectable. The strength of the identity claim would still depend on how that key is bound to a person or system.

Signing alone does not tell a verifier that a file holder replaced the entire file and capsule with another self-consistent history. Detecting complete replacement, rollback, or omission requires comparison with an external trusted head, witness, or checkpoint.

Can parallel copies be merged without Git?

Yes. merge-plan finds a common ancestor for portable copies of the same artifact and reports compatible changes and genuine block conflicts. After a person or agent resolves the visible document, merge preserves the supplied public histories and records a multi-parent event.

Different documents are not parents. They remain ingredients and are referenced with merge-lineage.

What happens if the local ledger ref is unavailable?

A valid portable file still works. Its capsule can be inspected, imported, and verified without refs/proofpress/ledger.

The ref is the complete local working record and repository index. Losing it can lose local-only history and local lookup, but it does not invalidate the public history embedded in a portable file.

Why not use MEMORY.md, a local vault, or a shared memory service?

Those are good solutions for workspace continuity. They retain broad context, support retrieval and injection, and help later sessions continue the work. The handoff boundary is different: a recipient may receive the artifact without the original vault, permissions, identifiers, or retrieval stack.

The two layers complement each other. A vault can hold private working context, unfinished exploration, and material relevant across many artifacts. Proofpress carries the smaller record admitted into one shared artifact: accepted transitions, reasons, consequential rejections, and attribution. Memory helps the next agent continue the workspace; provenance helps the next recipient understand the artifact.

Why not export selected vault context with the file?

That is a valid design. Once the exported context is bound to a particular artifact and revision and travels with it, it is functioning as an artifact provenance record. Proofpress provides a portable structure and deterministic checks for that deliberately admitted subset; it does not claim to be the only way to package it.

How does Proofpress complement OpenWiki, DeepWiki, and Open Knowledge Format?

//: # (ob:95be06b6)

Layer Primary job How Proofpress complements it
OpenWiki Generate and maintain an agent-readable wiki from repositories and connected sources; it can emit Open Knowledge Format bundles. Record which generated or edited artifact revision was admitted, why, and by whom.
DeepWiki Index and explain a repository through navigable documentation and question answering. If an explanation is exported or committed as an artifact, give that artifact a portable admission trail. Proofpress does not attest DeepWiki's internal state.
Open Knowledge Format Represent linked knowledge in a vendor-neutral Markdown and YAML bundle. Add accepted revision lineage and claim-versus-diff verification to selected artifacts in the bundle.
Proofpress Preserve and check admitted artifact transitions. It does not generate a wiki, retrieve context, provide a knowledge graph, or establish that the content is semantically correct.

They can form one stack rather than competing alternatives: a generator such as OpenWiki produces documentation, Open Knowledge Format organizes the knowledge bundle, a wiki surface helps people and agents explore it, and Proofpress records the acceptance boundary for the files that are actually shared. Not every transient generated view needs a snapshot.

Can Proofpress manage an Open Knowledge Format bundle?

At present, Proofpress works at the artifact level. An Open Knowledge Format concept is a Markdown file with YAML frontmatter; Proofpress preserves frontmatter at byte zero and can attach a portable capsule to each selected file. Proofpress does not currently validate the bundle schema, graph or link consistency, or atomic admission of a whole bundle. Use an OKF-aware validator for the format and Proofpress for artifact provenance.

Does a DOCX sidecar provide the same revision history as Markdown or HTML?

No. Markdown and static HTML can carry a native portable revision ledger. For DOCX, Proofpress currently verifies semantic evidence in a separate provenance sidecar. That evidence can travel with the document and detect canonical-content drift, but it should not be described as an embedded revision history.

Why not ask an LLM to explain the diff?

An LLM can provide a useful reading of two snapshots. Proofpress adds stable artifact identity, version lineage, portable handoff, explicit separation between attributed context and computed facts, and deterministic checks that recorded claims match artifact changes.

Does the portable capsule leak private prompts or chat history?

Proofpress is not a conversation recorder. A capsule contains only history admitted into the public portable lineage; merging copies combines only the public records already present in those input capsules.

Anyone holding the raw portable artifact may inspect its capsule. Keep private history local, or create a clean copy before sharing.