Project guide — Writfold

01 / Evidence

Keep the source. Keep the distinction.

A source may support a statement without making that statement universally true. Writfold's model keeps support, contrary evidence, freshness, validation, authority and publication separate.

What a record needs

Exact source identity, the revision and bytes observed, the claim it relates to, and the context in which it is assessed. A later edit at the same URL must not silently become the evidence for an earlier decision.

What it cannot establish

A citation alone does not approve a change. A successful retrieval does not demonstrate complete coverage. A database relationship is not an inference rule.

02 / Contexts

Shared knowledge. Explicit boundaries.

A named context specifies the scope and policy under which knowledge is assessed. It is not a folder that silently combines every source or permission available to an agent.

Select deliberately.

A query names the context it needs. Work and personal knowledge do not pool evidence or approval just because the same person can access both.

Pin the view.

The intended retrieval contract binds a release, context and assessment time. Later publication must not quietly change an in-progress historical read.

Show uncertainty.

Missing, expired, contradictory and incomplete evidence remain visible. An empty result is not automatically proof that nothing exists.

03 / Scribes · planned

Acquisition without authority.

Scribes are the planned integration boundary for small source-reading programs. Their job is to acquire evidence, not to sign approvals, mutate the knowledge store or choose an authorization context.

SourceRepository or document
ScribeBounded acquisition
WritImmutable evidence record
ProposalSeparate review & approval

The scribe runtime, plugin SDK and catalog workflow are not released. There are no installation instructions for them yet.

04 / Architecture direction

Local state. One approval boundary.

The active target is Linux x86_64 and WSL2. Writfold is a local tool in development, not a hosted knowledge service.

Semantic core

Rust domain & decisions

Checked identities and typed records separate parsing from semantic decisions. CLI, agent requests and future reading views are intended to consume the same prepared application results.

Selected backend · not integrated

Omnigraph companion

Revision 4 selects a supervised Omnigraph process as the primary structured backend. It must first pass a source-pinned foundation campaign. Dolt stays isolated for the historical reference and legacy import, not as a second normal writer.

Publication contract

Retained evidence & Git

Authored records, signed approvals and retained evidence remain distinct from graph storage. A native graph commit does not itself approve or publish a Writfold release.

Reading channels · planned

Markdown & Obsidian

Generated reading views will present a pinned, authorized context. They are not an alternative authority: editing a note must not silently approve a claim.

Physical schema changes require a separate immutable graph epoch, with old reads retained under their original schema and query contract. Migration, recovery and independent restore still need qualification; the selected design is not a durability claim.

05 / Status & assurance

A foundation, with its limits visible.

The Rust workspace contains checked domain identities, bounded wire codecs, canonical signed operations, protocol admission, native filesystem primitives and byte-preserving source syntax. Its development reference host is not a production CLI.

Still open

Complete semantic and operational proofs, Omnigraph integration, publication and recovery, migration and restore, scribes, reading views, production CLI and installed-release qualification.

Different evidence, different claims

A model proof, verification of selected executable functions, differential comparison and a native runtime exercise answer different questions. None alone establishes that the complete product is ready.