Import documents

PDF and Markdown documents, such as official decrees, regulations, or existing notes, are split into reviewable knowledge sections. Only what a person accepts in review enters the memory.

One import, two outcomes

Use «Import» in a room’s library for every file. The file decides what it becomes: a Markdown file with a decision header (a YAML frontmatter block whose type or key is ADR, BDR, SDR, or DREAM) becomes a draft decision, and every other file (PDF, or Markdown without a decision header) becomes knowledge in the room’s memory. Before anything is written, the dialog shows the split, and you can switch a Markdown file to the other kind.

A decision draft binds only after it is accepted, and any room member can import decisions. Knowledge is split into parts that you accept or reject in review, and accepted parts are advisory, not rules. Only the room owner or a decider can import knowledge; the dialog names the files you cannot import before you start.

In neither case is the import itself an approval. The «Import documents» item on a memory page imports knowledge straight into that memory. Plain text and OKF files (.txt, .okf) use the reviewed knowledge import, linked in the next section.

Import jobs

Review and apply knowledge in the selected room, with controlled undo when needed.

UTF-8 Markdown, text or OKF documents (.md, .txt, .okf). Up to 10 files and 2 MiB total. No PDF, ZIP or JSON.

Uploads are stored in the room-protected job. Content checks run before transfer into knowledge; a failed check prevents transfer.

Only type: document is supported. Rules, exemptions, decisions, relations and authority fields are rejected. status is unverified source information only. No model call extracts content.

Select entries and save the selection before applying. Content is read-only here: correct the source file and upload again if needed.

Import does not approve a rule or exception. It creates documents; effective governance remains unchanged.

Reviewed knowledge import

What the import does

The import reads the text layer of uploaded PDF files, scans it for secrets and hints of personal data, and extracts the key metadata per document: title, reference, version, valid-from, and important people and roles (for example, issuing authority, responsible persons, approvers), so that they can be maintained. Long documents are split into a few large parts along the main chapters; short ones stay a single part. Markdown files (.md) are split without a model call: parts follow the headings, and metadata follows the frontmatter; tags and links are kept as metadata on each part. Typed frontmatter keys (depends_on, supersedes, conflicts_with, refines, is_a, relates_to) are carried over as proposed edges on decision import and on derivation; unknown keys are left untouched.

Every run leaves evidence: which files were processed, what was blocked, and who accepted or discarded what.

Connected agents can submit knowledge through propose_knowledge. Their drafts appear in the import review with their origin marked; only humans can accept them.

How an import runs

1. Start under «Memory»: open the memory of your own room and choose «Import documents» in the «More actions» menu (selectable profile). While the «Documents & regulations» list of that memory is still empty, it offers the same «Import documents» button. Only the room owner and the room’s deciding roles (governance owner, platform admin) see the action.
2. Choose files (PDF or Markdown, up to 25 of 20 MB each) and pick the target, memory or expertise; platform admins can create a new expertise here.
3. Wait for processing: the progress view honestly shows per file whether it was extracted, had no text, was blocked because of a secret, or failed.
4. Review: for each document, check and adjust the metadata and people/roles in the header, then expand the collapsed parts (title and word count) as needed and accept or discard them. «Accept all» accepts a document’s open parts together with the document metadata and deliberately stays limited to that document.

Mandatory review

There is no silent import: no content enters the memory before a human accepts it. Discarding is final; the batch remains as an audit trail.

Personal-data hints (PII) do not block. They appear as warning chips on the section, and the reviewer decides.

Known limits

• Scanned PDFs: documents without a text layer are read through local text recognition (OCR) and labeled «recognised via OCR» in the review. By default, only the first 60 pages are read; the operator can also turn OCR off. Text recognition can make mistakes, so review the content of such documents with extra care.
• No duplicate detection: importing and accepting the same file twice puts the content into the memory twice.
• Limits: up to 25 files of 20 MB each per import, PDF and Markdown (.md).
• A running import does not survive a service restart. If a run hangs unusually long, start the import again. There is no overview of running imports yet, so keep the dialog open.
• Secrets block hard: a file containing detectable credentials is not processed.

Who may import

The room owner and the room’s deciding roles (governance owner, platform admin) import into the memory; platform administration imports into expertise. The backend enforces this at every step, including the review.

After acceptance: the document administration

Accepted documents don’t disappear into the memory: the “Documents & regulations” section on the page of each memory lists what was imported there, with title, version, valid-from, roles, source file, and parts. From there, you can open and maintain every document: header metadata for the whole document, title and content for each part. Every change is recorded as evidence; content changes are re-embedded so that search finds the maintained state. You can delete documents that you no longer need in the document dialog: the accepted parts are removed from the memory, while the import evidence remains as a record.

Important context: imported documents are knowledge and act as advice in answers. They don’t automatically become rules. A rule only comes into being when a part is deliberately raised as a rule, as described in the section «From a document part to a governed record».

Agent reading version and translations

When you import with the «Document (official)» profile, the platform also generates a structured «Agent reading version» (essence) for each part: obligations, prohibitions, responsibilities, scope, and exceptions. It is machine-generated and strictly limited to what the text supports; empty groups are normal. As a secondary version for agents, it never replaces the original. In the document administration, you can review it, adjust it, or generate it retroactively for existing documents. Very short parts don’t get one.

There you can also machine-translate accepted documents (French, Italian, English). Each translation is created as its own, clearly labeled entry in the same memory. The first line states, in the target language, that it is a machine translation and that the German original remains authoritative. Translating again replaces a language’s existing version; deleting the document removes its translations with it.

From a document part to a governed record

Room owners can derive an accepted part as an ADR, BDR or SDR draft in document administration, or raise it as a rule through the normal Policy editor. The same part may support several distinct decisions and rules.

The source document remains unchanged and advisory. A derived decision has no effect until a human accepts it; a rule is created only through explicit submission in the fully visible Policy editor. Both paths retain a stable source anchor, write Evidence, and return the existing record when an identical request is repeated.