Before an intent system tells you what it can predict, ask what it is permitted to collect.
That question belongs at the start of a product discussion. It determines which explanations the business can defend, which consent it needs, and what happens when an attractive source of data falls outside the rules.
For MIZ OKI, the boundary is part of the design.
ORACLE, our anticipatory intent surface, and the Anticipatory Intent Engine v2 remain Preview · in development. Their current posture is observation and shadow evaluation. A forecast does not carry permission to change traffic or spend.
The design works with limited signals from a consented session: changes in viewport movement, attention to coarse page regions, tab hide and return events, and content-free form lifecycle events. Form started and form abandoned describe an interaction without collecting what a person typed.
These signals are imperfect behavioral proxies. A pause can mean interest, distraction, confusion, or a slow connection. Treating it as certainty about a person's motivation would give the observation more meaning than it supports.
The intended output is an expiring hypothesis with uncertainty and an explanation path. It must remain separate from a sensitive personal profile.
The exclusions are equally concrete. Keystroke dynamics, raw keys, entered text, typing cadence, and typing fingerprints are prohibited inputs. So are microphone or audio-derived signals, gaze, biometrics, fine individual location, and sensitive-trait inference. Coarse, allowlisted form events cannot become a route for collecting sensitive field content.
The O-1 keystroke prohibition is an ingestion rule. In Act 2 of the Media demo, press “Send keystroke-dynamics payload.” The demonstration displays the rejection reason DISALLOWED_KEYSTROKE_DYNAMICS.
That button illustrates the contract. It is not a penetration test or proof that every possible deployment has been audited. The underlying collection, retention, and deletion controls still need to be verified for the connected environment.
Expiry belongs in that verification. Session evidence should have a defined life. Hypotheses need a stated expiry. Deletion needs a checked path through the stores that actually received the data. A retention promise is useful only when the operating behavior matches it.
There is a second boundary after collection: the boundary between predicting an outcome and causing a better one.
A model might identify a session with a higher chance of purchase. That does not establish that a different message, discount, or ad would help. The intervention could add nothing. It could consume margin or make the experience worse.
The governing sequence is straightforward. Signals can propose an idea. A suitable experiment must qualify the claimed incremental effect. Policy and named authority determine whether an action may proceed.
That leaves room for useful anticipation while keeping the purchase forecast from marking its own homework.
I want a customer to be able to explain our system without quietly skipping a sentence about its data. Clear limits make that conversation possible. They also give operators a definite answer when a proposed shortcut crosses the boundary.
Try the privacy demonstration in Act 2, then read the Intent product page.