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, surfaced to your product as bounded, observable states, each carried with a confidence value. The underlying model is proprietary; buyers receive its full documentation in the methodology manifest under NDA.
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.
We validate rather than assert, and we publish the results that go against us.
Four pre-registered studies have been run across e-commerce, retail and education. Design and thresholds were frozen before any outcome was joined, each run carries a permutation benchmark, and passing effects are shrunk for winner's curse against a family-wise bar. One returned a clear signal. One replicated the direction but landed below our own practical floor. Two returned nulls, one of them because a strong baseline left no headroom to measure.
We report that split deliberately, because a method you can trust is one you can watch fail. The full record, with effect sizes and caveats, is available on request.
What none of that entitles us to claim is your vertical. So deployment in a new vertical runs as a paid design partnership: we scope the outcome with you, freeze the protocol before anything is measured, and validate against your own history before go-live, and you receive that report whichever way it comes out. That run, not a borrowed benchmark, is the evidence your decision should rest on.
It does not read emotion. The dimension named emotional control measures behavioural regularity, such as activity timing and pacing. It does not infer feelings, and it must not be used to.
It does not produce a label or a personality type. It produces continuous, bounded scores, each carried with its own confidence, and the confidence is part of the reading.
It does not know what it has not seen. A dimension with no supporting evidence returns the midpoint with a low confidence value. Read the confidence, not just the score.
Its confidence reflects how much evidence it has, not how diagnostic that evidence is. A highly active user produces a confident reading; that is a statement about volume, not about certainty.
It has not been validated in your vertical. It has been validated in ours, and the result was mixed on purpose: see the record above.
It is not a basis for hiring, credit, insurance, education admission or clinical diagnosis, and never for an automated decision about a person without a human who can overrule it and an explanation of why the score says what it says. Every inference carries the rule that produced it, so that explanation always exists.
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 provisioning, and stated in your engagement terms. | Existing products and platforms |
| Hosted API | A shared multi-tenant endpoint. | On the roadmap. Not offered today; a dedicated instance is what we provision. |
Behavioural data is sensitive by nature, so we will be precise about what isolation you actually get.
A dedicated instance is provisioned per client: your own engine process and your own database, so your data is not stored alongside another client's. We provision it at the start of delivery, and the isolation boundary is written into your engagement terms.
IBI's own products currently run on a shared internal instance, separated by scoped credentials rather than by separate databases. That is our own data, not a client's, and it is not the shape we deploy for you. We would rather tell you that than let you infer otherwise from a diagram.
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, consent-gated)
If your product has conversational surfaces (support chat, advisory sessions), a transcript route can feed them to the engine's language layer. People are registered automatically on first contact; there is no per-user provisioning. Because this layer processes conversation content, it ships disabled by default and is only switched on after an explicit consent design agreed in the data-protection phase. Most deployments do not need it: the model scores from structured events alone.
3 · State reads
Wherever your product should adapt to the person, one authenticated GET returns their current behavioural 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.
Validation run
Before anything is called decision-grade, we run a pre-registered validation on your own backfilled history: the outcome you care about, a cutoff date, your own ordinary bookkeeping as the baseline to beat, and thresholds, all frozen in writing before results exist. You receive the report either way. A measured lift is the switch-on evidence; an honest null costs you nothing further and is told to you straight.
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.