Guides
Digitizing home paperwork: check every page and OCR suggestion before filing
Build a readable home document packet: check page order, ambiguous text, dates, and filing context before saving assisted capture results in PropertyOS.
Eternity Labs ·To turn a paper home file into a useful digital record, I would first check that every needed page is readable, then compare any extracted information with the document before saving it. OCR can help with transcription. A clear scan and a plausible suggestion still need my attention: the information must belong to the right page, event, and home record.
PropertyOS describes document capture with on-device assistance and asks the user to review every suggestion before saving. That makes the review step part of the workflow, rather than an inconvenience to skip. The app can organize documents alongside properties, rooms, equipment, contractors, and interventions. Those capabilities are described on the official PropertyOS page.
Here is a fictional example, told in the first person: I am organizing a small packet left after work in my home. The packet and its details are invented to explain a method. This is not a report of a scan I performed in the app, and no recognition result or time saving is being claimed.
The packet on my table is not yet a complete record
In this example, I have three sheets concerning one visit: a cover sheet, a description of the work, and a page of additional notes. The second sheet has writing on its reverse. There is also a sticky note I added later, which must not become part of the contractor's original document by accident.
Before reaching for the camera, I separate the original pages from my own annotation. I count the faces that contain relevant information and check whether the printed page numbers agree with what I have. Three sheets do not necessarily mean three pages of content.
I would record a missing page as missing. I would not renumber the pages to make the packet appear complete, or reconstruct a sentence because I expect to know how it ends. A readable incomplete document is still incomplete.
This is also the moment to define the purpose of the record. I want to find what was done and connect the paperwork to the relevant intervention. I am not trying to prove that every statement in the document is correct. Capturing a page and verifying the real-world event it describes are different jobs.
A readable capture starts with the edges and the small print
I would place one page on a surface where its edges are distinguishable and keep shadows away from the text. After capture, I would inspect the image itself, including the top, bottom, and corners. A preview that looks tidy at a distance can still omit a line at the edge.
My first checks are ordinary ones: is the page the right way up, is the smallest relevant text readable when enlarged, and is a fold hiding a word? If a handwritten note matters, I inspect that area separately. I do not assume that a sharp printed heading means everything beneath it is legible.
In the fictional packet, a finger covers the end of a reference on the first attempt. I would capture that page again while the paper is still in front of me. Keeping a bad image and hoping recognition will repair the missing part would confuse a capture problem with a transcription problem.
An improved image does not need to look polished. It needs to show the information I will later rely on. I would retain useful margins, labels, and context rather than crop so closely that the relationship between a number and its heading becomes unclear.
Page order deserves its own check
Once the images are readable, I would check the packet as a sequence. I compare its digital contents with the paper beside me, including the reverse of the second sheet. I look for a repeated capture, a gap, or a page that belongs to a different visit.
My method does not assume that PropertyOS automatically detects those problems. The public description confirms assisted document capture; it does not specify a universal missing-page detector or an automatic reconciliation of every document in a packet. The completeness check is mine.
If I choose Apple's Notes app for a separate scanning step, Apple's document-scanning instructions explain adjusting the corners of a capture and adding further scans. That is an Apple Notes workflow. It does not establish an identical button, import format, or automatic connection inside PropertyOS.
Whatever capture route I use, I would verify the actual attachment controls available in my installed version and open the saved document afterward. I would not assume that creating a file elsewhere means it has already arrived in the home record. The final location matters as much as the scan visible on the screen.
The source image and the proposed fields answer different questions
The document shows what was written. An extracted field helps organize that information. I want to keep the two roles clear, especially when the proposed text looks more certain than the source.
Suppose the fictional paper contains a reference with a letter that resembles a zero. If a proposed field displays a zero, I compare it with the actual mark and the surrounding wording. If the paper does not resolve the ambiguity, I do not invent an answer merely to finish the form.
The same applies to dates. A document may show a date of issue and separately describe the day of a visit. Before placing a date in a record, I check the label on the original. A correctly transcribed date can still be assigned to the wrong event.
PropertyOS says suggestions can be reviewed before saving; its French listing also explicitly describes them as visible and editable. That is the verified boundary of the assistance here. I am not assuming confidence scores, a particular set of extracted fields, or recognition that always succeeds. See the current App Store description.
My annotated review of the fictional packet
I would use a small review note while checking the record. This table illustrates my decisions; it is not a PropertyOS screen or a claim that the app generates these labels.
| What I notice | What I compare | What I do before filing |
|---|---|---|
| A reference contains an unclear character | The enlarged image and the text around it | Keep the uncertainty explicit rather than guess |
| Two dates appear on the page | The heading beside each date | Use each date only for the event it actually describes |
| A reverse side contains additional notes | The paper packet and the saved pages | Include that side and check its readability |
| My sticky note adds later context | My own note and the original document | Keep my annotation distinguishable from the source |
| A page looks familiar | Page numbers and the actual content | Confirm whether it is a repeat or a separate page |
The table is deliberately about decisions I can justify from the source. It does not grade the document's authenticity or determine whether the work was satisfactory.
For an unresolved item, I would write a short question in my own working notes and leave the uncertain value unasserted. “Character unclear in the supplied page” is more useful than a confident transcription I may later mistake for something checked. I would return to that question when better information is available.
Filing means deciding which event and object the paper belongs to
After the content review, I would decide where this packet belongs. In the example, the paperwork concerns one intervention on one piece of equipment. The equipment is located in a particular room, but the paper describes the intervention rather than the room as a whole.
PropertyOS lists properties, rooms, equipment, documents, contractors, and interventions among its organizing concepts. I would use the relevant links offered in the installed app to preserve that context. The point is to make the same event understandable when I later approach it through the equipment or through the home timeline.
I would not create several slightly different descriptions just because the document is relevant to several places. Where the app offers a suitable relationship, that relationship is preferable to my manually maintaining competing summaries. If the relationship I need is unavailable, I would use a clear note without claiming an undocumented feature.
For naming, I would choose a short description that still makes sense outside today's session: the event, the object concerned, and a verified date when useful. “New scan” would tell me almost nothing later. This is an organization habit, not a promise about automatic naming or search behavior in PropertyOS.
A second look tests whether I can understand the saved result
Before considering the packet filed, I would leave the capture view and open the saved record. I want to see the actual stored pages, not only the preview I just accepted. I compare the final sequence with the paper one more time.
Then I ask a practical question: if I returned in a month without the packet on the table, would I know what this document concerns? A readable image with no useful context can be difficult to interpret. A well-labeled record pointing to an unreadable attachment has the opposite problem. I need both.
In the fictional example, this check reveals that my own later annotation is easy to confuse with the supplied notes. I would clarify the distinction now. The improvement comes from reviewing my organization, not from claiming that the app recognized the authors of every sentence.
If another page arrives later, I would identify it as a later addition and check how it relates to the existing packet. I would preserve the distinction between the date shown on the document and the date I organized it. I would not silently rewrite the earlier source to make the record appear as though it had always been complete.
Local analysis, backup, and access are separate parts of the decision
The current PropertyOS listing says OCR and document analysis run on the device, no account is required, and there is no Eternity Labs cloud. It also discloses limited pseudonymous product analytics without home content. I would not turn those statements into a claim that the app collects no data of any kind.
The same listing says external backups go to a Files folder selected by the user. A local record and an external backup are separate things to plan. I would check the available backup controls and the destination I choose; I would not assume that capturing a document automatically creates an external copy.
The current access terms also matter before organizing a large archive. Non-subscribers receive seven complete days from the first opening of this version. That access starts no subscription and triggers no automatic charge. Continuing afterward requires choosing a monthly or annual auto-renewable Premium subscription handled by Apple. The listing says records remain stored if Premium ends and return after subscribing or restoring purchases. These terms are stated in the PropertyOS App Store listing, checked on September 15, 2026.
I would begin with one small packet I can fully check
My first batch would be a document whose pages I can compare comfortably with the original. That lets me establish a naming habit, understand the controls actually available, and discover whether I need a better capture of small print before I repeat the process across a drawer.
I would keep the original paper available while checking the digital result. This guide does not decide when an original may be discarded or what status a copy has in a particular situation. Its purpose is to build a readable, understandable home record.
For the wider organization of properties, equipment, and related documents, the PropertyOS home-record guide provides the broader context. Here, my finishing test is narrower: every intended page is present, uncertain information stays uncertain, and I can explain why the packet belongs to the record where I saved it.