What the customer wrote down and what the machine knows

In one line

The intake answers are the customer's memory, and the system is the fact. The work of the first week is not to believe the answers but to reconcile them field by field and build a list of the fields that do not match and the fields with no answer.

Why this was needed

Before going on site, you usually send a questionnaire. What the version is, how many days logs are kept, what it integrates with, how often the backup runs. When the answers come back, you build the schedule, the access permissions, and the migration plan on the premise that they are right. And when you go in, about half of them turn out to be different.

Nobody lied. The person who wrote the answers is usually the one who installed that system three years ago, and since then someone shortened the retention period, someone attached one more integration, and the backup interval was changed after an outage. The answers are the system in that person's head, and what we meet is the system as it is now. Documents age more slowly than systems.

The problem is not the mismatch itself but building a plan without knowing about the mismatch. If you believed logs are kept for 30 days and promised "we will reconstruct the incident from two weeks ago", but the actual retention is 14 days, that promise is already broken. Whether you learn about the broken promise on the first day of the engagement or on the day before the report decides the success or failure of the work.

How it works

If you reconcile by eye, things will certainly slip through. The fields run past twenty, some fields look "roughly right", and some fields have no way to be measured and get skipped. So for reconciliation, harden the rules into code and let a machine run it. The rules only need to decide one thing per field: "how to compare".

Exact match (exact) — a version string or a time zone name, where a single character of difference makes it a different value.
Within a range (range) — a field the customer answered as a range from the start. If they answered "from 80 days to 100 days", you only check whether the measured value falls inside it.
Tolerance for approximate figures (tolerance) — a field where the customer answered "about 1,200 a day". You set in numbers how many percent still counts as the same. That number has to be written in the rules file, and if it is not written there, it is not a verdict but a mood.
List comparison (set) — a field such as the integration targets, where order has no meaning. It is not wrong because the items were written in a shuffled order.

Up to here it is a story of right and wrong. What matters more in real practice is the remaining two.

A field with no answer (unanswered) — that field of the questionnaire is empty. Whether or not it can be measured, you have to start by finding out who decides that field.
Unverifiable (unverifiable) — there is an answer, but you could not find a place in the system to verify it. Things like the recovery time objective (RTO), the on-call headcount, and a contractual SLA fall here.

The key is to write these two neither as "match" nor as "mismatch". If you write what you could not confirm as correct, nobody looks at that field again later, and if you write it as wrong, you argue with the customer for nothing. You have to write what you do not know as not known for it to stay on the list.

답변 칸 하나
   ├─ 답이 없다                  → unanswered   (누가 정하는 값인지부터 묻는다)
   ├─ 답은 있는데 잴 자리가 없다  → unverifiable (어디를 보면 되는지 묻는다)
   └─ 답도 있고 잰 값도 있다
        ├─ exact      같으면 match_exact
        ├─ range      범위 안이면 match_in_range
        ├─ tolerance  허용 오차 안이면 match_in_range
        └─ set        집합이 같으면 match_exact
                      아니면 전부 mismatch

The reason to give the rules a priority is the same. A field that is empty and also has no place to measure falls under both, and if you do not decide in advance what to write for it, each person writes it differently. This lab looks at the unanswered side first. This is because the fact that "nobody decides this value" is more dangerous than the fact that it cannot be measured.

What it looks like in the field

First, if you write the reconciliation result as a list of faults, the relationship suffers. If you walk in holding a table saying twelve fields are wrong, the customer becomes defensive first. If you turn the same content into questions, it becomes a conversation — "You wrote that log retention is 30 days, but the server currently holds 14 days. Which is the correct value?" This sentence is not a verdict but a confirmation, and the person answering has nothing to defend. That is why this lab has the reconciler even generate the question sentences.

Second, a measured value must come with its source. If it is not written where "14 days of logs" came from, the conversation stops when the customer replies "we keep them in the archive too". If the source is written as "the range of file names in the site/logs directory", you can move straight to the next question — where is the archive, and how many days can you see there.

Third, reconciling once and stopping is useless. The answers are updated in the middle of the project too. If you leave the rules and the reconciler as files, you can rerun the same command two weeks later and see what changed in the meantime. A reconciliation done by eye cannot be rerun.

Fourth, if you do not use a tolerance, the table turns entirely red. If you write the answer "1,200 a day" against a measured value of "1,104" as a mismatch, the real problem, the backup interval (answered as 24 hours but actually 6 hours), is buried in the same color. Allowing a tolerance on approximate-figure fields is not going easy on them but keeping the signal alive.

What really matters in practice

An answer is not evidence. An answer is a map that tells you where to ask, and the evidence is the value measured on the system.
Decide the verdict rules first, then reconcile. If you decide the rules while reconciling, you get the result you want to see.
Leave the fields you do not know on the list. Unverifiable is not a conclusion but the place of the next question.
Deliver the result as question sentences. We look at the table, and to the customer we give questions.

What you will do in the next lab

You hold the nine intake answers of (fictional) Hanbit Logistics and that company's real system. You measure the system directly to build a facts file, decide the verdict rule for each field and harden it into a file, and build a reconciler that judges into five verdicts: exact match, within range, mismatch, no answer, and unverifiable. The grader feeds answers and facts made with different values each time into your reconciler, actually executes it, and checks the verdicts one by one. At the end you have the machine generate the question to ask again for each mismatched field, and deliver the result as a four-section report.