Questions we get asked.

Yes. The first two weeks are the Migration Readiness Sprint at /databricks/migration-readiness. TechFabric Airlift at /accelerators/airlift composes Databricks Lakebridge, then wraps conversion in signed certificates and a reversible cutover. If you already know the source, start at /databricks/from-snowflake, /databricks/from-synapse or /databricks/from-teradata.

Deciding who can see what, proving it, and keeping lineage intact as data moves. In practice that means catalogue and schema design, grants that match how your teams actually work, and making sure the applications and agents you build inherit those permissions instead of routing around them.

Both. Applications that run in-workspace under their own service principal are a large part of what we do, using Databricks Apps, Unity AI Gateway, Model Serving and Genie. That is the difference between a lakehouse and a system people actually use.

Usually on the initiative that keeps slipping because your team is fully committed elsewhere. We take ownership of that piece without pulling anyone off the current roadmap, and we work in your workspace so nothing has to be handed back later.

Unity Catalog, Lakeflow, Delta, Databricks SQL, Databricks Apps, Model Serving, AI Gateway, Genie, Lakebase and Asset Bundles. Our accelerators are built on those same surfaces.

In practice they overlap, and pretending otherwise is how grants get retrofitted. We design the catalogue and the schema shape at the same time as the pipeline, so permissions and lineage are a property of the model rather than something added once the tables already exist.

The separate governance line at /services/data-ai-governance exists for the cases where the estate is already built and the problem is defending it.

Yes, and it is common. The first work is usually reading what is actually running rather than what the documentation claims: which jobs matter, which tables nobody has queried in a year, and where the grain silently changes.

That inventory is the same one the Migration Readiness Sprint at /databricks/migration-readiness produces, and it is worth having before anyone proposes a rewrite.

Yes. It's most of what data engineering is once the slides are put away. Ingestion from the systems the business runs on, transformation into tables people can query, and integration so the ERP, the CRM and the lakehouse describe the same customer and the same order.

On Databricks that's Lakeflow pipelines and Lakeflow Jobs, with Temporal underneath the flows that cross systems and must not half-complete.

Yes, and those three plus Synapse pipelines are the estates we see most. The conversion runs through TechFabric Airlift, which composes Databricks Lakebridge and adds what Lakebridge doesn't do: a record of every change so a reviewer can check the translation, a signed certificate per object, and a cutover with a tested way back.

The Migration Readiness Sprint comes first, so you know the package count and the ones that will fight before you commit.

If you need one more pair of hands on a pipeline your team already owns, hire. If the pipelines are the problem, you want a team that has shipped together and that builds the application and agent layer above the tables from the same people, because a platform nobody builds on doesn't get used.

We don't do body-shop staffing, and the engagement is scoped so you can judge us on something small before anything larger.

Yes. Databricks is where 80 of our engineers are certified and where we've gone deepest, and where a system has to reach past the workspace we build on Azure, AWS, Google Cloud and Cloudflare too. What decides the design isn't the platform. It's whether the numbers have to reconcile and who has to be able to defend them.

By treating cost as a design constraint rather than a monthly surprise. Cluster policies, sensible file sizes, and knowing which queries are actually paying for themselves. The two-week Databricks Health Check at /databricks/health-check is the named engagement when the bill is the question.

Lakeflow is enough for most pipelines. Temporal earns its place when a process spans systems and must not half-complete, or when a human approval sits in the middle of it and the workflow has to survive the wait. We are a Temporal partner and we use it where that property is worth the extra moving part, not everywhere.

A feature calls a model.

A system is everything that has to be true for that call to be trustworthy on the hundredth day: where the context comes from and how it is retrieved, what the agent is allowed to touch and under whose permissions, what happens when a step fails halfway, how you know an answer is still correct after someone changed a definition, and what it costs.

The model is nearly free.

Whether the call ships is decided by the rest of that list.

Usually you need definitions before you need a graph. Andrew Ripley, who runs product here, walks into arguments that come down to a word two teams both use correctly and still cannot share.

We start with the semantic layer, add structured relationships where questions genuinely span entities, and do not sell a graph to a problem that a definition would have fixed.

Yes, and that is the default. Applications and agents run in your workspace under their own service principal, inheriting Unity Catalog permissions. Hosting by us is available where it suits, but nothing about the architecture requires your data to move for it to be reasoned over.

An evaluation harness with ground truth you own. We sit with the people who already know the right answer, write the questions they actually ask, record what the answer should be, and run that suite against the system on every change. Without it you are relying on whoever last used it not to have hit the broken case.

Canvass is one we built and run for a client: account research and campaign review on Cloudflare with PostgreSQL and durable Temporal workflows, with TechFabric Platform governing business actions and required human approvals. The implementation connects the interface, authorization and recovery path in one working product.

Later than most people expect, and it is not usually the first problem. Optimisation of any kind, whether reinforcement learning on the model or an automated loop tuning the workflow around it, needs something to optimise against: a rubric that says what a good answer is and an environment that can score one.

Almost every team we meet wants the optimisation and has neither. Build the rubric and the environment first, and you get most of the benefit from ordinary iteration; skip them and reinforcement learning is an expensive way to hillclimb a hill nobody has measured.

Both, in the same room, and that is the part we will not do at arm's length. Andrew Ripley, who runs product here, sits in those sessions for exactly this reason. The rubric encodes what your business considers a right answer, which is knowledge you have and we do not.

Our job is to interrogate it until it is specific enough to score automatically, then build the environment that runs it. An engineer who has never sat with the people who own the question cannot write it, which is most of why we deploy forward.

Usually because the model underneath is ambiguous rather than because the language model is bad. Two tables both hold something called revenue, the grain changes halfway through a table nobody documented, or an instruction says one thing and a column name implies another. Genie resolves that ambiguity silently and moves on. The fix is upstream of the prompt every time.

With a suite of benchmark questions that have known answers, run repeatedly rather than once at launch. That gives you a number that moves when someone renames a column, which is the only way to know accuracy is holding. The Genie Accuracy engagement at /databricks/genie-accuracy exists to build that suite and the definitions under it.

Not if the permissions are done properly, and this is the question worth asking early. Genie queries under the identity of the person asking, so row and column filters in Unity Catalog apply to the answer the same way they apply to a query.

Where that boundary has not been drawn yet, it is governance work before it is Genie work, and it is at /services/data-ai-governance.

Yes, and they should read the same definitions. A dashboard answers the question everybody asks every Monday, and it should look identical every Monday. Genie answers the question somebody thought of in the meeting. Building them on separate definitions is how you end up with two numbers and an argument.

Building models where one is needed and, more often, productionising the one you already have.

Feature engineering registered in the Feature Store, MLflow for experiments and the registry, a Model Serving endpoint with its own service principal, an evaluation gate that has to pass before a new version is promoted, drift monitoring on the inference table, and the retraining job on a Lakeflow schedule.

Eighty of our engineers are Databricks-certified, and the pipelines underneath are at /services/data-engineering.

Less than teams expect on the serving itself and more than they expect on everything around it. The endpoint is straightforward.

Reproducing the training set, moving feature computation somewhere that runs without one person's laptop, and deciding what happens when the model degrades are where the work actually is. That's usually two to six weeks depending on how the features were built.

On a schedule to begin with, because it's honest and it's cheap, then on a drift signal once there's enough production history to know what normal looks like. Retraining on drift before you can characterise drift produces a model that chases noise. Lakehouse Monitoring's inference profile gives the inputs and predictions a baseline to be measured against, window by window.

Both, and the second is more common. Most teams we meet have a data scientist who has already found something that works and no path from there to an endpoint anyone will depend on.

Where a model does need building, our engineers work alongside your data scientists rather than replacing them, because the domain knowledge that makes a feature useful is already in your building.

When a rule does the job. A threshold somebody can explain beats a model nobody can, if the threshold catches the cases that matter. We've replaced planned models with three lines of SQL more than once, and the client kept the budget.

A model earns its place when the pattern is real, the data to learn it exists, and the cost of being wrong is one you can measure.

MLOps is the discipline of shipping and running models the way software is shipped and run. Versioned features, tracked experiments, a registry that says which model is live, a gate before promotion, monitoring after it, and a rollback.

You need it the moment a model's output feeds a decision somebody is accountable for. Before that, a notebook is fine, and we'll say so.

Yes, and the first question is whether the data has to move. Lakehouse Federation reads Snowflake, SQL Server, Synapse and others in place, which is enough for a first model.

If the model goes to production, the features usually want to live on Delta next to the serving endpoint, and that's the point at which the migration conversation at /services/databricks starts.

This page is models that predict, score or classify, and reach an endpoint. Agents and applications built on language models, with retrieval, tools and a governance boundary, are at /services/ai-systems. The two share the platform, MLflow and AI Gateway among them, and often share an engagement, but the failure modes are different and so is the evaluation.

Yes, that's the forward-deployed model at /services/forward-deployed. A working team with a lead who owns the outcome, in your workspace and your repository, rather than individual contractors you manage. Ask for the certification count of any partner you talk to, because it's checkable and a tier isn't.

With one model, end to end, because a proof of concept that never serves a request teaches nobody anything. We pick it with you, take it from wherever it is to a monitored endpoint, and write down what was decided and why. If the estate itself is the question, the two-week Databricks Health Check at /databricks/health-check comes first.

At TechFabric it starts with an inventory of what's true today. Which grants exist, where lineage breaks, which tables nobody has queried in a year, and what an examiner would find.

Then the design work, which is catalogue and schema structure, a grant model expressed through groups, row filters and column masks where a table-level grant isn't fine enough, and the audit evidence pulled from system tables so the answer to a question is a query. The two-week Databricks Health Check at /databricks/health-check is the named way to start.

It's the substrate, not the answer. Turning it on gives you somewhere to express grants; it doesn't decide who should have them, whether lineage still resolves after a rebuild, or what an agent is allowed to touch. Most of the engagements we take start from a working Unity Catalog and an estate nobody can defend in a meeting.

The written answer to four questions. Which data each model and agent may read, under whose identity it acts, what it's allowed to do without a person approving, and what gets recorded so you can reconstruct a decision afterwards. On Databricks the enforcement half already exists.

Agents run under a service principal that inherits Unity Catalog permissions, AI Gateway logs the calls, and the audit table records the access. The framework is the policy that decides what those settings should be, and we write it with your security lead rather than for them.

The same way you govern a person, which is the point most teams miss. The agent runs under its own service principal and inherits Unity Catalog permissions rather than being handed a broad token.

What it may do is a policy decision made before it's built, not a setting adjusted after something goes wrong. Fabric Tower at /accelerators/fabric-tower is what we use when a squad of agents needs watching rather than one.

Yes, where the governance question turns out to be a definition question, which it usually does. Two teams both call a column revenue and both are right, and no grant fixes that.

We write the definitions down with whoever owns each number, put the quality checks into the pipeline so a bad load stops instead of landing, and handle the master data reconciliation that sits underneath. The pipeline half of that work is at /services/data-engineering.

Retrofitting it does. Designing it alongside the pipeline doesn't, and it's considerably cheaper than the alternative, which is discovering during a security review that the grants don't hold. We put the permissions boundary in the first architecture conversation for exactly that reason.

The first thing we establish is what's actually true: which grants exist, where lineage breaks, and what an examiner would find today. That inventory is quick, and it tells you what's reachable before the date rather than after it.

Most of the evidence an auditor asks for is already in system. access. audit and the lineage tables; the work is knowing which query answers which question.

Yes. We're a Microsoft Solutions Partner with a Data & AI designation, and a lot of the estates we govern have Power BI, Dynamics 365 or Azure SQL in them.

Row-level security in Power BI, the connection that lets a report inherit Unity Catalog permissions, and the Azure side of the identity model are all in scope, because a governance model that stops at the workspace boundary isn't one.

With the two-week Databricks Health Check, which is fixed fee and reads the estate as it stands, including the grants and the lineage. You get a scorecard and a written recommendation whether or not you continue. Longer work is scoped against that document rather than against a brief, so the second number is known before anyone commits to it.

A contractor takes a ticket, where a forward-deployed engineer takes the problem and stays with it until it is gone. They sit with the people who have it, work out what is actually wrong, and build the fix. You are buying judgment about what to build, not hours against a specification someone else already wrote.

Days, not months. Our engineers average fifteen years of experience and have worked in unfamiliar enterprise codebases many times. The two-to-three week discovery exists so that ramp happens against a scoped piece of real work.

Yes, because continuity is most of what makes the arrangement worth anything. The team assigned to your project stays on your project and learns your systems, your data and your business context. We do not rotate people between accounts to balance utilisation.

Either, and the choice is yours. Our people can embed in your team, joining your standups, using your tools and reviewing your pull requests.

Or we take the whole programme and run it as a full team from our own offices, delivering against outcomes while your team stays on its current roadmap. That second model is how we take on the larger builds, and plenty of engagements start as one and become the other.

The permissions boundary gets drawn in the first conversation, because giving an agent reach into production data before that line exists is an incident with a date on it.

What comes out of that conversation, in order: a business problem stated precisely enough to argue with, that problem turned into a scoring rubric and an environment that can run it, then the agent or workflow that scores well against it.

Tooling now writes a great deal of the third. The first two still require sitting with the people who own the problem and knowing what a right answer looks like to them.

Because the constraint moved rather than disappeared. When implementation was expensive, the scarce skill was building the thing. When implementation gets cheap, the scarce skill is deciding what should be built and being able to tell whether the result is right.

A wrong goal now gets implemented faster than it used to. Our engagements have gone from ten people to three on exactly this basis: the three are the ones who can define the problem, write the rubric, and judge the output.

Both. Alongside software engineers we field product engineers, who decide what is worth building and cut the scope that is not, and design engineers, who make the thing usable. All three work as one team, and AI has made that team considerably smaller and faster than the equivalent staffing three years ago.

Andrew Ripley runs product and Sam Salima runs design, both in house. Sam puts the design case as arriving while the engineering decisions are still open, since coming in after them leaves you decorating whatever was already decided badly.

Most start with a two-to-three week discovery, which gives you a scope, an architecture and a realistic cost before you commit to anything larger.

From there we put the right team on it to get things done, with daily demos so you see working software every day. That might be a single embedded engineer or a pod that owns the programme outright.

The parts that decide whether a product is operable: an admin and operator console, tenant isolation enforced in the data layer, an audit trail of state changes, and the deployment path that gets releases out repeatedly.

TechFabric Platform gives you a governed mutation pipeline, so every state change is policy-gated and auditable from day one instead of being retrofitted. Harness gives you a durable agent runtime. Those are months of foundation you do not have to write.

Yes. Everything we build for you is yours. Where an accelerator is involved we are explicit about which parts are ours and what it means for you to keep running them.

Azure, AWS, Google Cloud and Cloudflare, chosen for the product rather than for us. Where the product belongs next to a lakehouse it ships as a Databricks App running under its own service principal, and that is one option rather than the default.

If you are already committed to a provider, that is a constraint we design to rather than an argument we will have.

Yes, and we build new ones from scratch just as often. Greenfield and brownfield are both normal work here: a product that does not exist yet, or a system that does and needs extending, replatforming or rescuing.

Discovery assesses what is already there before anyone proposes replacing it, so whether you extend or start fresh is decided on the evidence in front of us.

Any process with more than a few steps that must not half-complete: a payment that charges but does not fulfil, a repossession that starts but is never recorded, a pipeline that dies mid-run and leaves partial data. Temporal makes the workflow itself durable, so the process survives the infrastructure under it.

No. The usual pattern is to leave the services alone and put a workflow in front of the sequence that calls them. Your existing APIs become activities. That is how we migrate an existing job chain without a rewrite.

A queue gives you delivery. It does not give you the state of a business process. Temporal keeps a complete, replayable history of the workflow, so you can answer what happened, where it stopped and what compensating action ran, without reconstructing it from logs.

Yes, and it survives a restart. A workflow can park for days waiting on a signal, then continue from exactly where it stopped. We use that pattern in our own systems for anything that leaves the workspace.

Both. TechFabric is a Temporal partner and we have certified durable paths against Temporal Cloud, including a workflow that survived a full application restart and completed from its original history.

No. It is a library you register inside your own application, not a system you migrate onto. You start by routing one domain's mutations through it and expand from there.

An audit log records that something changed. This makes the change impossible unless a policy allowed it, and the event that explains why is emitted as part of the same transaction. You audit by running a query.

That is the reason it exists. An agent actor passes exactly the same policy and state-machine gates as a human one, with the same audit trail. There is no separate, weaker path for automation.

Yes. The local runtime, Temporal worker path, model provider registry, approvals, tasks, artifacts, metrics and Docker sandbox support agents running under real production workloads.

The same definition builds for a local Node runtime, a Temporal worker, a Cloudflare Worker, or a Databricks App running under its own service principal. You choose the target without rewriting the agent.

Tools resolve through Unity Catalog, so an agent's data access is bounded by the same grants as a human analyst's. It cannot reach what its service principal has no permission for.

Twenty-seven, each with an executable playbook. Snowflake, Azure Synapse and Teradata have their own pages at /databricks/from-snowflake, /databricks/from-synapse and /databricks/from-teradata. Redshift, Oracle, SQL Server, BigQuery, Netezza and SAP are covered too. Tell us your source and we will confirm what the playbook does today.

Cutover runs as checkpoint, apply, verify, with a defined path back out of an external change. A wave only cuts over once its certificate is issued, so the gate is the evidence itself.

That is the design goal. Every converted artifact is bound to immutable evidence and carries the tool version that produced it, so what was in scope, what proved it correct and who approved the wave are all answerable after the fact.

Yours. The control plane is a Databricks App inside your own workspace. TechFabric-hosted is available as an option, but in-workspace is the default so your data never leaves your boundary.

Promotion. An agent or model version only moves forward if its evaluation suite passes, and the gate is a policy checkpoint in the pipeline, and it holds when a release is late.

Every pull request gets one, with per-environment secrets synced to secret scopes. The point is that a change gets an environment before it gets an opinion.

Monitoring tells you a job failed. Radar carries declared service level objectives per workload, so it can tell you whether the breach matters, who is allowed to intervene, and what was actually done about it last time. If you are not sure the workspace is worth that yet, the Databricks Health Check at /databricks/health-check is the two-week way in.

Restarting a job or rerouting a pipeline runs as a policy-checked action with an audit record, executed as a durable workflow. A fix at two in the morning stops being an untracked click in a terminal.

Telemetry ingest is deliberately append-only and stays outside the governed pipeline. Only state transitions pass through it, which keeps the audit trail meaningful instead of drowning in events.

One place to watch, steer and stop the work of an agent squad: a mission board, one-tap approval tickets, a runs ledger and shared documents, with the governance pipeline under every change.

No, and that is enforced structurally. Anything that would leave the workspace parks at a ticket that a person answers. The supervisor plans and routes; it never approves.

The mission resumes. The durable path is certified against Temporal Cloud: a mission parked at approval survived a full application stop and start, then completed from its original workflow history.

No. Databricks stays authoritative for compute, data, lineage and governance. Native MLflow runs are referenced rather than copied, so datasets, traces and artifacts stay where they are, and Experiments adds assignment, gates and cross-workload evidence on top.

Assignment, evaluation and quality gates run against your own Databricks data, so the comparison is mechanical. A failed evaluation blocks the promotion. When the thing being scored is a Genie space that executives have already stopped trusting, the named engagement is Genie Accuracy at /databricks/genie-accuracy.

Yes. The same gates apply to an agent version as to a model version, which is what lets you ship agent changes at a pace without guessing at the effect.