Straight answers

The data operating model a mid-market business runs on: who owns each dataset, what the rules are, and how you prove it. It is the organisational layer that sits above Microsoft Fabric or AWS, or ahead of choosing either.

No. A catalogue discovers what exists, captures lineage and classifies columns; Purview, DataZone, Atlan and the rest do that well. Lake On Rails holds what a catalogue does not: a named accountable owner per dataset, a responsibility matrix, written procedures with approvals, and a measure of whether any of it is happening. If you have a catalogue, keep it. The register can read from it.

No. Tools like Great Expectations, dbt tests and the platforms' own monitors check the data. Lake On Rails records who is responsible when a check fails, what the procedure is, and whether it was followed. They are complementary.

Because governance is the content of what we sell, not the label. To most people running a business your size, "governance" reads as cost and bureaucracy, a thing you do after you have had a problem. What this actually is, day to day, is a short list of decisions — who owns what, what the rules are, how you prove it — and a system that keeps them true. That is an operating model.

Three levels a dataset moves through: as it landed, cleaned and checked, and ready to report from. Each has written criteria and moving up needs an approval. If you know the "medallion" vocabulary, they map onto bronze, silver and gold. We say trust tiers because your finance director has never heard of a medallion and should not have to.

No. It never moves, transforms or stores the contents of your data. Where you connect it to a platform it reads technical metadata only: dataset names, schemas, owners and refresh times, from Microsoft Fabric and Purview or from the AWS Glue Data Catalog, on a schedule. You can also run it with no connection at all, on metadata you enter yourself or import from a spreadsheet.

We will tell you what each is good at and where each will cost you engineering time. We will not put a thumb on the scale, because the point of the product is an operating model that holds whichever way you go. Scorchsoft does build on both if you want the same team for the build.

The operating model is identical and the Glue connection reads the same metadata the Fabric one does. Our platform-specific notes are deeper for Fabric today and the AWS content is being expanded. If that matters to your decision, ask, and we will show you exactly where each stands.

The operating model does; the capability map has a "custom platform" option and the register can be populated by import. There is no automated metadata connection for those platforms today. If one of them is your platform, say so in the demo request and we will be straight about what that means.

Yes, on Professional and Enterprise. A versioned REST API and an MCP server expose the register, roles, procedures, work items, courses, workflows and audit trail, so you can connect Microsoft Copilot, ChatGPT, Claude or an agent you have built yourself. The point of it is the typing: an assistant can draft descriptions and classifications for a few hundred datasets against your own register, which is the work that otherwise stalls this in month three. How it works, and what stops it going wrong.

Five things, all enforced in the product rather than promised in a policy. It ships switched off, and turning it on is an explicit, audited act by one of your admins. Writes arrive as proposals in a review queue by default, with the assistant's stated reason as the first column and a field-by-field diff — applying them directly is a setting you have to choose. A proposal records what it was based on, so if a person edited the same field in the meantime, approval stops and shows you a three-way diff instead of overwriting them. Every change is snapshotted with its reason, marked on the record as AI-assisted, and revertible to the previous version. And permissions are twelve narrow named scopes with no wildcards and no delete, capped by what the person who issued the credential is allowed to do today.

No. The API and MCP server are optional, off by default, and the product is complete without them — every screen works the same way whether or not anything is connected. They are there because most of our customers will want an assistant doing the documentation drafting at some point, and because an operating model that only a human can update is one more system that goes stale.

Yes. All traffic is encrypted in transit over TLS 1.2 or later with modern cipher suites. The database is encrypted at rest with the hosting provider's native disk encryption (AES-256). Daily logical backups are encrypted before being written to object storage. Application secrets are held in the hosting platform's secrets store and never committed to source control.

Three ways, agreed in the first conversation. The standard service is hosted by Scorchsoft in a UK or EU region agreed with you, with your organisation's data isolated from every other. Where your policy requires it, we set up a dedicated instance, or deploy it into your own Azure subscription under your identity and network controls, with your IT partner operating it if you prefer. What each means commercially.

Not yet, and we are honest about that. A SOC 2 Type I audit is planned, with ISO 27001 work to follow. Today we operate under OWASP-aligned engineering practice, run internal security reviews against the codebase, and publish a responsible-disclosure policy. A security review summary and a gap-to-SOC-2 analysis are available on request for serious evaluations.

Yes, on the Enterprise plan, against your own identity provider: Microsoft Entra ID, Okta, Google Workspace and other OAuth or SAML providers. The internal login remains available as a fallback. Because SSO is configured against your provider, Enterprise is set up with our team rather than self-served.

Access to production is restricted to a small number of named platform engineers whose credentials are scoped, logged and rotated. Support access to a specific customer's tenant needs either your explicit request or an approved incident-response action, and the access is recorded in the application's audit trail. We do not mine customer metadata for analytics. Sub-processor details are in the data-processing addendum, available on request.

Continuous write-ahead-log archiving plus daily logical dumps, a one-hour recovery point objective and a four-hour recovery time objective, with quarterly restore drills. Backups are kept for thirty days rolling with a twelve-month monthly retention for audit. A documented incident-response runbook with severity definitions and communication commitments (a P1 acknowledged within fifteen minutes) exists and is shareable under NDA, along with the drill log.

The application has no edit or delete path for it: every change writes a new event and nothing is overwritten. A database administrator with direct access could still alter the underlying table; that is true of every audit log you already rely on, including your ERP's. What we do about it is restrict direct database access and sign the exports. We would rather you knew that now than found it later.

No. It sets no cookies, runs no analytics and loads nothing from a third party. The forms email us what you type and nothing more. The privacy policy is short because there is little to say.

Not unless you ask us to, and either way it is written into the partner terms rather than implied. The default is that you remain the commercial lead: we register the account to you, we do not contact your customer without you, and we do not pitch development work to them unsolicited. When the operating model surfaces something that needs building, you qualify it and lead or join the proposal. If you would rather we never speak to the customer directly, say so and we will put that in writing too. And if you would rather hand the relationship over entirely — some firms want the introduction to be the end of their involvement — we will contract with the customer directly on a referral fee. Both models, side by side.

Our centre of gravity is the product and bespoke engineering; yours is operating the estate. Tenancy, identity, network, cyber assurance, Fabric capacity, Purview guardrails, the service desk and anything watched at three in the morning are yours. Lake On Rails itself, bespoke applications, APIs, product-owned ingestion and AI embedded in software are ours. Where a piece of work spans both — a security boundary around a workspace, a platform-to-product handover — we scope it jointly and still name one accountable owner rather than pretending there is no overlap. The boundary in full.

No. The standard service is hosted by us and reads technical metadata only — dataset names, schemas, owners, refresh times — through a connection your customer authorises and you can scope. Where it runs in the customer's own Azure subscription, you can operate it: we agree in writing who patches, backs up, monitors and responds, and it can be entirely you. Our own people's logins are flagged as ours, do not consume the customer's seats, and appear in the same audit trail as everyone else.

It is usually the opposite: the product is what your consulting leaves behind. Most governance engagements end with a framework in a document, and the value evaporates over the year that follows because nothing prompts anyone and nothing measures whether it is being followed. Delivering the same thinking into a system that chases owners, records approvals and produces a score gives you a reason to still be in the account next quarter. Where our model and your judgement disagree about a particular customer, take your answer and record it in the product — none of it is locked.

No. It adds nothing to the rows the platform already covers, and it is explicit about that: the capability map shows, per platform, what the cloud covers natively and what still needs a human decision recorded. In practice it scopes platform work rather than replacing it — an owner who cannot be named is usually a conversation about access controls, and a dataset nobody trusts is usually a pipeline job.

Agreed per partnership, in writing, before the first customer goes live. Most partners want first line and to keep the relationship; we take product defects and anything that needs a change to the software. What we will not do is leave it ambiguous — one boundary, one price basis, one documented handover per service, so the customer never has two suppliers each assuming the other has it.

They can ask, and we will tell you. If you introduced them, the account stays registered to you and the referral or reseller position stands whichever way the paperwork goes; we do not treat a direct enquiry as a way out of that. We would rather lose one sale than have a partner conclude we are a risk to their accounts.

Not today. White-labelling and annual partner fees are deferred until repeated use justifies them, and we would rather say that than sell you a roadmap. What exists now is a cross-customer partner view, a populated instance per customer, and the ten-signs scorecard offered under your name as a conversation-starter with past clients.