OUR FRAMEWORKS
The four things we build with
Get the data in. Orchestrate the work. Put agents on it. Prove it’s right.
Every engagement we run is assembled from these four. They exist because we got tired of rebuilding the same four things for every client, and because a framework maintained across twenty projects is better than one written from scratch for each.
They aren’t products you license. They’re the reason our third month looks like most vendors’ ninth.
Layer 1 — Ingest
Connect a source once. Stop writing the same connector twice.
A configuration-driven ingestion framework. You declare a source and get a tested pipeline: incremental loading, schema drift handling, retries, quality assertions at the boundary, and lineage — without anyone writing bespoke Python for the fortieth REST API this year.
Declarative, not bespoke. A source is a config file, not a codebase. New sources land in days rather than sprints.
Schema drift is handled, not discovered. Added, removed, and retyped columns are detected, versioned, and alerted, rather than silently breaking a dashboard three weeks later.
Incremental by default. CDC and watermark strategies are built in. Full reloads become a deliberate choice instead of the only thing that works.
Quality checks at the boundary. Freshness, row volume, null rate, and uniqueness assertions run on arrival, so bad data fails loudly at the edge instead of quietly downstream.
Lineage without a separate project. Every model traces back to a source, a load, and a timestamp.
Apache Airflow · dbt · Snowflake, Databricks or BigQuery · Python · your cloud
It isn’t a reverse-ETL tool, and it isn’t a replacement for a managed connector that already works. Where a vendor connector is cheaper than maintaining our own, we use the vendor connector and say so. Conduit exists for the sources nobody has built a good connector for — which, in most enterprises, is most of them.
Your cloud · your data · your permission model
Layer 2 — Orchestrate
Agents you can audit, retry, and explain.
Most agent frameworks run a reasoning loop. The model decides to call a tool, gets a result, calls another, accumulates context, and eventually answers. From outside, none of that is visible. When it fails you get a failed run and a transcript, and when one call in twelve breaks, the whole thing starts over.
Junction builds agentic workloads as Airflow DAGs instead. Every model call is a named task with its own log, its own retry counter, and its own recorded input and output. The Airflow project makes this argument better than we could, and we link their writeup rather than paraphrasing it.
Every step is a task. Parallel model calls appear in the UI as individually named instances, each with its own log and retry state — the same information an agent harness has internally, surfaced as first-class artifacts.
Partial failure doesn’t restart the run. When one branch of a fan-out fails, that branch retries alone. Completed results are preserved rather than discarded.
Human approval is a step, not a wrapper. Review gates live inside the workflow, so a person can inspect, edit, and approve before the run continues.
“Why did it answer that?” has an answer. The exact input a model received and the exact output it produced are both stored and queryable after the fact.
It runs where your pipelines already run. Same scheduler, same connections, same RBAC, same on-call rotation. No second orchestration system to operate.
Apache Airflow 3 (`common.ai` provider) · OpenAI, Anthropic, Vertex AI or Bedrock · your existing Airflow deployment
Airflow DAGs are acyclic. An unbounded critic-to-generator feedback loop, where a reviewer step sends work back until quality clears a bar, has to be wired as explicit branching at authoring time. That acyclicity is what buys you the auditability, and it’s a real tradeoff. If your problem genuinely needs open-ended iteration, we’ll tell you and reach for an agent harness instead.
Apache Airflow, Airflow, the Airflow logo, Apache, and the Apache feather logo are trademarks of The Apache Software Foundation. DataBridgeCrux is not affiliated with, endorsed by, or sponsored by the ASF.
Layer 3 — Apply
Agents that do the document work, with a human in the loop and a trail behind them.
A large share of back-office work is reading documents, pulling facts out of them, checking those facts against another system, and escalating the exceptions. High-volume, rules-heavy, and almost entirely invisible until it goes wrong.
Crew workers do that work. Each one is scoped to a single process, cites the document and page behind every claim, stops and asks a person at the points where being wrong is expensive, and leaves a record that satisfies an auditor.
Human checkpoints where they matter. Workers flag, hand off, and wait rather than guessing. You decide which decisions require a person; the worker enforces it.
No claim without a citation. Every output links to the source document and location it came from. Unsupported assertions are a failure condition, not a stylistic preference.
It sees what the person sees. A worker operates inside your existing permission model, resolved per user. It cannot surface a document the requester couldn’t open themselves.
Audit-ready by construction. Who asked, what the worker read, what it produced, who approved, and when — captured as the run happens, not reconstructed later.
Custom workers for your actual process. The pre-built types cover recurring shapes. The interesting ones are assembled from how your team already works, which is the part a generic tool can’t do.
Junction for orchestration · Conduit for system access · your document stores and line-of-business applications
Workers don’t take irreversible actions without approval, and they don’t replace a reviewer on high-stakes judgment. If a process has no tolerable error rate, a worker is the wrong tool and we’ll say so on the first call. We also won’t build one on a corpus whose access permissions are undocumented or disputed — the worker will faithfully reproduce whatever is wrong with your access model.
Layer 4 — Prove
Know when your AI gets worse. Before your users tell you.
Every enterprise AI rollout stalls on the same question, and it’s a fair one: how do we know it’s right, and how will we know when it stops being right?
Assay is the layer that answers it. A golden dataset built before the system is, automated evaluation in your pipeline, regression gates that block a deploy when scores drop, drift monitoring after release, and one export that risk, audit, and legal will actually accept.
“Working” gets defined numerically before anything is built. The evaluation set is the first deliverable of an AI engagement, not a retrofit in month four.
Regression gates in your pipeline. A prompt edit, model swap, or retrieval change that lowers scores fails the build. This is the control that stops quiet degradation.
Drift detection in production. Quality decays as your data and users change. This is what makes that decay loud instead of gradual.
Cost and latency as tracked budgets. Both treated as monitored metrics with thresholds and alerts, not as a surprise in the month-three invoice.
Adversarial suites on a schedule. Prompt injection, data leakage, permission bypass, and off-policy output, tested continuously rather than once at launch.
One export for the people who ask hard questions. Evidence assembled in the format risk and audit teams work in.
Junction · your CI system · open-source eval libraries · your observability stack
It doesn’t make a bad system good. It tells you, early and specifically, that it’s bad — which is cheaper than finding out from a customer, and considerably cheaper than finding out from a regulator.
HOW THE FOUR FIT TOGETHER
Useful alone. Better stacked.
Most engagements don’t start at layer one. A client with a working warehouse and a stalled GenAI pilot starts at Assay, because the first job is finding out whether the pilot works at all. A client with clean data and forty disconnected spreadsheets starts at Crew.
What the stack buys you is that the layers were built to sit on each other. Crew runs on Junction, which reads data through Conduit, and all of it reports into Assay. Nothing between them is glue code written under deadline by whoever was available.
We’ll tell you which layer your problem actually lives in. It’s frequently not the one you called about.
WHAT YOU OWN
You keep all of it.
Source code, configuration, documentation, and runbooks are yours at the end of the engagement, along with the right to run and modify everything we built. There’s no licence, no seat count, and nothing that stops working if you stop paying us.
These four exist to make your project start from something proven rather than from an empty repository. They are not a lock-in mechanism, and a site full of honest patterns would be a strange place to hide one.
If you’d rather stand one of these up with your own team and just want help getting it right, that’s a conversation we’re happy to have.
FAQ
Questions, answered.
Isn’t Junction just Airflow DAGs? +
Yes, and that’s the pitch. Standard tooling your team already runs, no proprietary runtime, no second orchestration system to operate, and nothing to rip out when we leave. A framework whose main feature is that it isn’t exotic tends to survive longer than one that is.
Can we use one without the others? +
Yes. They share conventions, not dependencies. Most clients start with one.
What happens to these if we stop working with you? +
Nothing. You have the source and the documentation. You’ll stop getting our upstream improvements, which is a real cost and worth weighing, but everything you’re running keeps running.
LET’S TALK
Tell us what’s stuck.
Most of our engagements start with a 30-minute call where we listen more than we pitch. If we’re not the right fit, we’ll say so and point you somewhere better.