How it flows

A document enters.
A cited result comes back.

The source system stays authoritative. OmniTome records what one operator can read, lets another operator derive and seal knowledge from the raw archive, and lets several teams query combinations of the resulting files.

Follow the stages Evidence and limits
source documents .omniblob .omnitome MCP clients

Human roles

The stages do not need the same person or machine.

File hand-offs separate source credentials, model compute, authorization policy, and consumption without losing provenance.

At the source

Authors and source owners

Write repository files, wiki pages, work items, boards, and shared documents. Their source system remains the authority for revision and access.

Near the source

Scrape operator

Uses a scoped credential to collect one tracker, repository group, file share, or local tree into a raw archive.

At the build machine

Knowledge builder

Receives raw data, runs extraction, applies the grant policy, compiles sealed files, and adds the embedding space used by readers.

At consumption

Reader teams

Possess one or several compiled files and query their combination from an MCP client. Each team only receives what its files contain.

Documents through the pipeline

Each arrow is a file or a query contract.

No pipeline database or daemon connects the build stages. Each artifact carries enough identity and provenance for the next machine to verify what it received.

  1. Sourcesauthoritative systems

    Individual facts begin in real documents.

    Repository files, wiki pages, issue threads, boards, file-share documents, and local files each have a native identity and revision. Software sources can include web and desktop UI, application code, RPC schemas, SQL definitions, and infrastructure.

    Human
    Authors and source owners
    Trust
    The source checks the scrape credential
  2. Scrapeomnitome scrape

    Observation creates provenance.

    The connector records locator, revision, scope, and content hash. The terminal meter shows source position, container fractions, bytes, and the proportional whole-source bar.

    Human
    One operator with source access
    Output
    Raw .omniblob
  3. Extractomnitome extract

    Extraction proposes knowledge.

    The model proposes typed atoms, entities, and relationships. A claim without cited support is rejected and counted; accepted rows retain every input scope.

    Before extraction, source readers preserve declarations and exact spans. Built-in readers cover frontend components, desktop markup, interfaces, data definitions, and deployment syntax; an optional language pack adds sixteen grammar families. The build record identifies partial analysis and fallback. Read the source coverage boundaries.

    Human
    Knowledge builder with model compute
    Output
    Enriched .omniblob
  4. Compileomnitome compile

    The grant becomes the file boundary.

    Pure code includes only entitled documents and knowledge. A derived atom enters only when every required input is entitled; ambiguity excludes rather than guesses.

    Human
    Knowledge builder applying the approved policy
    Output
    Sealed .omnitome
  5. Embedomnitome embed

    A named search space joins the sealed text.

    The embedding model adds vectors identified by provider, artifact, version, dimensions, normalization, and digest. A mismatched query embedder is unusable rather than approximate.

    Human
    Knowledge builder or deployment operator
    Output
    The same sealed file with one more derived space
  6. Serveomnitome-mcp local

    Reader teams query one or several files.

    The server opens the files over stdio. Lexical and exact semantic branches fuse deterministically; each result carries its source identity and citations.

    The CLI or desktop can also generate answers with a chosen model. Optional checks assess source support and question coverage before accepting a draft; model judgments still need review.

    Human
    Several teams, each with its permitted file set
    Output
    MCP results for a client to read or narrate

Returning operator path

End-to-end incremental updating.

The update path preserves the same evidence and authorization rules while avoiding work for unchanged content.

  1. 1Scrape

    Use revision- and date-aware enumeration over the complete selected scope and deliver a delta containing only moved documents. GET retries are bounded; admitted documents survive interruption in a valid incomplete archive and journal.

  2. 2Extract

    Read only the delta. Each finished document is journalled, so a mid-run resume does not ask the model for completed work again.

  3. 3Update

    compile --update checks the epoch chain, swaps changed documents, applies honest tombstones, and computes retired atoms against the Knowledge Base.

  4. 4Embed

    Schedule only missing object and content-hash pairs. Existing vectors for unchanged content remain in place.

Compatible checkpoints, extraction journals, and embedding identities allow unchanged work to be reused. A gap in the epoch chain refuses with the scope to resync; an incomplete enumeration never turns absence into deletion.

Consumption

Possession selects the local corpus.

A reader team may receive one domain file, while another receives several and serves them as one corpus. The server merges deterministic identities and never reconstructs content that was excluded at compile time.

Read the local serving contract
Team Aplatform.omnitome
Team Bproduct.omnitome
Team Cplatform.omnitome + product.omnitome

Each MCP session can answer only from the files that session opens.