Most data quality work happens too late. Someone exports a spreadsheet, finds the typos, duplicates and blanks, and spends an afternoon cleaning. Next month, they do it again.
The cheapest place to fix data quality is the point of entry: the moment information is first typed into a form. Every error caught there is one nobody has to clean later.
The dimensions of data quality
It helps to name what “quality” means. Commonly used dimensions include:
- Accuracy — does the value reflect reality?
- Completeness — is the information that’s needed actually there?
- Consistency — is the same thing recorded the same way everywhere?
- Validity — does the value fit its expected format or rules?
- Uniqueness — is each real-world thing recorded once?
- Timeliness — is the information current enough to act on?
Point-of-entry design directly improves validity, completeness and consistency, and makes accuracy and uniqueness much easier to achieve.
Principle 1: Validate formats where they’re typed
An email address that isn’t one, a phone number with letters in it, a date in three different styles — these are validity problems, and they’re entirely preventable. Give each field a type and, where it helps, a format that’s checked as the person types. A form that refuses an invalid email is doing data cleanup in advance.
Principle 2: Require what you can’t act without
Completeness is about the fields you’ll actually need. Make those required, and leave the rest optional. Over-requiring backfires: people type “n/a” or “000” to get past a field, which is worse than a blank.
Principle 3: Define each piece of information once
Consistency problems usually come from the same information being defined in several places — one form asks for “Mobile”, another for “Phone”. Define reusable groups of fields once and build every form from them, so the same question is always asked the same way.
Principle 4: Change definitions deliberately
When a form changes, old answers shouldn’t be reinterpreted against new questions. Versioning definitions — so each answer is tied to the version of the question it was given to — keeps history consistent even as forms evolve.
Principle 5: Let people check their own answers
A review step before submission — every answer in one place, with a chance to fix mistakes — catches typos that no validation rule can. It’s especially valuable on public forms, where you can’t ask a colleague to double-check.
Principle 6: Know who entered it
Accuracy questions often come down to “who told us this?” Capturing identity with each submission means there’s always someone to confirm a detail with.
Principle 7: Prefer references to retyping
Uniqueness suffers when the same customer or location is typed fresh on every form. Where possible, let a form point at an existing record rather than asking for its details again.
A point-of-entry checklist
For any form, ask:
- Does every field have the right type?
- Do email, phone and similar fields have formats?
- Is every field we can’t act without required — and nothing else?
- Are shared field groups defined once and reused?
- Is there a review step before submission?
- Do we know who submitted each entry?
What good and bad entry look like
| Aspect | Weak form | Strong form |
|---|---|---|
| Free text, no checking | Text with an email format, validated as typed | |
| Phone | Number field | Text with a phone format, preserving formatting |
| Address | One “Address” box | Street, city, state, postal code as separate fields |
| Date | Free text | A date field |
| Choice | Free text | A fixed set of options |
| Required | Everything, or nothing | Only what you can’t act without |
| Review | Submit immediately | A review step before submitting |
Each improvement is small. Together they change the character of the data you collect.
The cost curve
Fixing a data problem gets more expensive the later you catch it:
- At entry: the person types it correctly the first time. Cost: near zero.
- At review: someone spots it before it’s used. Cost: a minute.
- In use: a crew drives to the wrong address, or an email bounces. Cost: an hour or a customer’s patience.
- In reporting: analysis is wrong, or someone spends a day cleaning. Cost: a day, plus the decisions made on bad numbers.
This is why design at the point of entry pays off more than any cleanup process.
Making quality someone’s job
Even excellent forms need a human in the loop:
- Assign an owner for each kind of information, responsible for what “correct” means.
- Check new submissions regularly, while it’s still easy to follow up.
- Track recurring problems. If one field is often wrong, the field is the problem, not the people.
- Close the loop with the form. Fix the label, the format or the required rule, and publish a new version.
A short quality review, monthly
- Which fields are most often blank or wrong?
- Which questions do respondents ask that the form doesn’t answer?
- Are any two forms collecting the same information differently?
- Has any definition changed without everyone knowing?
- Are duplicates appearing, and why?
Thirty minutes a month is enough to keep quality from drifting.
Frequently asked questions
Isn’t validation annoying for users? Done well, it’s the opposite: catching a typo immediately is less annoying than a phone call a week later. What frustrates people is validation that rejects legitimate answers or clears what they typed.
Should I validate everything? No. Validate what has a real format — emails, phone numbers, dates — and leave genuinely free-form answers free.
What about data that’s already bad? Fix entry first so the problem stops growing, then clean what matters in priority order.
How Atlas applies these principles
Stratosphere Atlas was designed around point-of-entry quality: fields live in reusable data schemas with types, formats and required rules; published schemas are versioned; public forms capture each respondent’s name and email and end with a review step; and forms are generated from the same schemas Atlas stores, so what people see and what Atlas accepts can’t drift apart. See Governed public intake.
