bearingbridge intelligence

No, and in most builds nothing moves at all. SL01 reads accounts and contacts from your CRM through its API and writes back into the same fields, so your CRM stays the system of record for customers. Your ERP stays the system of record for orders. DB09 reads both and reports the rows where they disagree rather than picking a winner. The one thing that does move is definitions: DB02 holds them in one place instead of three.

IT01 through IT05 or DB01 through DB04, for the same reason in both cases: you already have the baseline. Your ticket history tells you what a password reset, a VPN failure, and a software install cost you today, so the before and after are not arguable. Dashboarding works for the opposite reason, because the assessment usually produces a finding worth having on its own. Start with one, not four.

You get it in writing before anything is built. A typical finding: three systems each hold a field called active customer, one of them counts trial accounts, one excludes anyone churned in the last ninety days, and the board pack has been silently using whichever ran first. DB02 surfaces that during the assessment. If the fix is large, a data foundation is quoted as its own piece of work and the module waits. A module on top of that mess would not fix it, it would publish it faster.

For one action, the prompt and the specific records or passages that action needs go to the routed model provider. Nothing else. We do not train on your data, and no other client can see your tenant. Provider retention settings form part of the routing decision and are documented per model in the handover, so you can read exactly which provider saw what. Where residency rules require a model to run inside a given jurisdiction, that constrains the routing table rather than starting a negotiation.

You do, and the handover is specific: source in your repository, documentation in your wiki, the database in your cloud account if you want it there, environment variables and credentials held by your team. Handover readiness is a deliverable with a date on it, not a concession at the end of a contract.

Tokens are bought in advance as a credit, so nothing can bill after the fact. Every action prints its price on screen while it runs. Each person carries a daily cap and the organization a monthly one, and at the cap generation stops while reading and dashboards keep working. The ledger row for every action records the person, the timestamp, the module ID, the model routed to, the tokens consumed, the cost, and the approver if there was one. That row is exportable, which is usually the thing finance actually asks for.

Both, and the list is written down per module. Under IT05 a typical client allows a password reset and a license reassignment unattended, and requires a human for anything that grants membership of an admin group. Under CS02 the draft is generated automatically and the send is a person. Under CS14 an outbound message to a customer about a late delivery needs approval on the first fifty, then the client usually decides whether to relax it. That list is reviewed, not set once.

Whichever benchmarks best for the specific task and is permitted where you operate. We route across Western and Chinese providers, GPT, Claude, Gemini and Llama on one side, Qwen, DeepSeek, GLM, Kimi, Doubao and ERNIE on the other. Routing is per task, not per client: ticket classification goes to a small cheap model because the job is a label, contract term extraction goes to a stronger one because a wrong date is expensive. The table is documented and re-benchmarked quarterly.

Usually, and you get a date rather than a roadmap slide. A documented REST or GraphQL API is typically days. An older SOAP interface or a direct read replica of an on-premise database is typically one to two weeks. A flat-file exchange over SFTP is the fallback when a system has no interface worth using, and it works. Where the only route in would be driving a legacy desktop client through its screens, we will tell you that is fragile and quote it as fragile, or decline it.

We build it, and it costs more, because none of the skeleton is reusable and the whole thing is implementation. The sequence does not change: assessment, working version on your data, hardening, handover. In practice about a third of what clients ask for turns out to be an existing module with different rules, which is a tailoring conversation rather than a new build, and the assessment is where that gets settled.