Records and archives¶
Records gives an organization a controlled place to receive correspondence, assign an official reference, establish responsibility and preserve the resulting record. It connects the original submission to later processing and filing. Receiving a file, registering it, completing its work and filing it are separate events.
Availability: this is a source-backed draft. The backend implements intake and registration, while the inspected frontend still uses sample data and preview actions. The guide follows the newer final designs. Public status tracking has unresolved connection and retry limitations, and no target environment or reader walkthrough has been accepted. Confirm availability with your organization before relying on these journeys.
Read the intake and registration guide for public submission, registry capture, registration, destination changes and finding records. The document and process guide explains saved versions, supporting files, current and earlier processes, filing outcomes and recovery. The record activity guide explains ordered updates, available detail, linked-process previews and delayed or missing evidence. Completed record work explains retrieval, review, compliance and stewardship evidence, attribution and corrections; its app journey remains unestablished. Records evidence and organization data explains reporting recovery and the Records export/deletion boundary. The dossier guide explains finding, creating and linking general dossiers, primary relationships and recovery. The pre-system file guide explains bringing previous records in with file details or ZIP packages, deterministic folder grouping, submission outcomes, whole-submission retry and cancellation. The ZIP delivery constraint remains explicit. Automatically prepared dossiers explains personnel synchronization, empty staff files, case-type grouping, pending links and support recovery. Classification, retention and final disposition explains filing rules, current-policy eligibility, queue limits and final archive/close outcomes, with governance action delivery still unverified. How work becomes an official record explains source-specific promotion results, delayed acknowledgements and the disabled general automatic-dossier policy. Records information in HiveAI explains source eligibility, currentness, basic status, incomplete scan meaning and recovery. Assistant summaries explains richer read results, limited searches, document metadata and narrow signing readiness. Assistant changes explains supported proposals, exact outcomes, approval limits and recovery after an uncertain result. Protected assistant handoffs explains document-screen preparation, creation receipts, completion limits and failed-return recovery. Complete promotion/assistant screen journeys, source proof production and remaining supporting-source explanations remain in progress.
Who uses Records¶
| Reader | Responsibility |
|---|---|
| External submitter | Send correspondence through the organization's public intake, keep its receipt and follow up with the registry. A receipt does not grant access to internal records. |
| Registry staff | Capture received correspondence, check its contents, register eligible records and choose a responsible office, recipient role and starting destination. |
| Process owner or manager | Follow the work associated with a record and investigate delayed handoffs or missing responsibility. Registration alone does not mean processing has started. |
| Organization administrator | Maintain current offices, positions, shared queues, access and classification configuration needed by the registry. |
| Business leader | Agree what enters official custody, who is accountable and what evidence demonstrates completion. A list count is not a measure of service quality or compliance. |
Internal viewing and changes require the corresponding access in the correct organization. Viewing a record does not grant permission to register it or change its destination. Personnel records have a separate protected access path and are excluded from the general register, intake queue and general record detail.
Three references with different purposes¶
A public submission reference identifies the item received through online intake. The private status key lets the intended public tracking journey locate that submission until the key expires. The official reference is issued later during registration. Keep the submission reference for correspondence with registry staff and protect the status key from disclosure.
An internal identifier exists before registration, so an unregistered item can already be stored and reviewed. Do not interpret a sample number in a design, or the appearance of a receipt, as proof that an official number has been issued.
From arrival to accountable work¶
Online intake begins as a received, unregistered submission. Registry capture begins under registry review. Both require a main document and a description; up to nine supporting files can accompany the main document. Intake does not assign a named staff member or select the eventual destination.
Registration checks that the record is still eligible, resolves the organization's classification and numbering configuration, verifies the receiving office and recipient role, and resolves an office, role or shared queue as the starting destination. The recipient role and starting destination must belong to the receiving office. The system issues the official number and preserves the selected responsibility information.
Incoming correspondence registration also requests the configured processing workflow. That request and an actually started process are different outcomes. A record can remain registered while the handoff is pending or has failed. The process reference and current status are the evidence to inspect before saying work is underway.
Changing destination is available only while a record is registered and has not moved into processing. It requires a reason and a destination different from the original registration destination. The responsible office and role change with the new destination, while the original receiving office and recipient role remain recorded. This action does not move a document into a different dossier, set retention or reassign a running workflow task.
Filing records the classification placement. Registration checks the configuration needed for that later step but does not itself save a filing placement or start a retention countdown. An item in Awaiting filing may still be in progress; its presence in that list is not confirmation that processing is complete or that a manual filing action is available.
Choose the right list¶
| View | What it means |
|---|---|
| Intake queue | Received, under-review and registered items that have not advanced beyond registration. It includes both public and registry-originated intake. |
| Registry review | Items under registry review, plus registered, unfiled items without a current process. |
| All records | General records across their lifecycle. Personnel records remain outside this view. |
| In progress | Records whose current stage is processing. |
| Awaiting filing | Unfiled records that are registered or in processing. |
These views overlap. Adding their totals double-counts some records. Counts for the visible page and totals across the whole result also have different meanings. Current list results are organization-scoped; they are not an organization-wide performance assessment, nor evidence that a particular person has completed a task.
What to establish before adoption¶
Choose the registry's accountable team, agree the public intake address, maintain usable organization structure, and verify the registration-to-process handoff with representative correspondence. Test a failed upload, missing destination, uncertain save and failed status lookup as well as a successful submission.
Public file limits are configurable. The inspected defaults allow PDF, JPG/JPEG, PNG, DOC and DOCX files up to 25 MiB each; the final designs label this as 25 MB. Follow the active intake page's allowed formats and size limit. The ten-file maximum comprises one main document and up to nine supporting documents. Organization storage and shared upload rules can impose further constraints.
This documentation does not establish a price, a response-time promise or a certification. The organization must confirm its access, operational readiness and applicable handling policies. If the result is uncertain, keep the reference and ask the registry to reconcile the existing submission before creating another one.