Preference Architecture Trade-offs Teams Actually Debate

Consent logs. Most teams treat them as an afterthought—a compliance checkbox buried in a settings page nobody visits. But if you're doing preference architecture right, those logs are a live surface. They record what a person actually agreed to, when, and under what conditions. That's not just paperwork; it's a chance to rebuild trust. In practice, the process breaks when speed wins over documentation: however small the change looks, the pitfall is that the next person inherits an invisible assumption, and the fix takes longer than the original task would have.

Claim desks that separate intake verbs from appeal verbs stop copy-paste denials from looking like thoughtful casework, and auditors notice the verb drift long before anyone rewrites the policy memo.

According to practitioners we interviewed, the trade-off is rarely about talent — it's about handoffs, and however confident you feel after the first pass, the pitfall shows up when someone else repeats your shortcut without the same context.

According to practitioners we interviewed, the trade-off is rarely about talent — it's about handoffs, and however confident you feel after the first pass, the pitfall shows up when someone else repeats your shortcut without the same context.

This field guide is for product folks who are tired of cookie banners and consent popups that annoy everyone. We'll walk through where consent logs matter, what people get wrong about them, and how to design them so they're actually useful. No fluff, just practical notes from the trenches. Watershed crews who keep phenology notes beside camera-trap cards treat absence as a process signal, not a missing checkbox, and that habit alone keeps seasonal reports from reading like cloned templates under review.

Where Consent Logs Actually Show Up in Real Work

Onboarding flows and settings dashboards

The first place consent logs bite is right where users meet your product.

Fix this part first.

A new signup clicks through three screens of permissions—then six months later, they're digging through settings to undo something they never understood. That's a design failure, not a legal one. Your log is the only record of what they actually agreed to, and if it's buried in a database dump nobody reads, you've built a promise you can't keep.

I have seen onboarding flows where the log captures everything except the moment that matters: the exact toggle state when someone clicked "Save." Wrong order. The audit trail shows the pre-click state instead of the post-click commitment. Fixing that takes one afternoon of engineering, but most teams discover it during a DSAR—when a user asks exactly what they agreed to, and your answer doesn't match their memory.

Settings dashboards are worse. You'll render a list of "active permissions" derived from the latest log entry, but that's a snapshot, not a history. Consent changes over time—revoked, renewed, expired—and your UI needs to show the timeline, not just the current state. The trade-off is complexity: a simple switch becomes a small state machine. Most products punt, showing only today's status. That works until a user complains they never agreed to something you can't disprove.

What usually breaks first is the link between the log and the interface. The log says "opted in," the dashboard says "opted out," and nobody knows which one is authoritative. The fix isn't more logging—it's making the log the single source of truth that every UI reads from.

Data subject access requests (DSARs)

DSARs are where consent logs stop being abstract. A user writes in: "What data do you have on me, and where did you get it?" You have thirty days in most jurisdictions. If your log is scattered across four services with inconsistent timestamps, you'll burn a week just assembling a coherent answer.

The catch is that DSARs expose every shortcut you took. That consent checkbox you prefilled? The log shows the user never actually clicked—you recorded consent for them. That dark-pattern "agree by scrolling" implementation? The log shows a timestamp with zero interaction detail. These are design decisions dressed as legal ones, and they surface exactly when an angry user goes digging.

Most teams skip this: you can treat DSAR responses as a product surface, not just a compliance chore. A well-formatted response—timeline of consent events, clear language, source attribution—turns a hostile interaction into a trust repair. I have built responses that read like a receipt, and users closed tickets with "thanks, that's what I thought." That's the quiet win.

But here's a pitfall: over-engineering the response. You don't need a beautiful PDF portal for a request that arrives once a month. Start with a plain-text dump your support team can paste into an email. Perfect is the enemy of compliant.

Audit readiness and internal reviews

Audits are the third place consent logs show up, and they're the least glamorous. A reviewer asks for "all consent events for user 4821 over the last year," and you realize your log rotates entries every ninety days to save storage. That's a policy choice that looks fine in a sprint planning meeting—until it's a finding in a report.

The design problem here is foresight. Your log schema needs to anticipate questions you haven't been asked yet: which version of the privacy policy was active when consent was given? What did the user see on screen at that moment? Most logs store the timestamp and the action, but not the context. That context is what auditors needle at, and retrofitting it later is brutal.

Internal reviews are sneakier. Your legal team wants to delete data when consent is withdrawn; your product team wants to keep it for analytics. The log is the only arbiter. If it doesn't record when withdrawal happened relative to data processing batches, you have a gap. I have watched teams spend two weeks arguing about whether an export was "before or after" a revoke event—entirely because the log didn't include a processing run ID.

Not every audit needs military-grade detail. But the log should answer three questions without manual digging: who consented, when, and under what terms.

One more thought—consent logs are rarely a single table in one database. They leak into email receipts, support tickets, and analytics events. Consolidate them, or you'll be piecing together stories from fragments. That's not elegance; it's survival.

What Consent Logs Are Not: Clearing Up Confusion

Logs vs. Preference Stores

A consent log is not a settings page, though teams often treat them as the same thing. A preference store is the current state — “Alex opted into analytics on March 4th.” A consent log is the stream of decisions, corrections, and revocations that produced that state. The store answers what now. The log answers how we got here. You need both, but they fail in different ways.

Most teams skip this distinction until the auditors show up. The preference store gets wiped during a migration, someone re-consents, and now you have a legal record that says Alex agreed twice — once under a stale policy version. The log is what saves you. Without it, you can't prove which policy text was live when the consent happened. That's not a compliance nuance; that's a lawsuit shaped hole in your record.

One concrete sign you're conflating them: you can overwrite an entry. Logs are append-only. If a design lets you edit or delete a consent record, you've built a preference store wearing a frock coat. Wrong tool for the job. And when a user withdraws consent, the log must show the withdrawal as its own event, not an edit to the original. Otherwise you're rewriting history and handing your legal team a smoking gun wrapped in good intentions.

Flag this for email: shortcuts cost a day.

The Difference Between Consent and Purpose

Consent is permission. Purpose is the reason you're asking for it. They're not interchangeable, and the log needs to capture both, separately, every single time.

Here's the trap: you log “user agreed to data processing” and call it a day. But processing for marketing vs. processing for security vs. processing for product improvement are three different purposes with different legal bases. A single vague entry means you can't distinguish “the user said yes to ads” from “the user said yes to crash reporting.” That ambiguity gets expensive in a privacy review.

“The log entry should read like a sentence: who, what, when, why, and under which rules.”

— privacy engineer, after untangling a rejected data subject request

I have seen products where the log stored a payload of “opt-in = true” and nothing else. When a user demanded to know why their data was used, the team had to trace through six other systems to reconstruct intent. Six weeks of manual work. Purpose isn't a nice-to-have field; it's the spine of the entire record. Without it, you're logging noise.

Why Timestamps Matter More Than You Think

A timestamp without a timezone is a guess with a calendar attached. UTC or bust — but that's only the start. The harder problem is causality between your systems and the user's local clock.

Say a user revokes consent at 11:58 PM their time, but your server logs the event at 04:58 UTC the next day. If your retention job runs at midnight UTC, you might delete their data a day early or a day late. The legal timeline doesn't care about your cron schedule. The tricky bit is correlating client-side timestamps with server-side ones, especially across DST boundaries. Most teams don't test for a user in Auckland who revokes during the company's backup window. That's when the seam blows out.

So what do you do with those timestamps? Sort them religiously. One log entry with an out-of-order timestamp breaks every downstream audit trail. You can't just store events; you have to store them in a way that resists clock drift and out-of-order arrivals. Add monotonic counters, use NTP, reconcile aggressively. It's unglamorous work, but it's the difference between a log you can defend and a log you cross your fingers about. And it lets you answer the only question that matters when someone disputes a record: “What did this user see, and when did they see it?”

Patterns That Usually Work

Time-stamped, plain-language entries

The most durable consent logs read like a short chat history with your product, not a legal deposition. Each entry should say what changed, when it changed, and why in words a non-lawyer actually uses. “You allowed location access for map routing” beats “GPS_DATA_PERMISSION_GRANTED_v2” every time. Add a human-readable timestamp — “May 12, 9:41 AM” — rather than an ISO string. That sounds trivial until you watch someone scroll back three months trying to figure out why their notifications stopped.

The prompt isn’t just decoration. We once shipped a log entry that said “We updated your privacy settings” — technically accurate, completely useless. People don’t want to know that something happened; they want to know what it means for them. One client rewrote every entry to start with the user’s action (“You turned off…”) rather than the system’s (“System applied…”). Support tickets about privacy dropped by a third. Not a scientific study, just a pattern we keep seeing.

The catch is verbosity. Long sentences in logs become wallpaper — nobody reads a paragraph per entry. Keep each line under twenty words if you can. Use short fragments for status changes: “Location: Off.” “Camera: On, one-time.” That works because the context carries the weight.

Layered summary plus detail view

A flat list of every consent event is the fastest way to make people ignore all of them. Instead, show a summary first: “You’ve granted 3 permissions in the last 30 days.” Then let them expand into the full timeline. This isn’t fancy — it’s the same pattern your inbox uses.

Most teams skip this. They assume users want full transparency at all times, so they dump fifty rows on screen. What actually happens is overload, then scrolled-past, then forgotten. The layered approach respects attention. Default to a digest view; make the raw history one click away. That single click is the difference between a log that gets consulted and a log that gets screenshotted and ignored.

One trade-off: summaries are opinions. You’re deciding what counts as important. If you hide a surprising change behind a “view details” link, you’ll get blamed for burying bad news. Rule of thumb — surface anything that revokes or grants access unexpectedly. Routine logins can stay tucked.

Proximity to the settings they describe

A consent log buried under “Privacy → Advanced → Legal” might as well not exist. Put entries near the controls they relate to. Toggle for location? The log entry for that toggle should sit inches below it, not in another tab.

The trick is treating the log as part of the setting, not a separate feature. We rebuilt one dashboard this way: each permission row got a small “history” chevron. Users could see the last change without navigating anywhere. Engagement with the log tripled — though that number came from our own instrumentation, so take it with salt.

Proximity also helps debugging. If someone insists “I never allowed this,” you can point to the exact toggle and its timestamp in the same view. That’s not about shaming users; it’s about closing the loop on trust.

Consent logs work when they’re furniture, not archives. You notice them only when something moves — and that’s exactly when you should.

— pattern note, from a designer who rebuilt three consent screens

What usually breaks first is the link between the log and the live setting. They drift apart during development; the log shows old values, the toggle shows new ones. Fix that with a shared data source, not copy-paste. Honestly, that alone prevents more confusion than any formatting choice.

Anti-Patterns and Why Teams Revert to Popups

Hidden or Vague Log Entries

The first time a consent log fails, it's usually because nobody can figure out what the entries mean. You open the panel, and there it's: "Consent updated" with a timestamp and nothing else. Updated how? By whom? For which purpose? That sounds fine until a user asks, and you have no answer. The log becomes a shrug with extra steps.

Most teams skip this part: they treat the log as a database table, not a communication channel. But the user who opens that panel isn't querying your schema—they're auditing your behavior. If the entry says "preferences modified" but doesn't say what changed, you've turned transparency into a locked drawer. The fix is boring but essential: log the delta, not the state. "Analytics turned off" beats "preferences updated" every single time.

I have watched teams ship this exact flaw and then wonder why retention dips. The log isn't the problem; the opacity is. You don't need perfect prose—just enough to answer the one question a person actually has: what did I agree to, and can I take it back?

Logs That Read Like Legalese

Then there's the opposite failure: entries so dense with conditional clauses that they might as well be boilerplate. "We may process your data for the purposes of service improvement, including but not limited to analytics, subject to your prior opt-in and applicable law." Nobody reads that. They skim, they shrug, and they close the panel—or worse, they never open it again.

The catch is that legal teams push for completeness, and engineers comply because it's easier than arguing. But a consent log isn't a contract; it's a receipt. Receipts don't restate the entire terms of sale. They say "two shirts, forty dollars." Your log should say "location data shared with map providers" and stop there. If you need the full legal text, link to it—don't embed it.

Flag this for email: shortcuts cost a day.

That said, brevity has its own trap. Strip too much, and the log becomes meaningless. "We used your data." For what? The sweet spot is one short sentence per purpose, written in plain language a twelve-year-old could repeat. If you can't explain the change in under fifteen words, you probably haven't decided what the change actually is.

Using Logs to Obscure Rather Than Inform

Some teams weaponize the log without realizing it. They bury the revoke button at the bottom of a five-hundred-entry history, or they label everything "adjustments" so nothing stands out. The intent isn't malicious—it's usually to reduce support tickets. But the effect is the same: you've built a maze and called it transparency.

Here's where teams revert to popups. Users get frustrated, they can't find what they need, so they ignore the log entirely. And when you can't rely on the log, you fall back on interruptive prompts—the very thing you were trying to avoid.

Obscurity is a debt. You pay it back in user distrust, one unanswered question at a time.

— field observation, consent UX review

The fix is to design for the angry user, not the compliant one. Put the most recent change at the top. Highlight anything active. Make the revoke action visible without scrolling. It's not about making everything easy—some friction is honest—but the log should never be harder to read than the popup it replaced.

What Usually Breaks First

In practice, the drift starts small. A product manager asks for a "minor" wording tweak. A developer adds a field without updating the display template. Six months later, the log shows a mix of old and new formats, and users can't tell whether an entry is current or stale. That's when support requests spike, and someone resurrects the modal.

Another common misstep: logging only successful changes, not attempts. If a user tries to revoke but hits a validation error, that's not logged. So they retry, fail again, and conclude the system is broken. A log that shows intent—even failed intent—would reveal the bug. But most teams only record the happy path, which leaves the log looking clean while the experience is rotting.

The deeper pattern is structural: consent logs fail when they're treated as a compliance artifact rather than a product surface. A popup asks for one decision at a moment of focus. A log asks for ongoing trust with zero attention. That's a harder design problem, and it doesn't solve itself with a database migration.

So before you scrap the log and slap up another modal, ask: is the log bad, or is the implementation lazy? If entries are vague, make them specific. If they're legalistic, rewrite them. If they're hiding something, surface it. Popups feel safer because they're familiar—but they're also why you started looking at logs in the first place. Don't revert; revise.

Maintenance, Drift, and Long-Term Costs

Keeping Logs Accurate as Purposes Change

Consent logs rot the moment you stop feeding them. A purpose label like "marketing analytics" means nothing six months later when your team quietly starts using that data for ad personalization. I've watched product managers update a privacy policy while the logs still display the old wording. That gap isn't a nuisance—it's a legal liability wearing a UX costume.

You need a change process that touches the log schema whenever a purpose shifts. Small teams often treat this as a one-time migration, but purposes evolve quarterly, sometimes faster. Define a flag for "superseded" rather than deleting old entries; users who consented under the previous framing deserve to see what they actually agreed to, not a cleaned-up rewrite.

The catch is that most consent infrastructure treats logging as an afterthought. Your CRM exports, your analytics pipeline, your data warehouse—each has its own idea of what a purpose means. We fixed this by adding a shared purpose registry with version numbers, so a log entry always references "purpose_12_v2" instead of a free-text string. Ugly, but honest.

UI Drift: Logs That Don't Match the Current Interface

Logs drift from the interface faster than you'd expect. A toggle gets removed from settings, a new checkbox appears on signup, or the wording changes from "share with partners" to "share with trusted partners." Every tweak widens the seam between what users think they control and what the log records.

That seam blows out in audits. Regulators or privacy advocates pull a user's record and compare it against the live product; mismatches read as deception, even when nobody intended harm. One team I consulted had 14 unused consent options in their database—dead buttons from a redesign nobody cleaned up.

Schedule a monthly diff: crawl your current UI, extract every consent control, and compare it against your log schema. Missing entries are red flags. Orphaned entries are technical debt you'll pay interest on during the next privacy review. Wrong order, too—your log should reflect the sequence of user actions, not the order developers defined them.

Every consent log is a promise written in production data. Once the UI moves on, that promise either gets honored by maintenance or silently broken by drift.

— preference architect, post-incident review

Storage and Retention Trade-Offs

Keeping everything forever is tempting and cheap until it isn't. Storage costs grow slowly, but the real price is subpoena readiness. If a log says a user opted out but your retention policy deleted that record after 36 months, you'll spend days reconstructing evidence. Conversely, retaining every micro-interaction creates a honeypot for hackers and a headache for deletion requests.

Most teams land on tiered retention: active consents kept indefinitely, historical records retained for a legally defined window, and raw interaction events purged after a year. That said, I've seen smarter approaches—anonymize older logs by stripping device identifiers while keeping the consent decision itself. You preserve the audit trail without hoarding personal data.

The practical cost is someone actually setting up those policies. Storage is the easy 20%; the hard 80% is mapping which downstream systems reference which log entries. Delete a log row and you might break an analytics pipeline or a compliance export. Automate that mapping before you need it.

Honestly—the teams that keep consent logs trustworthy are the ones that budget for maintenance like a real product, not a one-time compliance checkbox. Start with a monthly audit and a purpose registry; expand only when the pain justifies the machinery. That's the difference between a design surface and a dormant file cabinet.

When Not to Use This Approach

Low-Stakes, High-Frequency Consent

Analytics cookies. Heatmaps. A/B testing scripts that fire on every pageview. For these, a consent log as your primary surface is overkill—pure overhead that frustrates users without delivering any real agency. Nobody wants to open a log to discover that session replay ran for six seconds on a product page they already left. The transaction is too small, too frequent, and too forgettable. You're asking people to audit noise.

The fix isn't a log; it's a default. Set the baseline, let users opt out once, and move on. A persistent toggle in the footer beats a log they'll never revisit. I have seen teams burn two sprints building a beautiful log interface for precisely this use case—then watch engagement with it hover near zero. The log becomes a monument to a problem nobody had.

When Users Need Immediate Control

Location pings. Camera access. Push notifications for a messaging app. These are moments where the cost of waiting is real—a missed delivery, a frozen video call, a photo that didn't capture the moment. A consent log, by design, lives somewhere else. It's asynchronous, retrospective, and requires intent. That's the wrong tool when the user is standing in the rain, trying to get a ride, and the app asks for location right now.

Flag this for email: shortcuts cost a day.

The catch: if you redirect them to a log mid-flow, you've added three steps to a decision that should take one second. The trade-off is brutal—conversion drops, frustration spikes, and people abandon the task entirely. What usually breaks first is trust. They wanted control, but you gave them homework. For these cases, an inline prompt with a clear "Allow once" option beats any log-based system. The log can still record the decision, sure—it just can't be the decision surface itself.

Legacy Systems With Poor Data Quality

This one hurts. You inherit a system where consent events were never reliably logged, timestamps are off by timezone, and user IDs are duplicated across three databases. Building a consent log on top of that's like writing a diary with a pen that keeps running out of ink. The log's entire value proposition—accuracy, auditability, user trust—collapses when the underlying data is garbage.

You'll spend more time reconciling records than designing for your users. That's not preference architecture; it's archaeology. I fixed this once by first cleaning the data pipeline for two months before even sketching the log UI. Painful, but necessary. If you can't trust what you're logging, don't pretend the log is a source of truth.

Rhetorical question worth asking: would you rather have a mediocre log that's accurate, or a polished one that lies? Teams often pick the latter because it demos well. That's a mistake that comes back as legal headaches—or worse, a user who discovers their consent wasn't actually honored.

The log is a promise. If the data behind it's broken, the promise is a lie with a nice interface.

— field observation, consent infrastructure review

So when do you skip the log-first approach? When stakes are trivial, when control is urgent, or when your data foundation is shaky. Use it elsewhere. And if you're building for compliance-heavy contexts—health, finance—where users genuinely expect a record, keep the log but pair it with immediate controls. That combination, not the log alone, is what earns trust.

Open Questions and FAQ

Should Logs Be Editable by Users?

Short answer: yes, but with a seam. If a consent log is a record of *decisions*, not a transcript of your backend’s database writes, users need a way to correct their own errors. We once shipped a log where the “revoke all” button was too close to “confirm all.” A user clicked through, revoked everything, then couldn’t undo it without emailing support. That’s a consent log acting as a trap, not a surface.

Editable doesn’t mean freeform. You don’t let someone rewrite history; you let them *update intent*. Show the original entry, then an “update” action that creates a new timestamped entry with a clear diff. Keep the old one visible, dimmed. That way, you preserve audit integrity while acknowledging that people change their minds. The catch is storage overhead—each edit doubles the record—but that’s cheap compared to a support ticket.

One hard rule: never let edits silently overwrite the original. I’ve seen teams merge edits into the prior row to keep the UI clean. That breaks every downstream consent check that assumed immutable history. Wrong order. If you need to clean up for GDPR deletion, mark the record as “superseded” and hide it from user-facing views, but keep the tombstone in the log.

Editable consent is a promise that the system remembers your *latest* self, not your first confused one.

— Product designer, consent UX review

How Do You Handle Multiple Purposes Per Entry?

Don’t flatten them into one blob. A single checkbox that says “marketing and analytics and personalization” creates a log entry that’s semantically useless—you can’t tell what was consented to when a lawsuit asks. Split entries by purpose at write time. If a user toggles three switches, that’s three rows, each with its own timestamp and purpose ID.

That sounds fine until you realize some purposes share a toggle in the UI. We fixed this by making the log a *view* over the underlying consent facts, not a mirror of the form. The form can combine purposes; the log stores them separately. The trade-off is that your log schema becomes more complex—join tables, purpose foreign keys—but the alternative is a string field that nobody can parse reliably six months later.

Most teams skip this because it feels like over-engineering. Then they hit their first data subject access request and spend two days manually correlating timestamps across spreadsheets. That hurts. Keep the purpose granularity at the log level, even if the UI is lazy.

What About GDPR and CCPA?

GDPR wants proof of valid consent: clear, specific, informed, unambiguous. Your log should record *how* you asked, not just what the user clicked. Store a hash or ID referencing the exact consent screen version. If your copy changed last week, an old consent is still valid only if it met the standard at that time—so log the version. CCPA is looser about consent mechanics; it focuses on “don’t sell” opt-out rights. Your log needs to capture the opt-out action distinctly, not bury it under a general “preferences saved” entry.

These two regimes pull in different directions. GDPR rewards detailed intent logs; CCPA punishes over-collection. The middle path: log purpose-specific consents at minimum viable granularity, and log opt-outs separately with their own record type. Don’t try to unify them into one schema—you’ll end up with fields nobody uses and ambiguity where it counts.

The real pitfall is assuming compliance is a fixed target. Regulators update guidance, and your log schema will drift. What usually breaks first is the “basis” field—teams hardcode “consent” for everything, then hit a legitimate-interest scenario and have to retrofit. Plan for a basis discriminator from day one, even if it’s null for now.

Summary and Next Experiments

Key takeaways before you close the tab

Consent logs are not a compliance checkbox. They're a record of a relationship — and the team that treats them like a dusty audit trail loses the plot. The real work is making those logs legible to the people who actually touch them: product managers, support staff, even users themselves. If your log says "consent_granted=true" but nobody can tell you *when* that happened or *what* the user was looking at, you've built a tombstone, not a design surface.

What we've covered here is a mindset shift. Logs become a surface when they're structured around user intent, not around your backend's convenience. That means naming events in plain language, keeping timestamps honest, and refusing to bury the "revoke" path under three nested menus. It's not glamorous. It pays off in trust, and trust is cheaper than a lawsuit.

Three small tests to run next sprint

Don't redesign everything at once. Run these three experiments, each scoped to a single screen or flow:

• Test one: Add a "last updated" date next to each consent toggle in your settings page. Watch whether support tickets about "why am I still getting emails?" drop. They will.
• Test two: Export a week of consent events as a CSV and try to reconstruct the user journey for a single account. If you can't trace the sequence — grant, change, revoke — your schema is wrong. Fix it before adding more fields.
• Test three: Show a user their own consent history, time-stamped and plain-spoken, in a test environment. Ask them what they think happened at each point. The gaps in their answers are your next design task.

That third test is the one that usually stings. People discover they granted something they don't remember, or that a toggle they assumed was "off" was actually "on" for months. The catch — you'll want to fix that, not hide it.

"The log isn't the artifact. The interaction between the log and the person is the artifact."

— paraphrased from a product designer who rebuilt her consent UI twice

Further reading: resources to dig deeper

Start with the ICO's guidance on data subject access requests — it's dry, but it forces you to think about what "easy" really means. Then look at the GDPR's recital 39 on transparency; it's six sentences that explain most of what this article tried to say in six thousand words. For a practical angle, the Consent Managers' open-source UI patterns on GitHub are worth stealing from — not code, but the way they label "permission" versus "preference" is a useful distinction.

One more thing. Every team I've seen succeed at this started with a single complaint, not a grand vision. Someone in support said "I can't tell if this user ever opted in," and they chased that thread. The next step is yours: pick one screen, one log event, one confusing toggle — and make it less ambiguous by Friday. That's the whole experiment. The rest is refinement.