One description, everywhere it’s needed.

Most tools make you describe your material for the catalog and then describe it again for the website. Quirow treats the catalog record as canonical and reads everything else from it.

The workflow

From a box of scans to a published site.

01

Describe the material

Catalog to Describing Archives: A Content Standard, with full Part I and Part II support. Build real multilevel hierarchy — collection to series to file to item — where each level stores only what is set at that level and inherited values are computed when the record is read, so correcting a collection-level statement corrects everything beneath it.

Name access points come from live Library of Congress lookups rather than retyping, and controlled vocabularies are real tables, not free-text fields you hope stay consistent.

DACS Part I & IIMultilevel inheritanceLCSH / LCNAF / LCGFTAuthority recordsScripture references

02

Attach the files

Digital objects hang beneath the records that describe them — images, audio, video, PDFs, or pointers to material hosted elsewhere. Uploads go straight from your browser to object storage, so file size is not bounded by what a web form will tolerate, and every institution’s files live in their own bucket.

Direct-to-storage uploadPer-institution bucketsSigned, expiring access

03

Curate the pages

Compose a landing page, an about page, and narrative exhibits by dragging blocks into place. An item card points at a record you already cataloged, so the archival description shown to a visitor is the description you maintain — editorial framing lives on the page, never written back into the catalog.

Themes read from a token layer rather than from the content, so re-theming a site does not mean rebuilding its pages.

Drag-and-drop blocksLive previewDraft and publish states

04

Publish and be found

Your site goes live at your institution’s own address with your logo, navigation, and colors. Alongside the curated pages sits a faceted research view, so a scholar who wants to browse the collection at every level can do that instead of reading the exhibit you happened to build.

Per-institution siteCustom brandingFaceted research view

Under the hood

Decisions that are hard to change later.

The parts a migration would be painful to undo, settled deliberately rather than by accident.

Three layers, never mergedCatalog records, digital objects, and presentation pages are separate things with separate jobs. Collapsing them is the mistake that makes archival software impossible to evolve, and it is the one thing this system refuses to do.
Your data is yoursEvery institution’s records are isolated at the database level, not by application code remembering to filter. Files live in a bucket of your own.
Description stays canonicalPresentation never writes back into the catalog. However many pages feature a record, there is one description of it, and it is the one you maintain.
Nothing to administerNo server to patch, no PHP version to worry about, no plugin that breaks on upgrade. The reason small archives abandon self-hosted systems is the reason this one is hosted.

Not yet

What it doesn’t do.

Quirow is in active development with one pilot institution. Machine interfaces for harvesting and exchange are planned but not built. There is no automated transcription, no OCR, and no machine-generated cataloging — the description is yours, deliberately. Sign-up is not self-service; institutions are onboarded by hand.

If something on this page matters to you and is on the wrong side of that line, that is genuinely useful to know. Tell me, or read why I’m building it.