What an empty date can tell you

The empty cell is doing several jobs

The blank availability cell is easy to misread because it looks the same in three quite different circumstances. A candidate may have said nothing about a date, mentioned a notice period or supplied conflicting dates in a forwarded thread. The administrator needs a different conversation in each case. Putting a plausible Monday in the cell would make the spreadsheet look more complete while taking away the very information needed to decide what to ask.

This example concerns recording availability from supplied messages, not automating recruitment judgements. Even within that small administrative task, a date can acquire authority as it travels. Someone’s tentative preference becomes a field called start_date, then an input to scheduling, then something another colleague assumes was agreed. The extraction may have begun as a reasonable interpretation; the growing confidence of the field names is what turns it into an unsupported commitment.

A nullable field avoids compulsory guessing, but the person receiving null still needs to understand it. The document may say nothing, the date may be ambiguous, processing may have failed or someone may have cleared the field deliberately. An elaborate taxonomy is not necessary for every system. The distinctions worth retaining are those that change what the administrator or another consumer should do next.

Four messages, four different obligations

Consider four invented inputs. E1 says, “I am available from 18 November 2024.” E2 says, “I can start after my notice period.” E3 thanks the sender for a role description without discussing availability. E4 contains two detached thread fragments, one naming 18 November and another 25 November, with insufficient context to tell whether the second supersedes the first. These examples are proposed contract cases, not outputs from an evaluated model. Their purpose is to settle what a useful answer would mean before asking software to supply one.

For E1, the proposed state is stated, the normalised date is 2024-11-18, and the evidence preserves the date wording. Even this answer does not establish an agreed employment start date. It records an availability statement. E2 is relative, with no normalised date and evidence containing the notice-period phrase. Asking for a missing reference is different from asking the person to repeat an answer they have already given. The record should allow that difference to survive the export.

E3 is not_stated, scoped to this supplied message. It does not establish that the person has never provided availability elsewhere. E4 is conflicting, preserves both pieces of evidence, and leaves the normalised date empty. Selecting whichever fragment appears last in an assembled prompt would convert formatting into an authority rule. If authoritative message order and clear superseding language later become available, the conflict may be resolvable. The contract should not pretend those facts were present in the fragments.

The accompanying records use kind, normalised_date, evidence and next_action to describe E1–E4. The last field explains the suggested follow-up; it is not something an incoming message is entitled to command. In a working application, routing would normally come from the controlled kind and the application’s own policy. That lets a message supply evidence about availability without also deciding which operations the office software should perform in response.

Make the state constrain the value

Putting a status beside the date is not enough if the two can disagree. A record saying conflicting and 2024-11-18 simply passes the argument to every downstream consumer: should it trust the warning or use the date? In this contract, only stated permits a normalised date. relative, not_stated and conflicting require null. Their evidence differs too: no availability statement for not_stated, the unresolved phrase for relative, and both statements for conflicting. These are small, inspectable rules about the record, before we consider whether a model interpreted the message correctly.

JSON Schema provides enums for restricting a value to a defined set, and object rules for required fields and permitted properties. Its documentation also distinguishes a missing property from a property containing null.[1][2] Those mechanisms can help express a contract. They do not establish that a sentence supports a date or that the right source document was supplied. A record can satisfy every structural rule while misclassifying E3 as stated and inventing evidence. Shape validation and evidence assessment therefore need separate names and separate failure records.

There is a modest implementation choice here. A discriminated set of record types can make invalid combinations difficult to construct, but a small integration might instead use one object plus a short explicit validator. The choice depends partly on the consumers. A spreadsheet export may need stable columns and a visible status column. An API client may benefit from handling each variant separately. Neither gains anything from silently replacing an unrecognised state with not_stated; that would turn a contract change or processing error into a claim about the document.

The evidence needs to stay attached to the right source. An accurate date quotation from the wrong candidate’s message is still the wrong answer. E1–E4 keep that association readable in the example. An actual application should supply the authorised source identity from controlled data rather than ask the extractor to invent it. Otherwise the output can agree beautifully with itself while belonging to someone else, which is not a useful form of consistency for an administrator.

Uncertainty should change the conversation

Now the administrator can ask a question that fits the gap. E2 needs the notice period or its reference, rather than a speculative date. E3 may need no follow-up if availability is irrelevant at this stage. E4 needs clarification of the competing sources before normalisation. I find that more useful than giving all three a low-confidence flag. A decimal still needs a rule to explain what happens next; these states already name the information the next conversation must supply.

Resolution should add knowledge rather than erase the trail. If a reply clarifies E2, retain the earlier relative statement and record the new message that supports a date. If a reviewer resolves E4 using a complete thread, preserve the association between that decision and its evidence. There is no need to display the whole history in every screen. There is a need to avoid making an extracted date indistinguishable from a reviewed correction or an explicit agreement made through another process.

The consumer must respect the state too. An export that keeps only normalised_date collapses three distinct unresolved cases back into blanks. A default such as next Monday defeats the contract altogether. If an older destination accepts only a date, decide whether unresolved rows should be held, exported with an accompanying exception report, or excluded with a visible count. Each option changes the operational burden. Silent omission is particularly difficult because the destination can look complete while the integration has quietly removed the people who required attention.

There is also a privacy cost to indiscriminately retaining evidence. A short date phrase and a controlled source reference may be enough for this task; copying entire personal messages into every downstream log is not automatically justified. Preserve what makes the interpretation reviewable, restrict who can retrieve it, and make the retention decision with the workflow owner. More context helps only when someone is entitled to use it and can distinguish relevant evidence from surrounding correspondence.

Keep only distinctions someone can act on

A team could extend this model indefinitely: conditional, approximate, withdrawn, translated, awaiting review, and so on. Some distinctions would be valuable in particular workflows. Others would create a set of categories nobody applies consistently. Start with examples that expose a real difference in action, and write the expected result before building the extractor. Include an example that deliberately remains unresolved. That makes restraint part of the specification rather than a disappointing result discovered after deployment.

For a simple human-only inbox, a note saying that availability needs clarification may be sufficient. A typed record becomes useful when several people or systems would otherwise interpret the same empty cell differently. Its meanings then need maintaining, including a way to review unfamiliar cases and introduce contract changes deliberately. Adding states is worthwhile when they spare a later person from reconstructing why the date is missing.

For E2, E3 and E4, I would evaluate whether the recipient can tell a relative statement from silence and from conflicting evidence. The share of populated date cells misses that distinction entirely. An extractor can finish its job faithfully with no normalised date, provided it says why and preserves what supports that explanation. The later clarification then remains an ordinary part of the office’s work, rather than a failure the extractor feels obliged to conceal with a guess.