micro1’s public program describes operational documentation and process records. For your inventory, separate the instructions explaining how work should happen from the records showing what actually happened. That helps you ask whether a proposed collection fits the program without treating a broad interest as acceptance of a particular system, company or archive.
The published record-interest boundary
micro1 names SOPs, knowledge bases, CRM data, project histories and QA processes. Its enterprise FAQ describes operationally mature companies with 30 or more employees and established documentation; English operations are the stated priority.
Sources: micro1
Compare a procedure library with a procedure in use
A folder of procedures can tell a reader what the company expected staff to do. A project history may show where the team used, changed or departed from those instructions. Inventory those as separate collections before deciding whether they can be described together.
Fictional example: procedure P-12 was revised in March. Project PR-80 began in February, had a review in April and closed in May. The current procedure cannot automatically explain the February work. The useful question is whether the earlier version survives and whether the project record references it.
| Collection element | Field to inspect | Question it resolves |
|---|---|---|
| Procedure | Document ID and version date | Which instruction existed then? |
| Project | Project ID and stage events | What sequence is retained? |
| QA review | Project reference and review date | Which work was assessed? |
| Decision note | Reason and related event | Why did the approach change? |
Use a small exception to test the description
Choose one project that needed rework or a second review. Locate the first version, the feedback, the revised work and the recorded acceptance. If the project folder contains only the final deliverable, do not label it a full revision history. If comments remain but the prior file does not, describe comments and final file separately.
This is an inventory exercise, not a request to reconstruct missing records. A precise gap such as review comments survive from June onward is more useful than presenting a seamless history assembled from memory.
Keep language and company details separate from contents
The company profile and the collection description answer different questions. Put employee count, operating country and working language in the company section. Put the actual record groups, dates, references and formats in the inventory.
- Name the operational process, not just the industry.
- Identify the document version used during the observed period.
- Describe whether project changes are events or current values.
- Separate recorded quality outcomes from informal recollections.
- Keep unknown history and format fields open for inspection.
Prepare one concise scope question
You might ask: our team has a procedure library and project review records for the same period, connected by project references; earlier procedure versions are still being checked. Is that collection relevant, and which examples would clarify the scope? This narrows the conversation to records the company can actually identify.
Questions about this comparison
Is a procedure folder the same as workflow history?
No. A procedure describes intended work. Workflow history describes recorded events and decisions. They can be related, but the relationship needs inspection.
What if our procedures have no version dates?
Record the current files and mark historical version availability unknown. Do not assign dates based on when the business began.
Sources
- Monetize your company's operational data (micro1)micro1 · Checked 2026-10-12