Three Fields From an Employment Contract: What the Assistant Adds to an Employee Card
A new employee signs a contract, the PDF goes into Documents, and then the same three facts are retyped into the employee card: the contract type, the start date and a short note. It is a small task, which is exactly why it gets postponed, done from memory, or filled with a date that is not the one on the paper. The assistant can read the PDF and propose those fields — but only as a proposal.
The entry point is the document itself. In Documents, an uploaded PDF has a menu item that opens the assistant with the file's name and asks it to read the document and say what it is. The item appears only when the assistant is enabled for the plan and the reading tool is available; Google Docs, Sheets and Slides do not get it, because they are links in a cloud drive, not files in the firm's storage.
The reading path is narrow and explicit. The file must be a PDF; anything else is refused with the type named in the message. The file must still exist in storage and be no larger than fifteen megabytes, because the reader holds it in memory. A damaged or password-protected PDF is refused as unreadable. The text is cut at twelve thousand characters — enough for an employment contract, not for a whole personnel file.
A scanned contract is the common disappointment. If the PDF is a photograph of paper without a text layer, the extractor returns an empty string, and the assistant says plainly that no text could be found and the file may be a scan. It does not guess from the file name and it does not pretend to have read the signature page. The practical answer is to keep the exported PDF for reading and the scan for the archive.
When the text is there, the assistant looks for three things: who the employee is, what type of contract it is and when it starts. It searches the employee directory by the name in the document. If it finds no match — a maiden name, a transliteration, a contractor who was never added — it says so. It does not create an employee, and it does not attach the contract to the nearest similar name.
The proposed action is a write action with a confirmation card. It appears with the employee, the contract type, the start date and the note. The person can change the values or reject the card. Nothing is written until the card is confirmed. This is not a limitation of the model; it is the only way a document can influence a record without a human checking the mapping.
The card saves three fields, and the narrowness is the design. The contract type is free text up to a hundred characters, because firms name contracts differently. The start date is a date. The note is one sentence, up to five hundred characters, meant to help a colleague understand what the document is — not to restate the contract. Salary, probation, notice periods and signatures have no field in this action.
There is no salary field on the employee record at all. That is not an omission the assistant should work around: payroll, taxes and payments belong to accounting, and an AI that copies a number from a PDF into a directory field would create a second, unreviewed source of truth. The contract stays the legal document; the employee card stays a directory.
Access follows the module. The action needs access to the company area where employees live; a viewer sees no card, because a card would change data. The assistant also respects the plan: if the AI is switched off, the document menu has no analysis item, and the tool is not in the list. Permissions are checked on the server, not hidden in the interface.
The original file does not move. The assistant reads it, the card stores three facts, and the PDF remains in Documents with its name, type and upload date. Nothing is renamed, archived or replaced. If the contract is re-signed with a new start date, a newly confirmed card overwrites the old values; the document itself is still there to compare.
The failures are predictable. A name in the contract does not match the directory. The contract is a scan. The start date is written as "from the first working day" and requires a human reading. The document is a DOCX, not a PDF. In each case the useful behaviour is the same: say what is missing and stop, instead of producing a plausible value that somebody will trust later.
A sensible routine takes a minute. Upload the text-based PDF, open its menu, let the assistant read it, check the three fields against the paper, confirm. For a firm that hires once a quarter, the saving is small; for a firm that onboards several people a month, the value is in not retyping and in not confusing two start dates. The assistant is a copyist with a confirmation card, not an HR department.
What cannot be claimed here is the time saved or the error rate. Those depend on the firm's hiring volume, the quality of its PDFs and its own review discipline, and without access to that data any percentage would be fiction. The mechanism can be checked in the code; the benefit has to be measured in the firm's own process.
The boundary is the useful part. The assistant reads a contract, proposes three fields, and waits. It does not sign, does not hire, does not set a salary and does not replace the document. That is a modest role, and it is the role that makes the feature safe to switch on.