A successful scan is a real test
The most common way integration projects lose their first fortnight is discovering, late, that the service account cannot read the table everyone assumed it could.
· SetMeld
The first two weeks
Ask anyone who has run an enterprise integration project where the schedule went, and a surprising amount of it went to connectivity: a firewall rule that needed a change request, a service account with read access to eleven of twelve schemas, credentials that worked from a laptop and not from the server. None of it is intellectually difficult and all of it is slow, because each discovery happens weeks after the assumption that caused it.
Why the scan matters
When SetMeld Composer connects to a source, it scans it and extracts an AI context: a structured description of every entity, field and datatype, enriched with inferred meaning. That description is what the design stage reasons over. But the scan does something else that is arguably more valuable. It exercises the same access paths that SetMeld SetMeld Pipeline will later use to extract data.
A green scan is therefore a proper end-to-end test. It says: these credentials, from this network position, can read these objects. Not “the connection string parses”. Not “we could reach the host”. The actual read path, proven before anybody designs a transformation on top of it.
When a connection fails
The other half is what happens when it does not work. A connection failure that returns a driver stack trace is a support ticket. SetMeld Composer’s assistant diagnoses the problem and coaches the administrator through resolving it, distinguishing a network restriction from a permissions gap from a misconfigured credential, because those three failures look similar and have entirely different owners.
Why this matters
Anywhere a system can verify an assumption cheaply and early, it should, and it should tell you in the language of the person who has to fix it. Most of the difference between an integration that takes days and one that takes quarters comes down to how quickly the boring problems surface.
Unified knowledge graph vs. siloed data sets: how far do you need to go to get your data AI ready?
Twenty questions, five versions of the same bank, six runs each. The largest single jump in accuracy did not come from a year of data engineering. It came from writing down what a few people already knew.
Your AI agents are going to be wrong until you build a knowledge graph
Everyone can describe the destination, and everyone can list vendors. The stretch of road in between is the part almost nobody in leadership can name, and it is where I keep watching smart companies stall.
See it run against your own systems
Two databases and a question they cannot answer together is enough to start.