The fastest way to lose a data leader's trust is a six-week discovery phase that produces a document. So week one does not produce a document. It produces a query that runs, on real tables, with governance already inside it. Here is what that week looks like.
| Day one | Kickoff-deck engagement | Week-one deployment |
|---|---|---|
| First artifact | A slide deck and a readiness survey | A governed query against your real schema |
| Data used | Synthetic or sample data | Your production tables, in your cloud |
| Governance | A later phase, if at all | RBAC and predicates in the SQL from day one |
| Ends with | A plan to build later | Something that runs on Friday |
Monday: read the schema, not the wiki
The engineer starts where the data actually is. Not the data dictionary, which is out of date. Not the wiki, which describes what the schema was supposed to be. The real tables, the real column names, the real foreign keys that were never declared.
This is the unglamorous part. Column names lie. A field called status holds four meanings depending on the source system. Two tables both claim to be the customer master. The engineer maps what is there, in your own cloud, against the systems you already run. Nothing gets migrated first. Colrows queries in place with a federated engine, so week one does not wait on a warehouse rebuild.
Tuesday and Wednesday: the first scoped subgraph
Scope is one business question. Not the estate. One question the data leader actually cares about, and the handful of tables behind it.
From those tables, the engineer builds the first scoped subgraph: the entities, the relationships, and the metric definitions that the question needs, encoded once. A customer is a node, not a guess about which of three tables to join. A join path is proven, not inferred by a language model that might pick the wrong key. This is the semantic layer being built by hand against reality, and it is the work no slideware can fake. If you want the mechanics of how a question becomes governed SQL, we wrote that up in what a semantic compiler does.
Fix the Context, Not the Model. Week one is not spent choosing a model or tuning a prompt. It is spent encoding what your data means and who is allowed to see it. The context is the work. The model is a commodity that plugs in afterward.
The governance goes in first, not last
Here is the part that separates a deployment from a demo. The access rules are not a later phase. As the subgraph goes up, the engineer wires the governance into it: role-based access, attribute-based access, and row and column predicates that get injected into the plan before any SQL runs.
So the very first query the engineer runs is already scoped to an identity. A forbidden row is never read, because the compiler cannot reason over data the caller is not entitled to. That is a structural property, not a filter bolted on at the end. We argue the general case in how to secure AI agent database access: the only enforcement point an agent cannot bypass is the compilation boundary.
Friday: a query you did not write
By the end of the week, the question runs. The output is compiled, dialect-perfect SQL you can read, with the join path proven and the predicates already inside it. A working query you did not write, against your own data, that your compliance team can defend line by line.
It is one question. It is not the whole system. But it is real, and it is the seed the rest of the engagement grows from. Weeks four and eight add the governance layer in full, the first analytics and reporting agents, and drift detection, until the agents are in production and the team is trained. The full arc is on the how we deploy page, week by week.
Why week one is built for handover
Everything about week one is designed to be handed back. The subgraph is versioned. The governance is explicit. The query is readable. Nothing is a black box only the engineer can operate, because a deployment that needs us to stay is a deployment we got wrong.
That is the difference between a forward-deployed engagement and a consulting retainer. The engineer leaves. The agents, the graph, the audit trail, and the runbooks stay. You can see what that looks like across pharma, BFSI, and travel retail in our deployment write-ups.
Frequently asked questions
What does a forward-deployed engineer do in the first week?
Reads your real schema, builds the first scoped subgraph over the tables behind one business question, and runs the first governed query against real data by the end of the week. No slideware, no synthetic dataset. The output is compiled, dialect-perfect SQL you can read, with the join path proven and the governance predicates already inside it.
Do you need our data cleaned or migrated before week one?
No. The engineer works against the systems you already have, in your own cloud. Colrows queries in place with a federated engine, so week one does not wait on a migration or a warehouse rebuild. The scope is one business question and the datastores behind it, not the whole estate at once.
What do we own when the engagement ends?
Everything built during it. The agents, the versioned semantic graph, the governance layer, the audit trail, and the runbooks are yours to operate. A deployment that needs the engineer to stay is a deployment that was done wrong. The handover is the point of the engagement, not an afterthought.
