Deploying Lens into your system
How the Lens behavioural engine attaches to your product, platform, or CRM. Written for the technical owner on your side. At the end you will know what ships, what we need, and how long each phase takes.
01 What Lens is
Lens is a behavioural inference engine. Your system sends it small, factual events: this person logged in, viewed an asset, completed a session, made a decision. Lens accumulates that evidence over time and maintains a live behavioural state per person across six dimensions, with a confidence value attached to every score.
Your product reads that state back through one API call and adapts: what it surfaces, how it communicates, when it intervenes.
Lens runs today inside IBI's own products. Those deployments are the reference implementations for everything described below.
02 Deployment models
| Model | What it means | Best for |
|---|---|---|
| Built in | IBI builds your system (booking platform, CRM, client portal) with Lens instrumented from day one. Nothing to integrate. | New builds, replatforming off rented SaaS |
| Dedicated instance | A Lens instance provisioned for you alone, attached to your existing system through the integration surface below. Your instance, your data, isolated by construction. | Existing products and platforms |
| Hosted API | A shared multi-tenant endpoint. | On the roadmap. Not offered today; dedicated instances are the current standard. |
Behavioural data is sensitive by nature. One instance per client means your data is never pooled with anyone else's, and the isolation is architectural rather than a policy promise.
03 The integration surface
Three touchpoints. All of them are one HTTP call; all of them fail soft, so Lens being unreachable can never slow or break your product.
1 · The event emitter
A small module dropped into your codebase at the points where behaviour happens. Fire-and-forget, sub-second timeout, never throws into your request path.
// the entire integration, per event
emit(userId, 'decision', { assetId, price }); // one line at each call site
// -> POST https://lens.yourinstance/v1/events (authenticated, ~ms, fail-soft)Which of your events matter, and what they signal, is decided in the sensor-mapping workshop (section 04) and shipped as versioned configuration on your instance. Adding an event type later is a config change, not an engineering project.
2 · Conversation analysis (optional)
If your product has conversational surfaces (support chat, advisory sessions), a transcript route feeds them to the engine's language layer. People are registered automatically on first contact; there is no per-user provisioning.
3 · State reads
Wherever your product should adapt to the person, one authenticated GET returns their current six-dimension state. Reads are fast (low milliseconds) and fail soft with a neutral default, so your product degrades gracefully, never visibly.
04 The delivery process
Sensor-mapping workshop
Half a day with your team. We map which of your events carry behavioural signal and what each one means. The output is your sensor pack: versioned configuration, the single artifact that makes Lens fit your system's shape.
Provision and instrument
Your dedicated instance is provisioned; the emitter goes into your codebase at the mapped call sites. Days of work, not months. Your engineers or ours.
Calibration window
Roughly 30 days of live data while the engine's weights are tuned to your cohort. You get the behavioural dashboard from day one; scores are labelled calibrating until the window closes. We do not skip this step, and we do not claim decision-grade intelligence during it.
Switch on
State reads go live in your product. From here the engine's evidence accumulates continuously, and the sensor pack evolves as your product does.
05 Your data
- Isolation. Dedicated instance, dedicated database. Your behavioural data is never pooled, benchmarked, or shared across clients.
- Ownership. The data is yours. Offboarding hands you a complete export and the instance is destroyed.
- UK GDPR. Deployments that touch personal data include a data-protection design phase before go-live: lawful basis, retention, processor terms, and subprocessor disclosure, agreed in writing.
Products in regulated or sensitive settings (health, therapy, finance) carry additional consent design work before any behavioural processing goes live. We will scope this honestly in the first conversation rather than discover it in delivery.
06 Historical backfill
Lens is event-sourced and every event carries its own timestamp, so your history can be loaded as history. Give us an export of your existing activity data and the engine scores your customer base across its real timeline, before the first week of live traffic.
- Day-one value: see the shape of your existing base immediately, not in month two.
- Faster calibration: your history already contains the outcomes the tuning needs.
- Trajectories, not snapshots: state can be computed as of any past date.
A backfilled picture is only as complete as what your system logged. Every backfill report includes a coverage statement: which dimensions had real evidence in your history and which did not.
07 What we need from you
- A technical contact who knows where behaviour happens in your codebase.
- An inventory of your event-shaped data (analytics events, audit logs, activity tables).
- For backfill: an export of historical activity, any format with timestamps.
- For personal data: your DPO or whoever owns privacy, in the room early.
- A staging environment where the emitter can be exercised before production.
Start the conversation: hello@ibitechnologies.co.uk or book an intro call.