The Classify page

The Classify page

Classify (/classify) works on one document — no pair, no redline. It is the ingest-side sibling of a comparison: use it when a document enters your repository and you want it checked against your filing conventions and sealed with the same proof stack every comparison output carries.

One drop does four things, in order:

1. Extract + check — the filing-metadata mapping configured for the document's family (compare.docx.metadata / compare.xlsx.metadata) runs, and the configured assertions are evaluated. Assertions that need two documents (expect: changed / expect: unchanged) can't apply to a single file — they are skipped and the classification says so explicitly.
2. Sanitize — the deployment's compare.scrub policy applies, exactly as it does on every produced output (author names, custom properties — whatever the config declares).
3. Seal — the classification record (pleodox/metadata.json: extracted values + assertion verdicts) is embedded, then the integrity manifest as the very last write. The sealed copy verifies on the Verify page like any other produced file.
4. Prove content untouched — the document's text content is fingerprinted before and after; the two must be identical. That's a runtime proof — shown as the ✔ badge — that classification changed properties, never content.

The sealed copy downloads as Classified <original name>. Nothing is stored on the server.

The controls

• Profile — the same caller-named config bundles as on the Compare page (compare.metadata.profiles): extra extraction properties and assertions for a specific template or state. Never auto-detected — selection is yours. Leave — for the global checks only.
• Verify content untouched (on by default) — runs the before/after content fingerprint. Word: the document text (including deleted-text runs); Excel: a per-part digest of everything under xl/.

What the result panel shows

• ✔ Content untouched / ✖ Content check failed — the safety-property verdict.
• Findings — failed assertions (e.g. stateCode expected "NY", found "AK") and anything noteworthy. Findings never block the download: the classification record inside the file carries the same verdicts, so the receiving system (a DMS rule, a workflow) decides what to do with them — this tool computes and proves; your repository decides and remembers.
• Classification — the human-readable block: which properties were found (and where), which were not, the profile applied, and how many two-document assertions were skipped.

Typical uses

• Intake gate: check an incoming filing document against naming/metadata conventions before it lands in the repository, and store the sealed copy — its embedded record is tamper-evident, so the classification claims can be re-verified any time.
• Retroactive sealing: run existing repository documents through Classify to give them the same integrity + metadata record your comparison outputs already carry.
• Pipeline step: the REST endpoint makes this a one-call step in any automated ingest flow.