What to include in the operating brief
Describe where the workflow begins, which systems and teams touch it, where the canonical record lives, what breaks, how often the exception matters, and what outcome would justify change. A sanitized diagram, sample field list, or written sequence is useful. Credentials and customer exports are not.
What the first call should produce
The purpose is not to force a build. The call should identify the problem boundary, actors, data, permissions, failure cost, evidence, and the smallest safe next step. That may be a diagnostic, architecture blueprint, controlled prototype, implementation phase, or a decision not to automate.
Security before access
Do not send passwords, API keys, tokens, private customer data, health information, or financial account details. If implementation proceeds, access should use client-owned accounts, least-privilege roles, an agreed secret-sharing method, and a record of who approved each external write.
Frequently asked questions
What should I bring to the first systems call?
Bring the current workflow, where state lives, the expensive failure points, who owns each decision, the systems involved, and the outcome that would make the work worthwhile.
What should not be sent before the call?
Do not send passwords, API keys, customer exports, health information, financial account data, or other sensitive records. A sanitized workflow description is enough for initial discovery.
What happens after discovery?
The next step is a written boundary: the problem, actors, data, permissions, failure paths, evidence, proposed phases, ownership, and the decision to stop, prototype, or proceed.