What to send before we read a week of usage

We would rather delay a start date than invent a week. The difference is almost always in what arrives before day one.

Send a named list of screens you believe invoke a model, even if you suspect it is incomplete. A wrong list is useful; an empty boast that ‘the whole app is AI’ is not. If you have route names, include them beside the human names.

Send redacted log lines that still show field names. We need to see whether a line can be tied to a screen, a user path, an attempt number, and a model identity. If those fields are absent, say so. Do not replace them with a screenshot of a chart from another product.

If logs cannot leave the building, say that in the first message. We can sit at SS15 with a counterpart, or travel inside the Klang Valley. Supervised reading is slower and still produces a report; unsupervised guessing does not.

Provider invoices for the same window are welcome as a cross-check. They will not replace the inventory. If the invoice currency or project breakdown does not map to the app, tell us how you currently reconcile it — or that you do not.

Name a counterpart who can answer ‘what is this route’ the same day. Assessments freeze when a log line waits three days for an explanation. The counterpart does not need to be the CTO. They need to have the app in their hands.

Do not send prompt catalogues, brand guidelines, or a pitch deck. We will read them if they explain a call site; they rarely do. The same goes for access to a demo account with no traffic. We need a window in which the app was actually used.

If this pack sounds like work, it is the first day of the assessment, done early. Teams that send it tend to finish on the original calendar.