Coolest Projects returned for its second year in India on Saturday 19 September, taking place in Telangana’s state capital Hyderabad once more.
This year’s India event brought together 326 young technology creators who showcased 132 projects: India’s young tech creator community is clearly growing stronger. From AI to hardware to the web, young people’s projects took on topics that mattered to them, covering the playful to the practical.
A showcase of standout ideas
Here are just a few of the creative projects young people shared on the day.
Vhedhya, Tanvi, Bhavani, Sameeksha
Vhedhya, Tanvi, Bhavani, and Sameeksha| Fruit keys —Advanced programming
Fruit keys is a project that turns fruit into a musical instrument. The team used a Raspberry Pi computer, a camera, and the software library OpenCV. Bananas work as virtual keys that trigger musical notes. An apple lets players switch between instrument sounds. It’s a fun example of how computer vision can create touch-free, interactive experiences.
Kumari, Bhoomika, Shaurya
Kumari, Bhoomika, and Shaurya|Kinetic care—Hardware
Kinetic care is a smart physical therapy system for use at home. A camera tracks the user’s movements, so they can play a therapy-based video game while they exercise. A wearable sensor watches for sudden or unsafe muscle movements. If it spots one, it sends a vibration alert straight away to help prevent injury. The project shows how hardware can make rehabilitation safer and more engaging.
Srishti, Kimaya
Srishti, Kimaya|Chrome dino in real life — Games
This is a dinosaur-themed game with a motorised conveyor, moving obstacles, and increasing difficulty. Players dodge obstacles using a button while LEDs and sound effects create an arcade experience. High scores unlock rewards!
A day to remember
Bringing Coolest Projects to India for a second year showed us just how much creativity and ambition exists among young people here. Every project represented hours of learning, problem-solving, and imagination, and it’s a privilege to give these creators a platform to be seen and celebrated.
Events like this shine a light on why investing in young people’s digital skills matters so much for India’s future.
What stood out to us most this year was the breadth of ideas on display, and the confidence with which these young tech creators presented their work. It’s a strong signal of where India’s next generation of creative thinkers and problem-solvers is heading.
A huge thank you to our partner Code Club India for their support with this event, to the volunteers and mentors who made the day possible, and to our sponsors Qube Research and Technologies. And most of all we want to thank every young creator who showed up ready to share and connect with their community. We can’t wait to see what you build next.
VoidZero's tools such as Vite, Vitest, Oxc, and Rolldown — bundled in one toolchain as Vite+ — have made frontend development faster, but building full-stack applications requires more than just a tooling stack. These applications need server routes, databases, local development environments, and a fast and easy way to deploy ideas to production.
We’re excited to open-source three new products that bring server routing, typed data access, and Cloudflare deployment into a unified Vite workflow.
Void Platform: A shared deployment platform for teams to host Void apps on Cloudflare.
Void SDK: A composable JavaScript SDK for building full-stack apps with Vite.
Void CLI: A CLI for provisioning resources and deploying Vite apps to Cloudflare.
The CLI deploys apps built with the SDK to the Platform. All three products are open-sourced as a single JavaScript package and Vite plugin that you can install via npm install void. With Void, you can build your server and client together, carry types from your database to the UI, and let Void automatically provision the Cloudflare resources that your app uses.
We originally set out to build a single, private platform for all users to deploy apps to. After VoidZero joined Cloudflare, we adjusted our direction to open-source the platform and allow anyone to install because we saw a growing need: companies want to encourage vibe-coded internal apps, but are concerned about security and do not want to give cloud access to every employee. Void addresses this problem.
Void Platform: a cloud platform for your company
The Void Platform is fully open source and you can fork it and adapt it to your needs by integrating your company's systems, customize deployment workflows, build features for your customers, or make it work on other deployment platforms. Use the platform as it is, contribute improvements upstream, or fork it and build only the features you need. The open source code can be used out of the box or as a starting point.
As an admin of a Void Platform, you control access, set resource limits, inspect deployments and usage through the Void CLI or admin dashboard, and provide guardrails so everyone else can ship serious and vibe coded apps to the same shared platform.
By installing a Void Platform, your team or customers have a shared deployment environment in your Cloudflare account on top of Workers for Platforms. Void Platform enables:
Faster prototyping. Your team can quickly build prototypes, deploy them, and share working apps for feedback, without setting up a separate Cloudflare account or provisioning resources for every project. This reduces the time to ship internal apps from days/weeks to minutes.
Non-technical teams building. This workflow also lets teammates who do not normally write code work with coding agents to build and share their own apps. A designer can create an interactive prototype, or an operations teammate can build an internal dashboard, then deploy it to the same platform. All with the right security measures in place.
To self-host a Void platform, you need:
A Cloudflare account with Workers for Platforms and R2 enabled
A PostgreSQL database
An account with your chosen login provider
A domain for your apps
Then install Void as a cloud platform by running a single command:
Once your platform is set up, approved users can connect to it via the Void CLI for deployment.
void connect https://api.orange-company.dev
A user builds their app using the Void SDK, which is what powers Void Platform benefits like authentication, framework detection, resource provisioning, and more. In other words, Void Platform only works because of the accompanying SDK and CLI.
Void SDK: zero-config infrastructure
Void turns a Vite app into a full-stack Cloudflare Workers app. You or your agents can write code and Void will automatically infer resource bindings and provision resources such as databases, queues, or AI bindings during deployment.
To get started, add Void as a Vite plugin:
import { defineConfig } from "vite";
import { voidPlugin } from "void";
import { voidReact } from "@void/react/plugin";
export default defineConfig({
plugins: [voidPlugin(), voidReact()],
});
The Void SDK ships with adapters for popular JavaScript UI frameworks such as React and Vue, provides file-based API routing, pre-rendering, caching, islands, and end-to-end type safety from the database to your UI.
All of Void’s features are optional and composable. Void integrates with existing application frameworks such as Vinext, React Router, SvelteKit, Nuxt, TanStack Start, and Astro. You can use those frameworks for routing and rendering, while Void handles resource APIs using Hono, migrations, deployment, and authentication with Better Auth.
Let's take a look at building a server-rendered page, with types inferred from the database query through to the client:
// pages/blog.server.ts
import { defineHandler, type InferProps } from 'void';
import { db } from 'void/db';
import { posts } from '@schema';
export const loader = defineHandler(async () => ({
posts: await db.select().from(posts),
}));
export type Props = InferProps<typeof loader>;
By importing void/db, Void provides a local database to your app during development and makes void deploy provision D1 automatically for you in production. This also works for using AI through Cloudflare’s AI Gateway: just by importing void/ai, everything is set up automatically for you.
// routes/api/decide.ts
import { defineHandler } from 'void';
import { ai } from 'void/ai';
export const POST = defineHandler(async (c) => {
const { question } = await c.req.json();
const result = await ai.run('@cf/cloudflare/clef', {
model: 'clef',
state: {},
questions: {
decision: { type: 'noul', instructions: question },
},
});
const probability = result.answers.decision.noul;
return c.json({
answer: probability >= 0.5 ? 'yes' : 'no',
probability,
});
});
Void's React router is built for Async React, using transitions and Suspense to enable responsive navigation across screens. When you pair this router with a modern data framework such as fate and UI libraries such as Astryx, you can coordinate navigation, data fetching and mutations through React's transitions, as well as actions and optimistic updates across your entire application. Together, these pieces let you build apps that feel synchronous on fast networks, gracefully fall back on slower ones, and keep interactions responsive during expensive rendering updates.
If a user does not need Void Platform’s team management features, they can use their own Cloudflare account. Void SDK also deploys to Cloudflare directly.
Void CLI: one deployment command
The Void CLI is the main interface for Void. The CLI manages the platform and deploys the app. It's built on top of the new cf CLI and works well with agents.
With the Void CLI, you can ask your agent to debug failing requests, read deployment logs, analyze how your app is performing, or have them take care of the full lifecycle by deploying a finished app for you.
Once your app is ready to deploy to Cloudflare, you can run:
The first time you run void deploy, the CLI will prompt you to log into your Cloudflare account. Void builds your app using Vite, applies migrations, automatically provisions resources, and deploys to Cloudflare or a Void Platform. It can be used to handle the full lifecycle of your project such as building, deploying, and managing your resources and projects, for example:
Similar to how the CLI, and an agent by extension, can manage the entire lifecycle of a Void app, you can also use the CLI to manage a Void Platform:
Manage users, project access, and resources
Inspect deployments, logs, and rollbacks
Monitor platform health and usage
Connect with us
VoidZero’s mission is to make JavaScript developers more productive than ever before. We brought Vite, Rolldown, Oxlint, Oxfmt, and Vitest together in Vite+ for development, bundling, code quality, and testing. Void extends that stack to full-stack application development, letting you and your agents build, test, and deploy entire applications.
We’ve been using the Void SDK, CLI, and Platform in production at VoidZero for the past several months and we are excited to see what you'll build with Void. Please share your feedback with us:
The story starts in 1996, when Matthias Ettrich, a student at the University
of Tübingen, posted to a Usenet group asking for programmers to help build a
desktop for Linux. What followed became KDE, one of the largest free software
communities in the world. KDE made Linux usable as a desktop for people who
weren’t system administrators, giving it a complete, consistent graphical
environment at a time when there was none.
The film covers the highs and lows of three decades of KDE: the Qt licensing
fight and the rivalry with GNOME; the success of KHTML, the browser engine that
became the basis of Apple’s WebKit and Google’s Chrome; and the contentious
release of KDE 4 and the rebuild that followed.
Ubuntu 26.10 advances enterprise security features, completes the rollout of
the Rust-based uutils coreutils, and strengthens integrations for user
authentication using Microsoft Entra ID.
[…] Ubuntu 26.10 also ships with GNOME 51, bringing a smoother, more
responsive desktop, better display handling, improved accessibility, and
refinements across core applications. In addition, the Ubuntu App Center now
provides a more consistent experience for managing snaps and debs.
Greg Kroah-Hartman has announced the release of the 7.2.11, 6.18.57, 6.12.113, 6.6.159, 6.1.190, 5.15.223, and 5.10.272 stable kernels. This series includes,
among other things, a fix for a
critical vulnerability (CVE-2026-99999). The
flaw in skb_checksum_help()
would allow an IPv4 packet with bad checksum metadata to “corrupt the network
header and cause a bunch of mischief” in the words of patch author Michael
S. Tsirkin. As usual, all users are advised to upgrade.
Optimizing your site for AI is of little use if AI can't find it. The answer to someone's question may already be on your website: the installation guide you spent a week writing, or a first-hand account of using a product, with the details that make the difference for whether they buy it. As more people turn to AI for help, you want those systems to find your work, represent it accurately, and send interested people your way. You also want control over how they access your site.
Cloudflare and OpenAI launched a research pilot in July 2026 with those interests in mind. We wanted to find out whether signals from Cloudflare’s network could help ChatGPT users discover new content more efficiently.
Today, we’re sharing early results. So far, the answer is a resounding yes: the pilot has brought previously unknown pages into OpenAI’s search index, giving ChatGPT more sources to draw on to help people find relevant, timely information. Along the way, we’ve learned more about what makes a page worth discovering and how AI systems use the web.
Finding more of the web
The web is full of specifics. Someone fixing a washing machine needs the manual for their exact model. Someone applying for a passport needs the current requirements and fees. Someone choosing a local restaurant needs its latest menu and opening hours. Finding the right page can be the difference between a wrong answer and one that actually helps. These pages can be valuable even if few other sites link to them.
In the previous version of the web, discoverability was getting to the top of a search result page. It was then up to the human who visited your page to determine the value of the information, book that table, apply for that passport. As people increasingly rely on AI to find information and complete tasks, discoverability matters in new ways. AI systems need to find the right sources, understand what's useful, and connect people with relevant information – whether that's through an answer, a citation, or a visit to the website itself.
Cloudflare's network provides signals that can help OpenAI’s search crawler discover more useful pages across the web to surface to ChatGPT users. OpenAI then independently evaluates and ranks how those pages appear based on how relevant and helpful they are. Together, this creates a feedback loop that can improve both discovery and the quality of information people find.
This joint pilot, which used a participating cohort of ~1% of Cloudflare’s total network, has enabled OpenAI to discover and index hundreds of millions of new web pages, helping people discover more useful content and get more questions answered through ChatGPT. By linking back to relevant sources, ChatGPT Search also gives people a way to explore the original content and discover the websites and publishers behind it.
With GPT-6 and Intelligent UI, OpenAI is also making ChatGPT an even better place to shop, learn, and find answers, with more visual, interactive experiences tailored to what people need. This work complements these advances by helping ChatGPT discover more useful, up-to-date information from across the web.
From discovery to useful answers
Finding a URL is only the start. We need to know whether it leads to a page someone can access, whether that page offers anything distinct, and what it might help someone do.
We’ve learned, for example, how easily automated traffic can make a nonexistent page look interesting. Bots repeatedly ask for files that aren’t there. Some sites redirect almost any address to their homepage. Other addresses lead to copies of the same content. Recognizing these patterns gives us a way to cut wasted work before a crawler fetches the page, and improve efficiency in a way that benefits site owners.
We're also testing signals that identify and flag potentially harmful pages, adding another layer of information to support safer, more reliable discovery. A legitimate site can have a single compromised page, such as a fake login form planted by an attacker. Flagging that one page, rather than the whole domain, keeps people safe without penalizing the site owner. Early results suggest these signals can help identify pages that should be kept out of an index.
Making discovery easier
As more people use AI to discover information, website owners have new opportunities to reach interested audiences. For those who choose to make their content available to AI systems, these improvements make discovery easier and more efficient.
Keeping up by fetching every page more often would be expensive for everyone. For a website owner, a crawler that repeatedly downloads an unchanged page adds load without bringing any benefit.
The signals above are how we avoid that. Filtering keeps crawlers away from pages that don't exist or that redirect elsewhere. Change signals tell them when a page is worth another visit, and when it isn't.
There's a balance to get right. Finding new pages can initially increase crawling as those pages are evaluated and indexed. The goal is to keep discovering and stay current while reducing the work that takes. For Cloudflare customers, that means less unnecessary load. For OpenAI, it means more of its search resources are spent on information that helps people.
Making it worthwhile to participate
The next phase will build on what we’ve learned: improve the selection of pages, test faster and more reliable change signals, and measure what happens after content is discovered.
We’re continuing to work with OpenAI to understand how better site discovery can translate into real business outcomes, and we’ll keep sharing what we learn along the way.
Domain owners’ choices matter throughout. A signal about a page doesn’t grant permission to access it. This research uses metadata about the web for search and discovery, rather than sharing page content for model training.
Историята започва с едно подвижно едноклетъчно водорасло, което има свойството да се насочва към светлината с помощта на двете си камшичета. Малките същества имат своеобразно „око“ (червеникаво петно на повърхността си), съдържащо ретинал – молекула, която може да улови енергията на светлината и да я превърне в химическа. Освен че са симпатични, едноклетъчните водорасли впечатляват с изключително бързата си реакция – електрическите импулси, които се генерират при осветяване на окото им, се отчитат само след половин милисекунда.
Това е изненада за Питър Хегеман, защото според разбирането към началото на 80-те години на миналия век процесът на обработка на тези импулси е по-бавен. Например в човешките очи светлината задейства сложна верига от различни молекули. Те си предават сигнала, докато след около 10 милисекунди той стигне до протеин, който може да образува специален отвор в клетъчната стена, т.нар. йонен канал. Специфичното е, че през него могат да преминат заредени частици (йони), предавайки малък електричен заряд на клетката. Това ѝ дава сигнал да се активира – така например работят невроните и мускулните клетки.
Хипотезата на Хегеман е, че най-вероятно активирането на йонните канали е следствие на по-прост процес, при който няма междинни стъпки, а каналите се контролират директно от светлината. За съжаление, към онзи момент са познати различни видове йонни канали, но не и контролирани от светлина, поради което идеята не бива приета.
Хегеман не се отказва, но за следващата стъпка трябва да изчака няколко години, когато японски екип публикува генома на водораслото. С помощта на колегите си измежду всички гени той открива два, за които е много вероятно да кодират фоточувствителни протеини. За да потвърди, че това са търсените гени, Хегеман се свързва с Георг Нагел (с когото впоследствие ще сподели и Нобеловата награда), който има опит в изучаването на сходни протеини и разкриването на тяхната функция.
Експерименталната система, използвана от Нагел, са яйца от обикновената ноктеста жаба(Xenopus laevis). Ако в тях бъде вмъкната кодиращата последователност на някой ген, те могат да произведат неговия протеин, намножавайки го в лесна за наблюдение клетка. Когато бъдат внесени в яйцата, новите протеини се откриват по тънката им мембрана. След редица експерименти предположението на Хегеман се доказва – открити са нов вид йонни канали, които обикновено са затворени, но когато бъдат осветени, се отварят.
Експериментът е повторен и в клетки от бозайници (човек и хамстер), които също стават светлочувствителни. Двата протеина получават имената channelrhodopsin1 и 2(ChR1 и 2), като първият се активира от зелена светлина, а вторият е по-чувствителен към синя. Те се различават и по типа йони, които пропускат – ChR1 е селективен към протони (H+), а ChR2 пропуска всякакви положително заредени йони и при осветяването си генерира пик, след което поддържа по-нисък, но стабилен сигнал, ако светлината се задържи.
Публикацията на Нагел и Хегеман заинтригува Дайзерот, чийто екип се фокусира именно върху търсенето на начини за активиране на невронни клетки. След като получават копие от ChR2 от Нагел, Дайзерот и колегите му го вмъкват в неврони от плъх, които отглеждат като клетъчна култура. Въпреки първоначалните тревоги, че въвеждането на ген от водорасло в чувствителните нервни клетки ще наруши нормалната им работа, учените са приятно изненадани – след намесата няма видима вреда. Клетките не само се развиват нормално, но и придобиват нова способност: ако се осветят от синя светлина, те се активират, предавайки сигнала към съседните неврони. Този пробив поставя основата на ново научно поле, за чието съществуване се спекулира от Франсис Крик още в края на 70-те години на миналия век и което Дайзерот нарича оптогенетика.
Светлинното активиране на неврони бързо се прехвърля от клетъчни култури към животни. Един от първите успешни експерименти на Дайзерот е стимулацията на невронни клетки в мозъка на мишки чрез тънка оптична нишка, прокарана през дупка в черепа им. ChR2 е вмъкнат в невронни клетки, специфични за двигателната кора на мозъка (частта, отговорна за движение), което дава възможност на учените да мърдат мустачките на мишката с помощта на син лазер.
Системата е използвана и за потвърждаване на функцията на нов вид мозъчни клетки, за които се подозира, че контролират състоянието на будност. След като учените ги модифицират и ги вмъкват обратно в мишки, с помощта на светлина мишките могат да бъдат събудени по команда и така се потвърждава очакваната роля на клетките.
Още по-впечатляващо е активирането на специфичен отпечатък върху невроните, появяващ се след създаване на спомен – т.нар. енграма. За целта първо мишките са изложени на среда, в която изпитват страх, като се отбелязват невроните, активни по това време. При светлинно активиране на тези неврони, дори и в спокойна среда, мишките дават същия стресов отговор. Експериментът е повторен при променени условия, като се създава „фалшив спомен“. Стресовите неврони се активират изкуствено в спокойна среда, след което при поставяне на животните в същата ситуация, те се страхуват, без да има причина.
В следващите години технологията се развива значително. Открити са нови протеини, които реагират при други цветове на светлината, давайки възможност за подаване на няколко сигнала едновременно. Това разширява значително възможността за изследване на мозъка и позволява да се определят специализациите на отделните невронни клетки и да се разплитат сложните взаимовръзки между тях. Така са открити невронни групи, които отговарят за усещането на болка, различни социални поведения, жажда, глад и регулация на сложни функции като циркаден ритъм и вдигането на температура при задействане на имунната система.
Освен разкритите възможности за фундаменталната наука, оптогенетиката има потенциал и за медицината. Като се използват знанията от изследвания върху различни психологични и неврологични заболявания, като депресия, тревожност, шизофрения, алцхаймер и паркинсон, е възможно в бъдеще да се създадат устройства, които да регулират невроните, отговорни за заболяването, с идеята да се намалят симптомите.
Надежда има и за подобряване на кохлеарните импланти, които в момента използват електрически сигнали, за да стимулират звуковите нерви. Ако това може да се прави със светлина, активирането на нервните клетки ще бъде много по-прецизно. В момента се провеждат и клинични изпитвания за терапия на слепи пациенти, като вече има положителни резултати с частично връщане на зрението.
Неутриното е изключително интересна елементарна частица, която през повечето време лети през пространството със скорост, близка до тази на светлината. То няма електричен заряд, а масата му е пренебрежима, което му дава възможност да преминава през всички препятствия по пътя си, откъдето идва и прозвището му „призрачна частица“, популяризирано от Айзък Азимов. Естествените му източници са различни видове радиоактивен разпад и ядрени реакции, като протичащите в звездите или при експлозии на свръхнови, но може да се генерира също в ядрените реактори и в ускорителите на частици.
Призрачните свойства правят частиците неутрино изключително трудни за изучаване, въпреки че са сред най-разпространените във Вселената – всяка секунда през нокътя на малкия ви пръст преминават около 65 милиарда неутрино, идващи от Слънцето. Но именно защото не взаимодействат с материята, са интересни за учените – тяхната траектория и заряд остават на практика непроменени от момента на напускане на източника си и могат да дадат информация за него.
Частицата е „видяна“ за първи път през 1956 г. благодарение на напредъка в развитието на атомната енергетика, а малко по-късно е засечено и първото неутрино, излъчено от Слънцето. Но учените срещат проблем – засечените частици са много по-малко от теоретично очакваните. Подсказка защо това е така, идва през 1962 г., когато е открит нов тип неутрино (мюон неутрино), а пълният отговор е разкрит почти 40 години по-късно, когато през 2000 г., е открит и третият тип – тау неутрино. Междувременно е установено също, че частиците могат да сменят типа си по време на необезпокояваното си пътешествие – например един път са мюон, друг път са тау неутрино.
През годините има различни предложения за най-добрия метод за „лов“ на неутрино. Някои физици предлагат използването на големи водни басейни – когато неутрино се сблъска с атомно ядро, се образува заредена частица, която продължава в първоначалната посока на движение, но отделя светлина благодарение на ефекта на Черенков. Това би позволило да се види пътят на неутриното, но и да се определи откъде е дошло. Друга идея е използването на радиоантени, които да „слушат“ за тези сблъсъци, но вместо вода средата да е антарктическият лед.
Тук идва приносът на Халзен: той предлага двете идеи да се комбинират, като се използват фоточувствителни детектори, които да се поставят в дебелия лед на Южния полюс. Идеята му има редица силни страни. На Антарктида вече се води изследователска дейност, дебелият лед е стабилен материал, който е тъмен след определена дълбочина и за разлика от океаните няма обитатели, които да пречат на оборудването. Известен недостатък е трудният достъп, който е възможен само през краткото антарктическо лято.
Така започва работа по пилотна обсерватория, наречена AMANDA. В началото изследователите срещат пречка – в леда има малки мехурчета, които разпръскват светлината от частиците и маскират посоката им. Това кара учените да поставят сензорите по-дълбоко. След преминаването на 1400 метра попадат на изключително чист и хомогенен лед, в който проблясъците могат да пропътуват над 300 метра, преди да угаснат, а това е доста по-далеч от очакваното. Въпреки че обсерваторията работи добре, размерът ѝ се оказва недостатъчен за улавяне на неутрино с много голям заряд, идващи от далечни космически обекти. Потвърждението, че технологията работи, дава зелена светлина за започване на работа по следващата обсерватория. Мащабът на наследника, наречен IceCube, е наистина впечатляващ – детекторът е с обем от 1 кубичен километър, в който на дълбочина между 1450 и 2450 метра са поставени 5160 сензора.
Обсерваторията бързо дава резултат, засичайки частици, които идват от Дълбокия космос. През 2013 г. са засечени 37 неутрино с такъв произход, като три от тях носят изключително висока енергия и са наречени Бърт, Ърни и Голямото пиле (на героите от „Улица Сезам“). Четири години по-късно е уловено неутрино, което е проследено до източника си – блазараTXS 0506+056, който се намира на 3,7 млрд. светлинни години в посока съзвездието Орион. Други две частици пък идват от разкъсването на звезда от черна дупка. А през 2022 г. има новини за открит източник на неутрино в сърцевината на галактиката Messier 77, което дава нова информация за процесите, протичащи в активните галактически ядра.
Работата на обсерваторията продължава и в последните три години са добавени още 600 детектора. Макар че резултатите са добри, Халзен не спира да мечтае и да се надява, че ще бъдат направени още по-вълнуващи открития, които дори могат да бъдат извън очакваното според стандартния модел.
Когато получава новината за наградата, Халзен вече работи по предложение за нов проект и шеговито отбелязва: „Надявам се, че Нобелът ще помогне да го одобрят.“
От някои химични реакции се получават две почти идентични молекули, които са огледални една на друга. Сред първите учени, обърнали внимание на феномена, е Луи Пастьор, който дочува от колеги, че понякога винената киселина изкривява поляризираната светлина, а понякога – не. Той се захваща да направи кристали от киселината и наблюдавайки ги под микроскоп, установява, че те имат два огледални варианта, които, ако бъдат разделени и разтворени поотделно, наистина могат да насочат светлината или наляво, или надясно. А когато двете се смесят, светлината не променя посоката си. Веществата, които имат такава способност, биват наречени хирални, а отделните им форми – енантиомери.
Пастьор прави и следващото интересно откритие: бактериите могат да разграждат дясновъртящата винена киселина в гроздето, но изобщо не проявяват интерес към другата форма. Това подсказва, че живите организми имат способността да различават двата варианта. По някаква причина животът на планетата се е развил по хомохирален начин – с използване само на едната форма на веществата. Например аминокиселините, които изграждат белтъците, винаги са лявовъртящи, а захарите – дясновъртящи.
Естественият въпрос е „Защо?“. Какво и как се е случило в зачатъка на живота, което да зададе едната или другата посока? Загадката е голяма, тъй като обикновено от химичните реакции се получават равни количества от двата хирални продукта. Тоест ако се опитаме да синтезираме винена киселина в лабораторията, крайният продукт няма да върти поляризираната светлина, защото ще е равна смес от двете форми. По някакъв неясен начин в гроздето се получава само дясна форма.
Един от първите пробиви по пътя към разгадаването на мистерията идва след откриването на първата асиметрична реакция (при която единият енантиомер се натрупва с предимство) с помощта на хирален катализатор. Неговата хиралност насочва реакцията към едната посока. Ефектът е минимален, но възможността за промяна на съотношението между двата енантиомера дава надежда на учените, че това има как да стане и в лабораториите, а не е някаква тайна, известна само на живите организми. С времето асиметричният синтез е подобрен, като дава много по-добър добив от желаната форма (дясна или лява), което донася и Нобелови награди за химия на учените, поставили основите през 2001 и 2021 г.
Работата на Каган е продължение на тяхната – получаването на възможно най-чисти молекули. Това е от особена важност при производството на медикаменти, защото понякога едната форма на веществата не е просто неактивна, а е вредна за организма.
По това време учените мислят, че съотношението на двете версии на катализатора ще се предаде директно на продуктите от реакцията – хипотеза, която Каган поставя под съмнение, и той прави ново предположение. То се базира на факта, че катализаторите, които се използват в тези реакции, съдържат два компонента – метален атом, който е „двигателят“, и хирална молекула, която задава посоката. Идеята на Каган е, че към един метален атом могат да се прикрепят поне две хирални молекули и така се получават три версии на катализатора – ляво–ляво, ляво–дясно и дясно–дясно.
Докато двата еднопосочни катализатора дават очакваната молекула, съответно лява или дясна, смесеният не само че не работи на случаен принцип (да дава ту лява, ту дясна), а въобще не работи. Това означава, че ако се започне със 75% десен и 25% ляв катализатор, то ефективното съотношение е всъщност 90% към 10%, тъй като смесеният не работи. Този феномен се нарича нелинеен ефект.
Соай задава следващия голям въпрос: възможно ли е да има асиметрична реакция, която сама да произвежда своя катализатор? След няколко години работа отговорът е положителен. Като се започва с около 2% повече от единия енантиомер на едно вещество, след няколко реакции то се концентрира до 87%. Постигната е първата автокаталитична асиметрична реакция. Успехът не спира Соай, който си поставя още по-амбициозна цел: да постигне пълната хомохиралност, която се наблюдава в природата. Това става след още 8 години – започва се с много малък превес на едната форма, а крайният продукт е съставен почти само от нея. Ако реакцията се остави на случайността, то крайният продукт е този, който е успял да вземе минимална преднина в началото.
Макар и изцяло синтетична, реакцията на Соай дава надежда на учените, че разкриването на тайната на хомохиралността при живите организми е възможна. Откритията на Каган и Соай имат голяма практическа важност, защото позволяват синтеза на изключително чисти медикаменти, пестициди и други вещества, които се прилагат върху живи организми. Нобелът е признание и за предаването на знания в науката, давайки възможност експерименталната нишка да се проследи до един от пионерите на биологията – бележития Луи Пастьор.
Веднъж месечно Михаил Ангелов – биолог, агроном и любим нърд от нашия екип, ни представя най-интересните скорошни новини от различни сфери на науката и обяснява защо тези постижения са толкова значими за света и човечеството. Или най-малкото – любопитни и забавни.
Предупреждение: Тази статия съдържа детайли, които може да се възприемат като разстройващи.
Какво е отношението ви към смъртното наказание? Ще ви разкажа как се формира моето.
На 5–6-годишна възраст живеех със семейството си в Бенгази, Либия. По онова време диктатурата на Муамар Кадафи беше още в разцвета си. Либия беше икономически доста по-напреднала от България. Помня тъмния и блестящ асфалт на улиците (никога дотогава не бях виждала такъв) и изобилието от западни стоки в магазините.
Сред нещата, запечатали се в паметта ми от либийския период, са и екзекуциите. Там бесеха хора на площадите и излъчваха това по телевизията. Гледаш си „Пчеличката Мая“ (в Либия пчеличката се наричаше Зина) и в следващия момент – хоп – екзекуция. На площада с бесилото – множество от екзалтирани възрастни и деца. Гледката на отнемането на човешки живот ме разстройваше – всеки път избухвах в плач и дълго време не можех да се успокоя. Ужасяваше ме както фактът, че някой умира, така и реакцията на тълпата зяпачи. Благодарна съм, че баща ми беше твърдо против и ние да ходим да гледаме.
Последната екзекуция в България
е извършена в самия край на тоталитарния период – в началото на ноември 1989 г. Престъпленията на убития чрез разстрел мъж, квалифицирани като диверсия, са серия от саботажи, сред които и повреждане на лифта на Боровец три пъти, защото държавата му пречела да развива частен бизнес като дърводелец.
След промените, още през 1990 г., се налага мораториум върху смъртното наказание, а в началото на 1999 г. то е изцяло премахнато. Няколко години по-късно, през 2002 г., повече от половината анкетирани в проучване на „Алфа Рисърч“ посочват, че са за възстановяването на смъртната присъда. Проучването е част от социален експеримент по идея на Центъра за либерални стратегии. Близо 300 от 1200-те респонденти са поканени да участват в дебат по темата, организиран от bTV, който включва юристи, експерти, но и пострадали от престъпления. В резултат на дискусиите 20% са променили позицията си от за екзекуциите на против тях. Изводът от социалния експеримент е, че обществото може да се вслушва в аргументи, ако такива му се предоставят.
Последното изследване за отношението към смъртното наказание е проведено от „Галъп“ през 2016 г. – близо 20 години след влизането на България в ЕС, където смъртно наказание не се прилага. Точно една трета се обявяват в защита на връщането му, докато близо половината (47%) са против. Но тези резултати са преди консервативния обрат, който започна да настъпва в България през 2018 г. с дезинформационната кампания срещу Истанбулската конвенция.
Смъртното наказание в САЩ и прецедентът с Криста Пайк
В ЕС е в сила пълна забрана на смъртното наказание – по силата на Протокол №13 към Конвенцията за защита на правата на човека и основните свободи, според който то се отменя, и чл. 2, ал. 2 от Хартата на основните права:
Никой не може да бъде осъден на смърт, нито екзекутиран.
В САЩ обаче смъртното наказание съществува в 27 от 50 щата, макар да не се прилага във всички тях. Американският президент Доналд Тръмп е толкова убеден привърженик на екзекуциите, че още в първия ден от встъпването си във втория мандат отмени наложения от предшественика му Джо Байдън мораториум върху изпълнението им на федерално равнище. Мораториумът на федерално ниво обаче не означава, че смъртни присъди не са се изпълнявали на щатско равнище. Федералното законодателство и щатските законодателства са различни системи, а присъдите на федерално равнище са за по-сериозни престъпления, например тероризъм.
Методите за екзекуция, които се прилагат в САЩ, са смъртоносни инжекции, електрически стол, разстрел, а от 2024 г. за първи път в света се въвежда нов метод – азотна хипоксия.
Пайк е осъдена на смърт в щата Тенеси още преди 31 години, защото на 18-годишна възраст е убила момиче, което според нея е искало да отнеме приятеля ѝ. Въпросният приятел също участвал в убийството, но се „отървал“ с доживотен затвор, защото е бил на 17 години. Още едно момиче е присъствало на убийството, но няма доказателства, че е участвало активно, затова е осъдено само условно.
За Криста Пайк също са налице смекчаващи вината обстоятелства: тя е преживяла нееднократно физическо и сексуално насилие, била е неглижирана като дете, на 12 години е направила опит за самоубийство. Диагностицирана е с няколко психически заболявания: биполярно и тежко посттравматично стресово разстройство и клинична депресия; има вродено мозъчно увреждане, което вероятно е свързано с биполярното ѝ разстройство и с (не)способността ѝ да прави преценка.
Ала нищо от това не променя убеждението на съда, че тийнейджърката трябва да заплати за стореното със собствената си смърт. След множество обжалвания и отлагания екзекуцията е изпълнена на 30 септември 2026 г. чрез инжектиране на пентобарбитал.
Криста Пайк обаче не умира.
И преди се е случвало екзекуция чрез инжекция да е неуспешна, но това е ставало основно защото палачите не са успявали да улучат вена на осъдените. Понеже на медицинските лица е забранено да изпълняват смъртни присъди, затворническият персонал се справя… както може.
През 2009 г. например екзекуторите два часа се опитват да вкарат игла във вените на Ромел Блум и го набождат на 18 места, докато той плаче от болка. Не успяват, а Блум умира 11 години по-късно от ковид, преди да е насрочена нова дата за умъртвяването му. Проблем има и с вените на Клейтън Локет – екзекуторите го бодат от 18:23 до 18:56 ч., вкарват игла дори в слабините му. Минути след като опитът за екзекуция е отменен, човекът умира – от инфаркт.
През 2018 г. бодат болния от лимфом Дойл Хам повече от два часа и така и не откриват вена. След това щатът (Алабама) взема решение да не прави нови опити да го убие. Алън Милър, чиято екзекуция през 2022 г., отново в Алабама, се проваля след часове убождания в търсене на вена, не изважда този късмет. Наказанието му е изпълнено успешно през 2024 г. – това е вторият случай на екзекуция чрез азотна хипоксия. На теория смъртта би трябвало да е бърза и неусетна – осъденият вдишва азот през маска и не усеща, че се задушава, а има чувството, че диша нормален въздух. На практика обаче, умирайки, Алън Милър видимо (според свидетели) се е мъчил.
За разлика от тези случаи, обявени за провалени, екзекуцията на Криста Пайк е изпълнена докрай.
Единственият подобен прецедент е от 1946-та с 16-годишния Уили Франсиз, осъден на смърт чрез електрически стол. Екзекуцията е извършена, но електричеството не е достатъчно силно и момчето остава живо. Върховният съд постановява присъдата да се изпълни отново с аргумента:
Стават инциденти, за които никой не е виновен.
Причините за неуспешното изпълнение на наказанието на Криста Пайк тепърва ще се изясняват. Адвокатите ѝ са убедили съда да изиска всички налични доказателства по случая. Но отсега се знае, че екзекуторите и в нейния случай се затрудняват да улучат вените. Опитват с поне седем игли и накрая май не успяват – веществото вероятно не влиза в кръвта на осъдената, а се разтича в тъканите ѝ.
На теория екзекуцията с пентобарбитал би трябвало да е бърза и безболезнена – човек се унася за секунди и дишането спира. Невинаги обаче става така. Криста Пайк усеща не само че многократно я бодат, а и как пентобарбиталът влиза в тялото ѝ. За да остане активното вещество в течно състояние, то трябва да е в силен алкален разтвор. Тоест нещо като белина. Или сода каустик.
Резултатът е болезнено химическо изгаряне. Свидетели на екзекуцията са чули Пайк да казва, че ръката ѝ гори толкова силно, сякаш всеки момент ще избухне.
След като първата доза, вкарана в лявата ѝ ръка, не я убива, прилагат втората в дясната. По закон след неуспех първия път може да се постави нова инжекция, но законът не предвижда друг опит, ако и вторият не е успешен. Час след началото на екзекуцията Криста Пайк е още жива и издава хрипове. Тогава служител на затвора се обажда на „Бърза помощ“ и след известни перипетии (диспечерите първоначално не са били сигурни, че сигналът е истински), жената е откарана в болница.
След няколко дни Криста Пайк се събужда, макар адвокатите ѝ да са били убедени, че е в мозъчна смърт. Пита: „Къде съм и кои сте вие?“ Изгарянията от разтвора с пентобарбитал са сериозни и тя не може да движи ръцете си, не е в състояние и да преглъща. Първоначално е объркана, но бързо се възстановява, започва да става и да се храни. През цялото време е с белезници и под охрана.
За успокоение на данъкоплатците скоро състоянието на Криста Пайк се подобрява дотолкова, че тя е върната в затвора, където е прекарала три от петте десетилетия на живота си. Но продължава да е под лекарско наблюдение.
След неуспешната ѝ екзекуция изпълнението на смъртни присъди в Тенеси е спряно до края на 2026 г. Не е сигурно дали ще има нов опит за прилагане на наказанието ѝ. Адвокатите на Пайк, както и правозащитници и противници на смъртното наказание се позовават на Осмата поправка в Конституцията на САЩ от 1791 г., според която няма да се „изпълняват жестоки и необичайни наказания“. Това, на което е била подложена Пайк, е и необичайно, и жестоко.
Ала силни са и гласовете, според които Криста Пайк заслужава да умре, защото е отнела човешки живот. Сред тях са майката на Колийн Слемър – убитото от Пайк момиче, и сенаторката от щата Тенеси, републиканката Марша Блекбърн. Трябва да имаме предвид, че в САЩ смъртното наказание се радва на високо одобрение – според различни изследвания от последните година-две 52% от американците го смятат за морално приемливо, а 66% го одобряват по отношение на осъдени за убийство.
Екзекуцията като риалити шоу
В разгара на дискусиите за и против смъртното наказание след неуспешната екзекуция на Криста Пайк министърът на войната на САЩ Пийт Хегсет предложи екзекуция чрез разстрел да се излъчва на живо по интернет. Става дума за изпълнението на смъртното наказание на Нидал Хасан, бивш военен, убил 13 невъоръжени военнослужещи през 2009 г. Въпреки че според близо 90% от водещите американски криминолози смъртното наказание не предотвратява извършването на убийства, според Хегсет целта на предаването на екзекуцията онлайн е хората да разберат, „че подобни действия имат сериозни последици“.
Тръмп одобрява планирания за началото на декември 2026 г. разстрел на Хасан, но до този момент не е дал съгласието си за излъчване онлайн.
Ако излъчването все пак се състои, САЩ, доскорошният „лидер на демократичния свят“, през 20-те години на XXI век ще се нареди до Либия под управлението на Кадафи. И до Афганистан под властта на талибаните.
Съществуват ли хуманни екзекуции?
Идеята за хуманно изпълнение на смъртните присъди е рожба на епохата на модерността. През голяма част от историята на човечеството целта е тъкмо обратната – екзекуциите да бъдат възможно най-мъчителни. Сред прилаганите методи са били стъпкване от слон, изяждане от различни животни – от мравки до крокодили, без да забравяме плъховете и змиите, разпъване с коне, сваряване, изгаряне, погребване на човека жив, набиване на кол, премазване, и още, и още… За разпъването на кръст знаем всички.
Едно от достиженията на Френското просвещение, влязло в употреба по време на Френската революция, е гилотината. Идеята за нея принадлежи на Жозеф Игнас Гийотен, въпреки че не я е изобретил той. Подбудите му били всъщност хуманистични (според мярата на тогавашното време) – той искал смъртта да не причинява страдание, а да настъпва бързо и безболезнено. Всъщност Гийотен бил против смъртното наказание и затова предложил, пак от хуманистични подбуди, осъдените на смърт да бъдат използвани за медицински експерименти вместо убивани. Такива са чудесата на просвещенския хуманизъм.
Обесването е метод за изпълнение на смъртното наказание, който се прилага в Европа и САЩ почти до края на миналия век: в САЩ последното законно обесване е през 1996 г., а от страните, които днес са в ЕС – в Полша през 1988 г. На теория този вид екзекуция би трябвало да подейства мигновено, но на практика се случва процесът да се забави, човек да усеща натиска от въжето и че се задушава, и да изпитва болка.
Екзекуцията чрез разстрел се прилага в някои американски щати (и както стана ясно, на федерално равнище) и до днес. Разстрелът може да бъде в главата или в сърцето. В първия случай, ако всичко е наред, осъденият не би трябвало да усети нищо и смъртта да настъпи мигновено. При прострелване на сърцето смъртта настъпва за секунди. Стават обаче грешки – понякога куршумите не попадат на правилното място, което може да причини мъчителна смърт.
Електрическият стол също на теория би трябвало да убие моментално – преминаването на 2000 волта през тялото би следвало да предизвика незабавна мозъчна смърт. На практика обаче се случва контактът между електродите и тялото да не е добър, човек да усеща как буквално се изпържва, да получава изгаряния и да изпитва задушаване.
Смъртоносните инжекции и азотната хипоксия вече ги обсъдихме. Човек би могъл да си помисли, че всъщност гилотината е най-сигурният метод, а проблемът с нея е естетически – в наши дни търкалянето на глави изглежда варварско. Макар и рядко обаче, има случаи гилотината да засече и осъденият да остане като козела от приказката на Ран Босилек – „клан, клан, недоклан“. Това е преживял например през 1793 г. френският якобинец Жозеф Шалие. Гилотината засякла и накрая се наложило главата му да бъде доотрязана ръчно.
Хуманността в концепцията за смъртното наказание е проблематична не само по отношение на екзекутираните, а и на палачите, както и на цялото общество.
Дори когато екзекуциите се изпълняват посредством машина – например електрически стол или гилотина, хора са отговорни за протичането на процеса. Тези хора не са от камък – те могат да изпитат страх, вина, ужас, да настъпят трайни поражения върху психиката им. Документирани са множество такива случаи.
Но дори да допуснем, че екзекуторите останат непокътнати емоционално и (според собствените си разбирания) морално – държавата има проблем, защото овластява едни човешки същества да убиват други.
Един от основните аргументи в защита на смъртното наказание е възмездието –
тоест че наказанието трябва да е пропорционално на престъплението. Ако се замислим обаче, пропорционалността рядко е достижима. Норвежкият националист Андеш Брайвик, убил 77 души, не може да бъде убит 77 пъти. От друга страна, на смърт в САЩ (а за други страни с диктаторски и фундаменталистки режими да не говорим) са осъждани и хора, които не са убили никого.
В основата на идеята за пропорционалността стои варварският по същество принцип „око за око, зъб за зъб“. Той обаче не може да се прилага последователно – изнасилвачите не биват изнасилени за наказание (поне като официална присъда, а иначе в затворите изнасилвания има), крадците не ги ограбват и т.н. На смъртното наказание обаче се гледа като на възстановяване на справедливостта, въпреки че, ако осъденият е убил някого, смъртта му няма да го върне.
Друг аргумент за смъртното наказание е опасността извършителят да повтори престъплението си, ако излезе на свобода. Този проблем обаче може да се реши с внимателна преценка дали осъденият продължава да е опасен. От друга страна, има извършители на тежки престъпления, включително убийства, които осъзнават вината си и искат по някакъв начин да компенсират щетите – най-малкото като призовават другите да не постъпват като тях. Те не биха могли да бъдат полезни на обществото, ако са екзекутирани.
Най-циничният от аргументите е, че за осъдения се харчат пари на данъкоплатците. Тогава да екзекутираме всички затворници ли? Броят им може да се намали чувствително чрез работещи форми на превенция и социална рехабилитация, не чрез екзекуции.
Не това обаче е поводът за тази статия. А неуспешната екзекуция на Криста Пайк и дискусиите по този повод, включително в България. Натъкнах се на много коментари как Пайк заслужава да умре. Някои дори разпространяваха конспиративната теория, че тя сама е направила така, че да оцелее – например като е отказала да изяде последното си ястие. Ако беше толкова лесно, всички осъдени на смърт щяха да се изхитряват.
Това, че в България не се изпълняват смъртни присъди, не е гарантирано веднъж завинаги. Затова е важно да започнем да говорим още отсега. Защото, макар да живеем във време, в което фактите и логичните аргументи нямат особено значение, може би хората все още могат да се вслушват – както става и в социалния експеримент на Центъра за либерални стратегии и „Алфа Рисърч“, проведен преди четвърт век. Може и вече никой да не се вслушва в никого. Но ако не говорим, няма да разберем.
Този път ще започнем нестандартно – с една съвсем кратка анкета.
Анкетата ще бъде активна до 21 октомври.
Темата за русизмите в българския език отдавна е в полезрението и на езиковеди, и на неспециалисти. За съжаление, когато тя се обсъжда от неспециалисти, емоциите са в повече, а научната информация, ако изобщо се взема предвид, е на втори план. Като цяло отношението на обществеността към русизмите е негативно и това е напълно разбираемо.
Опитвайки се по всякакъв начин да се разграничим от Русия, искаме да зачеркнем и руските следи в нашия език.
Нищо ново под слънцето всъщност – подобна реакция е имало през Възраждането срещу турските думи.
В тази и в следващата статия ще се опитам да хвърля повече историческа светлина по темата, без претенцията, разбира се, да я разгледам от всички страни.
В списъка на незаподозрените
В началото е редно да направим теоретичното уточнение, че русизмът не е дума, която ясно се осъзнава като руска и обикновено се сочи с пръст (например считам, касае се, удачен), а изобщо „дума, израз или синтактична конструкция, заимствана от руския език в друг език“¹.
Не бях замислила да ви потопя направо в дълбокото, но каква по-добра илюстрация бих намерила от това, което написах преди малко: „В началото е редно да направим теоретичното уточнение“. Само тук има два ясни русизма, които надали бихте заподозрели – начало и уточнение. Звуковите маркери – наследниците на определени звукове и съчетания на звукове в праславянския език – ни помагат да ги идентифицираме.
Един от тези маркери е застъпникът на малката носова гласна (означавана с ѧ в старобългарски) – в съвременния български книжовен език това е е, а в руския – я или а след мека съгласна². Съответствието на първата дума в старобългарския език е начѧло³ и ако бяхме я наследили направо, без език посредник, тя щеше да бъде начело и да е омоним на наречието начело. Днес обаче употребяваме начало, също и производните началник, начален, в които има несъмнени руски следи.
В думата уточнение виждаме типичната за руския език замяна на гласната ъ с о в корена. Старобългарският корен е -тък- и днес го срещаме в наречието тъкмо и в глаголи като тъкмя, изтъквам, стъквам, стъкмявам. Доста по-често обаче употребяваме точен, точно, точност, даже и точка, ако щете – пак с несъмнени руски следи. След като уточним, че промяната на к в ч не е специфична за руския език (дължи се на това, че някога е имало ь след тази съгласна), можем да направим едно упражнение: в случай че бяхме наследили тези думи направо от старобългарския език, те щяха да звучат и да се пишат така: тъчен, тъчно, тъчност, тъчка.
Други маркери и нови руски находки
Тази статия би разширила обема си поне до курсова работа, ако разгледаме подробно всички звукови маркери и приведем съответните примери, затова ще се ограничим. Един от най-сигурните маркери е голямата носова гласна (ѫ) и нейните наследници: ъ в българския език, у в руския. Вече няколко пъти използвах термина звук – стопроцентов русизъм, тъй като в старобългарския език тази дума е била с облика звѫкъ.
За мен лично е интересно, че руският език е сложил своя отпечатък и върху думата художник(хѫдожьникъ), а трусовете на земята и конският тръс всъщност имат един и същи праобраз – трѫсъ⁴. Във възмущението (възмѫщениѥ – от възмѫтити сѧ) и ругаенето (от рѫгати сѧ) също има доза руска фонетика, както и в блудството (блѫдъ ‘блудство, разврат’, блѫдъныи сынъ ‘блудният син’).
Тук трябва да отбележим, че значението на старобългарските думи в доста случаи се различава от значението, което влагаме в тях днес, например съществителното възмѫщениѥ се е употребявало за морско вълнение или за вода, която се движи, а рѫгати сѧ – за подиграване, присмиване. Все пак ни дели повече от хилядолетие – време, през което тези думи са пребивавали в различна езикова среда и са развили нови значения, а някои от старите са отпаднали. Смисловата връзка с водата обаче се пази в глаголите мътя, размътвам, в съществителното мътилка, където срещаме българския наследник ъ на звука ѫ.
Думата лев също е с променено значение (название на доскорошната ни парична единица) и в нея също има руска следа – е на мястото на някогашната малка ерова гласна(львъ)⁵. Със сигурност знаете, че през Възраждането, а и след това със съществителното лев е назоваван царят на животните. То стои и в основата на прозвището Левски. Други думи с този маркер са ревност (рьвьность ‘усърдие, старание’; ‘завист, омраза’) и възмездие (от мьзда ‘награда’).
Последният маркер, който ще посоча, е застъпникът на праславянското съчетание *dj: в българския език това е съчетанието жд, а в руския – само ж. Избрах този маркер, защото днес редовно употребяваме думата госпожа в официалното общуване. Тя произхожда от старобългарската госпожда и е означавала „господарка“, както господинъ е означавала „господар“. Впрочем предполагам, че и преди да прочетете това, сте знаели откъде произлизат думите, понеже не сте невежи (невѣжда ‘невеж човек’) – още един русизъм.
Странстванията на думите и книгите
За да си починем малко от тази сравнително сложна материя, ще очертаем в най-едри щрихи пътя на думите във времето, за да обясним как и защо са настъпили посочените по-горе промени в тях. Тръгваме от т.нар. класически старобългарски паметници (основно ръкописи и епиграфски паметници), от които е извлечено лексикалното богатство и са съставени речниците на старобългарския език. За жалост, до днес няма нито един открит оригинал на първоначалните Кирило-Методиеви преводи на светите книги. Най-старите ръкописи – споменатите класически старобългарски паметници – са от края на Х и от ХI век.
Нищо не е оцеляло и от някогашната Преславска библиотека. За нейното съществуване има само косвени сведения, които обаче са достатъчни, за да се предполага, че е била богата за времето си и преводаческата и преписваческата дейност в столицата е била покровителствана лично от владетеля (княз Борис, цар Симеон, а по-късно и цар Петър)6.
Съществуват различни хипотези как преславските книги са стигнали до Киевска Рус в края на Х век, когато държавата е покръстена. Общоприето обаче е мнението, че всички старобългарски книги, пренесени там, са погинали7. Чрез тях се осъществява т.нар. първо южнославянско влияние, което по същество е българско. Преславските преводни произведения и авторски творби познаваме по по-късни преписи, направени на местна почва, в които започват да проникват руски езикови черти, като споменатите по-горе звукови промени. Постепенно се формира руската редакция на старобългарския език – и това е нещо, което почти не се знае от нас, българите:
в началото на руския книжовен език стои старобългарският книжовен език. Дали сме на руснаците не само кирилската азбука, но и основата на тяхната книжнина и на книжовния им език.
По време на Второто българско царство нашата литература преживява нов възход. Търновската книжовна школа и езикът на паметниците от търновски тип упражняват влияние върху руската редакция. То е известно като второ южнославянско влияние. По-късно руската редакция „постепенно се затваря в рамките на каноничната литература и се превръща в т.нар. църковнославянски език“8.
Влиянието променя своята посока през Възраждането, когато формиращият се новобългарски книжовен език започва енергично да черпи от църковнославянския и впоследствие от руския език, включително и коментираните по-горе думи.
Този интензивен процес, а и други процеси, по-близки до нашето време, ще проследим в следващата статия, но все пак в края на тази ще актуализирам първия въпрос от анкетата: употребявате ли русизми? ;)
2 За улеснение посочвам буквите, с които се означават [йа] и [’а].
3 Голяма част от примерите за фонетичните маркери в тази публикация са взети от Харалампиев, И. Историческа граматика на българския език. В. Търново: Фабер, 2001, с. 235–237.
4 Като добавим земетресение (впрочем имаме и земетръс) и стряскам, тряскам, картината става доволно сложна.
5 В съвременния български книжовен език широко разпространена е замяната на ь с е в наставките (ловец < ловьць; виновен < виновьнъ) и по-рядко в корените на думите.
6 Гагова, Н. Владетели и книги. София: ПАМ Пъблишинг Къмпани, 1910, с. 49–57.
7 Пак там, с. 58.
8 Кирило-Методиевска енциклопедия. Т. III. Грашева, Л. (гл. ред.) София: Академично издателство „М. Дринов“, 2003, с. 453.
Езикът може да е вкусен и извън блюдото – онзи, българският език, на който говорим от малки и на който около 24 май се кълнем в обич. А той в същността си е средство за общуване и за да ни служи добре, непрекъснато се променя. Да го погледнем в неговата динамика и да се опитаме да разберем какво става и защо, кои са движещите механизми и как те са свързани с обществените процеси. И тъй като задачата не е лека, ще го правим постепенно – на порции.
On September 22 we released systemd v262 into the wild.
In the weeks leading up to that release (and since then) I have posted
a series of serieses of posts to Mastodon about key new features in
this release, under the #systemd262
hash tag. In case you aren’t using Mastodon, but would like to
read up, here’s a list of all 35 posts:
I intend to do a similar series of serieses of posts for the next
systemd release (v263), hence if you haven’t left tech Twitter for
Mastodon yet, now is the opportunity. My series for v263 will begin in
a few weeks most likely, under the #systemd263
hash tag.
Following reported strikes on Yandex data centers, claims circulated on the Internet that Russian bot farms and influence operations had been knocked offline. HTTP traffic charts showed steep drops, fueling speculation that the infrastructure damage had stopped these malicious actors. However, aggregate traffic metrics can easily mislead. There are two autonomous system numbers (ASNs) associated with Yandex: AS13238 is used by Yandex’s search engine, while AS200350 runs its cloud services.
Using Cloudflare Radar and Bot Management data, we analyzed how these two ASNs were affected — and while both saw drops in traffic, they saw differing impact.
Yandex Search (AS13238): The drop in traffic consisted almost entirely of verified search crawlers indexing web pages, images, and site resources.
Yandex.Cloud (AS200350): There was a decline in malicious activities like vulnerability scanning and probing, but high-volume automation did not vanish — it simply migrated to other hosting providers.
While malicious traffic may originate from a particular provider, it does not necessarily tell us who is responsible for the traffic. Understanding why the strikes had little lasting effect on malicious traffic requires analyzing request behavior, rather than just overall traffic patterns.
What happened: the effect of the strikes and pre-event baseline
Between October 7 and 11, reported Ukrainian drone strikes hit three Yandex facilities in Russia, progressively knocking data centers and network capacity offline. As seen on Cloudflare Radar, this culminated in a near-total collapse of the Yandex network on October 11 when traffic plummeted to 99% below baseline for Yandex Search (AS13238) and 90% for Yandex.Cloud (AS200350). Despite a brief partial recovery, both networks remained disrupted through October 13, settling at 86-90% below normal baselines. (As of October 14 at 18:00 UTC, traffic is at 85% of normal.)
A drop in overall HTTP traffic only confirms that the network went down. It does not reveal whether malicious or evasive bots were disrupted. Looking at the pre-event automation baseline, we can see that before the strikes, automated requests accounted for 36.1% of all HTTP traffic observed globally across Cloudflare's network, and 35.8% of traffic from Russian IP addresses.
The outage had different effects on automated activity on the two affected ASNs because they served different roles.
Yandex Search ASN (AS13238) is used for search index crawling. Cloudflare classified 99.5% of its requests as automated, and 93.6% of its bot requests as Verified. Our analysis showed that traffic from this ASN indexed pages, rendered pages, and rendered images, which is consistent behavior for a search crawler. The Yandex Search ASN supplied about 7% of Russia-origin bot requests, and just 0.05% of the global total.
Yandex.Cloud ASN (AS200350) is a cloud-hosting network and carries a very different mix of automation. Approximately 95.0% of its scored requests were bots, but none of its observed bot requests were verified by Cloudflare. Yandex.Cloud’s bots looked more like software apps: nearly two-thirds of their requests sent data to websites, some identified themselves as JavaScript, Python, or Go programs, and a larger share went to software companies than Yandex’s search bots. The Yandex.Cloud ASN supplied about 2% of Russia-origin bot requests, and just 0.01% of the global total.
Impact of the event on overall bot traffic
"Bot traffic" refers to automated requests to websites on Cloudflare's network, such as crawlers and scripts, not necessarily activity on social media platforms. As Yandex’s networks lost capacity, their bot requests fell too. That was expected: nearly all traffic from Yandex Search and Yandex.Cloud was automated. While we saw the obvious drop in total traffic, we did not see any evidence linking a global disruption in malicious traffic to the drop in traffic from Yandex.
Russia-origin bot requests fell roughly in proportion to the Yandex traffic that went offline, since most requests from those networks were automated.
Date UTC+3
Global bot requests (% of all HTTP requests)*
Russia-origin bot requests (% of Russia-origin HTTP requests)
* Radar reports global traffic by both total HTTP requests, and by HTML requests (an approximation of a page view). The above table reflects total request volume.
Impact on Yandex Search ASN (AS13238): less search crawling
The decline on Yandex Search ASN was almost entirely search crawling. Sampled requests showed that 78.1% belonged to verified YandexBot, 11.5% to YandexRenderResourcesBot, and 1.9% to YandexImages.
Among websites and services, the industry segment that saw the steepest drop was Publishing and Newspapers, where traffic from Yandex networks fell 44%. Approximately 90% of pre-event traffic to news sites from this ASN was YandexBot indexing articles, with 40.5% of Cloudflare customers returning HTTP 403 Forbidden responses because the site owner blocked the crawler. When the Yandex Search ASN went offline, customers simply saw less indexing from Yandex.
Impact on Yandex.Cloud ASN (AS200350): legitimate use and migrating malicious traffic
Yandex.Cloud displayed a completely different profile. Following the reported strikes, bot traffic from Yandex.Cloud fell about 40%. Several attack-like categories showed especially sharp declines. For example, WordPress plugin probing fell 90% and scanner-identified requests fell 93%. Interestingly (and tellingly), Cloudflare customer blocks on Yandex.Cloud traffic also fell 70% during the event period, suggesting that proportionately less malicious traffic was even hitting the Cloudflare WAF from this ASN.
Impact on business verticals
Yandex.Cloud’s bot traffic is also interesting when segmented by top request destination industries:
Destination industry
Bot traffic pre-event
Bot traffic during event (Oct 7-13)
Change
4xx (client error) HTTP response status share: pre → event
Computer software
24.24M
15.18M
−37.4%
18.5% → 15.9%
Gambling
23.01M
18.80M
−18.3%
99.1% → 99.3%
Media incl. adult
1.33M
223.1K
−83.3%
82.0% → 61.8%
Internet and telecom
524.2K
206.5K
−60.6%
71.4% → 51.1%
Travel / tourism
363.9K
158.1K
−56.6%
27.0% → 12.3%
Retail / wholesale
316.0K
167.7K
−46.9%
71.0% → 55.9%
Gaming / computer games
226.3K
63.2K
−72.1%
51.4% → 9.2%
Publishing / newspapers
90.8K
8.8K
−90.3%
90.2% → 61.4%
The majority of traffic from the Yandex.Cloud ASN fell into two industry buckets: computer software and gambling. The computer software bucket was predictable for an ASN meant to host third-party applications and software integrations. In fact, we even saw that api.cloudflare.com is a top hostname for Yandex.Cloud request traffic. An overall majority of that traffic succeeded (requests returned 200s) both before and during the event, pointing to legitimate usage.
The gambling sector offers the clearest evidence that malicious automation relocated rather than disappeared. Nearly all of Yandex.Cloud’s bot requests were targeted at one gambling customer account, with traffic shifting among its hostnames. Immediately following the October 8 disruption, bot requests from Yandex.Cloud to this account dropped to zero. Simultaneously, identical requests began appearing from other Russian hosting ASNs, including Radist and Selectel. The incoming traffic maintained an identical fingerprint across providers:
The same JA4 TLS client fingerprint
The same uncommon request paths and HTTP headers
The same custom User-Agent strings
Overall, Russian bot traffic targeting gambling accounts remained essentially flat over the week, moving from 167.7 million to 170.1 million requests (+1.4%). The automation never stopped running; the operators simply migrated their workloads to alternate cloud providers once Yandex.Cloud became unavailable.
Across most industries, the share of bot requests from Yandex.Cloud returning any HTTP 4xx response fell. This is largely due to a drop off in the attack-like traffic mentioned above. This, in combination with the gambling customer analysis, shows that malicious traffic that was sending requests through Yandex.Cloud simply shifted its “services” to other providers after the service disruption.
Finally, when we analyzed social media traffic, we found no unexpected changes in traffic either from Russian-origin IPs (0.6% decrease in total traffic over the event period) or globally (1.2% increase in total traffic over the event period). We repeated the analysis on bot traffic hitting the “post”, “reply”, and “like” endpoints for a specific social media platform and similarly did not find an unexpected shift before or during the event period from either Russian-origin IPs (5.7% decrease in total traffic over the event period) or globally (1.1% increase in total traffic over the event period). Based on our assessment, the data does not appear to support the claims that the strikes crippled social media manipulation, though without further analysis with data outside of Cloudflare, we cannot conclusively say there is no connection.
What the data told us — and what it didn’t
When traffic from Yandex networks collapsed, speculation spread across the Internet that Russian influence operations and malicious botnets had suffered a crippling blow. Cloudflare data tells a different story: across Cloudflare's network, there was no evidence that the strikes knocked social media manipulation offline or otherwise disrupted malicious activity on the Internet. Instead, the data demonstrated:
Search indexing dropped. The overwhelming majority of the traffic that dropped from Yandex Search ASN consisted of verified YandexBot crawlers fetching news articles and web assets. The main impact was reduced content discovery in Yandex Search.
Malicious automation migrated instead of stopping. While vulnerability scanning and plugin probing temporarily dropped on Yandex.Cloud, high-volume operations quickly moved to alternative hosting networks.
A network disruption means that specific servers stopped sending requests, but it does not mean an automated threat disappeared. Cloud workloads are portable, so when a data center goes dark or an IP prefix gets blocked, operators can migrate their scripts to another provider in hours.
Our analysis here is a reminder that client ASN traffic volume is an unreliable proxy for interpreting automated bot behavior. Defending against automated threats requires inspecting request behavior, such as identifying shared JA4 fingerprints, monitoring anomalous request rates, and applying WAF rules to sensitive endpoints, regardless of which network the request originates from. Physical infrastructure is static, but malicious automation is built to move.
Most security tooling that fits into a CI/CD pipeline—static analysis (SAST), software composition analysis (SCA), and dynamic scanners (DAST)—flags potential issues from patterns and signatures. A flagged pattern shows you where to look; penetration testing is what confirms whether something is actually exploitable. That confirmation has traditionally come from a periodic, out-of-band engagement that runs on a schedule rather than on a deploy, so deploys between engagements reach production with that confirmation still pending.
AWS Continuum for penetration testing (formerly AWS Security Agent) is a service that uses AI agents to find and confirm exploitable vulnerabilities in your running applications. In this post, we walk you through making it a post-deployment gate in your pipeline. The gate runs a penetration test that is automatically scoped to the change you just deployed, and it can block promotion to production when a finding is at or above a severity threshold you choose. Because each run tests only the change since the last passing gate rather than the whole application, it is fast and economical enough to run on every deploy. We give a high-level overview of the pattern, which can be applied on four major CI/CD platforms: GitHub Actions, GitLab CI/CD, Bitbucket Pipelines, and Azure DevOps Pipelines. We then provide a specific worked example for GitHub Actions.
By the end, you will have a pipeline that deploys a change to a staging environment, runs a scoped penetration test against the deployed change, and promotes the change to production only when the gate passes.
The following diagram shows the end-to-end flow. Your CI/CD pipeline deploys to staging, then the pentest gate step authenticates to your AWS account through OpenID Connect (OIDC) and calls Continuum for penetration testing, which runs the scoped test against the staging environment. The gate waits for the result, reports the outcome back to your pipeline, and conditionally blocks promotion to production. All testing runs server-side in your AWS account, so no penetration testing logic runs on your CI/CD runner.
Figure 1: Pipeline gate architecture: Your CI/CD pipeline deploys to staging, the pentest gate authenticates via OIDC and calls Continuum for penetration testing, which returns a scope decision that gates promotion to production.
Why scoping to the change matters
What makes the gate practical to run on every deploy is that it scopes each test to the change you just deployed. Continuum for penetration testing determines the commit range—the head is the commit being gated, and the base is the previous commit the gate already cleared—and tests only what changed. Testing the change instead of the whole application is what keeps a per-deploy penetration test fast and cheap enough to belong in a pipeline rather than on a quarterly calendar.
Each run returns one of three scope decisions: in scope (the change modified the attack surface—findings are evaluated against your threshold), scoped out (the change was within scope but nothing security-relevant changed—the pipeline passes), or scope conflict (the change fell outside the configured scope and was not tested—you choose whether that blocks). The Continuum for penetration testing console records the decision and the commit range on the Scoping tab of each run. When a gate blocks, you can see exactly why. For the full mechanics of how the commit range is computed and validated, see How the pipeline integration scopes the test.
Because the gate blocks on findings that Continuum for penetration testing validated as exploitable rather than on pattern matches, a red pipeline carries a clear meaning: a reproducible vulnerability in the change, waiting to be fixed before promotion.
Setting up the gate
The gate takes three steps to set up: configure a penetration test, create an AWS Identity and Access Management (IAM) role that your pipeline can assume, and add the gate step to your pipeline.
Before you start, you need an AWS account with permission to create both an IAM OIDC identity provider and an IAM role, and a staging environment the penetration test can reach.
Step 1: Configure the penetration test
Complete the one-time setup described in Before you start: verify your target domain, create a penetration test in your Agent Space, enable CI/CD mode, and connect your repository. Note the Agent Space ID (as-…) and penetration test ID (pt-…), because you pass both to the gate step in Step 3. The pipeline tests whatever this penetration test is configured to test, so its target and scope set what the gate covers.
Step 2: Create the IAM role
Authentication uses OIDC federation rather than stored keys. Your CI/CD provider issues a short-lived token identifying the pipeline, and AWS Security Token Service (AWS STS) exchanges it for temporary credentials when the pipeline assumes an IAM role you create. There are no long-lived AWS access keys to store as CI/CD variables, which removes the credential most often leaked from a pipeline.
The security of the gate rests on two policies: the IAM role’s trust policy (which pipelines can assume the role) and its permissions policy (what the pipeline can do once the role is assumed). For the exact policy JSON, the provider-specific OIDC URLs and audience values, and the sub claim format for each CI/CD platform, follow the reference in Scope the trust policy to your pipeline and Grant least-privilege permissions.
The following judgment calls help you decide how to scope these policies.
How tightly to scope the trust policy is the first decision. Pinning the sub claim to a single branch (for example, main) is the right default when a branch is the only one that deploys through this pipeline. If several branches or environments legitimately run the gate, scope to the environment instead of the branch where your provider’s claim supports it—and remember that not every provider carries a branch in the claim at all. On Bitbucket, the repository (and optionally a deployment environment) is as tight as it gets. Start as narrow as your deployment reality allows and widen only when a real branch or environment needs it. Note that GitHub repositories created or renamed on or after July 15, 2026 emit an immutable sub claim with numeric IDs—confirm the exact sub your pipeline emits before you write the policy.
Step 3: Add the gate step to your pipeline
The step is the same idea on every provider—the syntax differs. Pin the integration to an immutable version (a release tag, commit SHA, or pinned component version) so an upstream change can’t alter what runs in your pipeline. For the full settings reference and defaults table, see Defaults the integration ships with.
Before relying on the gate, run it once in dry-run mode. A dry run checks authentication, the Region, and that your repository resolves—without starting a scoped penetration test job. If validation fails, the step fails regardless of your error-handling settings, so a misconfiguration surfaces immediately.
A worked example: GitHub Actions
The following workflow shows the three-job topology that makes the gate work: deploy deploys to staging, security-pentest runs the gate, and deploy-prod promotes to production. Because deploy-prod declares needs: [security-pentest], GitHub skips production whenever the gate fails.
Note: The tutorials use an application with a deliberate SQL injection so the gate has a real finding to block on. Deploy it only to an isolated, non-production environment and remove it when you finish.
Replace the account ID, role name, Region, and the as-/pt- identifiers with your own values.
Two things in this example deserve attention. First, the contents: write permission lets the gate advance the baseline marker it keeps as a ref in your repository—without write access, every run would test a wider range than intended. Second, the role-duration-seconds: 7200 on the credential step must outlast the penetration test; AWS STS rejects a request for more than the role allows rather than reducing it, so set the role’s maximum session duration to at least (timeout + 10) x 60 seconds. A credential that expires partway through makes an otherwise-healthy run fail as though the service were at fault and leaves the cleanup unable to stop the abandoned, still-running job.
The full step-by-step tutorials for all four providers are linked at the end of this post.
Rolling out the gate: from report-only to blocking
The single most important detail before you roll this out.
Three independent settings decide whether the step fails, and each covers a different outcome: severity-threshold (what happens to findings), on-scope-conflict (what happens when the change wasn’t tested), and fail-on-infrastructure-error (what happens when the job couldn’t run). They are independent—relaxing one does not affect the others.
Most teams introduce the gate in report-only mode first—set threshold to NONE so the test runs and publishes findings without blocking anyone’s pipeline. Watch what it finds for a release or two, then tighten the threshold to HIGH. This staged rollout is sound, with one critical caveat:
A run that passes—including a report-only run—advances the baseline. The commits in that run’s range are then recorded as cleared and will not be re-tested when you later tighten the threshold. If you run report-only for a month and then switch to HIGH, the gate only assesses commits after the last report-only run—it does not go back and recheck what it already reported on.
This is by design: relaxing a setting is you accepting the outcome it allows. But if you want a stricter setting to reassess a range an earlier run cleared, override the head and base commit SHAs by settingbase-commit-shaandhead-commit-sha. Where the marker lives differs by provider; see What advances the baseline, and why that matters for the full matrix.
One default also deserves attention: fail-on-infrastructure-error ships as false (fail-open). For pipelines where promotion requires security sign-off, set it to true from the start.
GitLab: your committed settings are defaults, not a contract
On GitLab CI/CD, a pipeline variable overrides the value a job sets in its own variables: block. That means anyone who can run a pipeline could supply a variable that lowers the threshold, turns on dry-run, or relaxes error handling—and the gate does what the variable says, not what your .gitlab-ci.yml says. Restrict who may override variables in your project’s CI/CD settings before you rely on the gate to hold a release.
Protecting credentials on the runner
The temporary credentials and OIDC token are sensitive for the duration of the step. Three practices matter:
Keep debug and verbose tracing off for steps that handle credentials—shell-trace modes (for example, GitLab CI’s CI_DEBUG_TRACE) echo command arguments to the job log in plaintext.
Don’t persist source control credentials in the workspace—set persist-credentials: false on the checkout step so a token isn’t written to the runner’s .git configuration where a later step could read it.
Don’t expose the token to untrusted steps—grant OIDC-token permission only to the jobs that need it, and don’t run untrusted code (such as a fork build) in a job that can read the token.
Taking this to production and multiple accounts
The example uses one account for clarity. In practice, your staging and production environments are often separate AWS accounts. The pattern extends cleanly:
Create the pentest-gate IAM role in the account where the penetration test and Agent Space live—the security account. Your pipeline assumes that role via OIDC regardless of which workload account it deploys to, so you keep one well-scoped gate role rather than a copy or a set of long-lived keys in every account.
Run the gate against each pre-production environment you promote through, and gate promotion to the next stage on its result. Because the baseline advances only on a passing gate, coverage stays continuous across deploys.
Set fail-on-infrastructure-error to true and restrict who can override pipeline variables once the gate is holding real releases.
Pin the integration version so upstream changes are reviewed before they run.
For broader guidance of AWS Security Agent—testing against non-production environments, validating AI-generated findings, and IAM—see Security best practices for AWS Continuum.
Cleanup
If you followed one of the provider tutorials to try the gate, complete its Clean up section to remove everything it had you create: the sample application’s staging environment, the IAM role and OIDC identity provider, and—if you created one specifically for the walkthrough—the penetration test (and dedicated Agent Spaces) in the Continuum for penetration testing console. Removing them avoids ongoing charges and takes the intentionally vulnerable sample application offline.
Conclusion
Scoping penetration tests to the deployed change is what makes them practical as a per-deploy gate rather than a quarterly exercise. The key decisions you now have are:
How strict: Start report-only (NONE), but know the baseline advances—delete the marker when you tighten.
How to fail: Set fail-on-infrastructure-error to true for anything that requires security sign-off.
How to scope trust: Pin the sub claim as narrowly as your deployment reality allows.
Where to put the role: One role in a security account, assumed from workloads pipeline via OIDC.
To build the gate end to end on your platform, follow the worked tutorial for your provider:
The motivation for building the Netflix Foundation Model for personalization was laid out in this previous blog post. The Netflix homepage is powered by several specialized models and it requires significant time and resources to maintain and continue innovating on these individual models. Therefore, we decided to centralize member preference learning and have one powerful model learned from comprehensive user interaction histories and content data at a large scale and have this model distribute its learnings to other models.
The previous two blog posts(1, 2) focus on the development of the Foundation Model and here we talk about how we integrate the Foundation Model into various applications. We found that there is extensive literature focused on the training and inference of large-scale transformer-based models. However, there remains a significant gap in practical guidance and research on how to effectively and efficiently integrate large models into existing production systems. At Netflix, we experimented with 3 distinct integration approaches — embeddings, subgraph and fine-tuning. The motivation for trying different approaches stems from varying application needs. Specifically, different teams have different latency requirements, tech stack constraints and different appetites for leveraging the full power of a large foundation model.
In this blog, we go over the 3 approaches we experimented with and which are now used in production for different use cases. Each integration approach has its own set of motivations, tradeoffs, complexities and learnings. The following sections go into the details of each of these integration approaches.
Embeddings from Foundation model
Transformer style foundation models naturally lend themselves to generating comprehensive user profile and item representations. Our approach for generating embeddings includes getting the hidden state of the last user event as the profile embedding and weights from the item tower as item embeddings.
Netflix has an elaborate set up for refreshing the embeddings every day. First, the Foundation Model is pre-trained from scratch every month. Then, the monthly pre-trained model is fine-tuned everyday based on the latest data. The daily fine-tuning also expands the entity id space to include the newly launching titles. After the daily fine-tuned model is ready, we run batch inference to refresh the profile and item embeddings and publish them to the Embedding Store.
An important part of this setup is the embedding stabilization technique (paper). When the pretraining job retrains the model from scratch, the embedding spaces between different runs are completely different due to the random initialization in the model. In addition, the embeddings start to drift when the daily job fine-tunes on the latest data, despite the daily fine-tuning job warm-starting from the previous day’s model. Therefore, it is important to map the embeddings generated everyday into the same embedding space, so that downstream models can consume pre-computed embeddings as features.
This embedding approach relies heavily on the Embedding Store, which is a feature store specializing in embeddings built by the platform team at Netflix. The embedding store makes producing and consuming embeddings easy by taking care of versioning and timestamping the embeddings. The Embedding Store also provides various interfaces to access the embeddings offline and online.
Embedding Store integration
This approach is often the initial and most straightforward way for applications to interact with the Foundation Model. Embeddings can serve as powerful features for other models or for candidate generation, helping to retrieve appealing titles for a user or facilitate title-to-title recommendations. Integrating embeddings as features into existing pipelines is generally well-supported and offers a low barrier to entry. Compared to other integration approaches, using embeddings from the Embedding Store is expected to have a relatively smaller impact on training and inference costs.
However, this approach also has some cons. The time gap between embedding computation and downstream model inference can lead to staleness, impacting the freshness of recommendations. This may prevent applications from fully unlocking the benefit of the Foundation Model, especially for use cases requiring real-time adaptability.
Overall, the default starting point for leveraging the Foundation Model is through its profile and item embeddings via the Embedding Store, provided that the embeddings’ freshness and stability meet application-specific needs. While embeddings may not leverage the full power of the Foundation Model, they offer a good initial step.
Our biggest learning from working on this approach is that embeddings are a low cost and high leverage way of using the Foundation Model. A resilient embedding generation framework and embedding store are essential for updating the embeddings daily and serving them to application models. We found this infrastructure to be so valuable that we stepped up our investment here to build a near-realtime embedding generation framework. This new framework also enables us to update the embeddings based on user actions during the session, making the embeddings and our downstream models more adaptive. Although the near-real time framework cannot be used for very large models, it represents an important direction for addressing embedding staleness and adaptiveness of recommendations.
Foundation Model as a Subgraph
This approach involves using the Foundation Model as an input to the downstream model i.e. the Foundation Model decoder stack is a subgraph of the application model’s full model graph and hence the name “subgraph integration”. The Foundation Model subgraph processes raw user interaction sequences and outputs representations that are then fed into the downstream model graph.
Foundation Model Subgraph integration
Applications can fine-tune the Foundation Model subgraph as part of their own training process, potentially leading to better performance than just using static embeddings. In this approach, there is no time gap or staleness between the Foundation Model inference and the application model’s inference, ensuring that the most up-to-date learnings are used. This approach also allows applications to leverage specific layers from the Foundation Model that may not be exposed through the Embedding Store, uncovering more application-specific value.
However, the subgraph approach comes with some complexities and trade-offs. To use the Foundation Model as a subgraph, application models need to generate all the features necessary for the subgraph as part of their feature generation process. This can add time, compute and complexity to their feature gen jobs. Merging the Foundation Model as a subgraph also increases the application model size and inference time. To alleviate some of these complexities, the Foundation Model team provides some reusable code and jobs that make the feature generation more compute efficient. To optimize the inference performance, we split the subgraph and ensure it only runs once per profile per request and is shared by all items in the request.
Overall, the subgraph approach allows for a deeper integration and enables the applications to harness the full power of the Foundation Model. But it can also make the application’s training code more complex, requiring a trade-off between metric improvement, compute cost, and time. Therefore, we would reserve this approach for high impact use cases where the increase in metric wins compensate for the cost and complexity.
Fine-tuning Foundation Model and use directly
This approach is similar to fine-tuning LLMs with domain specific data. In the previous blog post, we described how the Foundation Model is trained on a next-token prediction objective, with the tokens being different user interactions. Different interactions are of different importance to various surfaces on the Netflix website. For example, for the ‘Trending now’ row, recent interactions on trending titles might be more important than old interactions. Hence, the Foundation Model can be fine-tuned on more product specific data and then the fine-tuned model can be used to directly power the product. During fine-tuning, application teams can choose to do full parameter fine-tuning or freeze some layers. They can also choose to add a different output head with a different objective. We built a fine-tuning framework to make it easy for application teams to develop their own custom fine-tuned versions of the Foundation Model.
Fine-tuned Foundation Model Integration
This approach offers the ability to adapt the Foundation Model to application’s specific data and objectives, making it optimized for their use case. A side benefit of this integration approach is that it provides a de facto baseline for new models/applications. Instead of coming up with a new model stack and spending months on feature engineering, new applications can directly utilize fine-tuned foundation models. However, this approach can lead to more models and pipelines to maintain across the organization.The latency and Service Level Agreements (SLAs) of the fine-tuned model must be carefully optimized for the specific application use case.
Conclusion
We are continuing to innovate on these integration approaches over time. For example, the Machine Learning Platform team is working on near-real time embedding inference capabilities to address the staleness issues with the embedding approach. We are also working on a smaller distilled version of the Foundation Model to reduce the inference latency of the subgraph approach. We also provide a fine-tuning framework to make it easy to fine-tune and leverage the Foundation Model. We also continue to refine and standardize the APIs used in these approaches to make it easy for application teams to use them. Overall, these three integration patterns provide a comprehensive framework for how Netflix applications can interact with and extract value from the Foundation Model.
Acknowledgements
We thank our stunning colleagues in the Foundation Model team for developing and continuing to innovate on the Foundation Model. We thank our colleagues in the AIMS applications teams for driving the integrations and their valuable feedback and discussions. We also thank our Machine Learning Platform team for building and supporting the infra components to get these approaches up and running in production.
Our Netflix journey from data to dashboards, particularly within the space of the experimentation platform, always presented a unique set of challenges. This blog post aims to illuminate these hurdles and explain how an innovative open-source metric platform became instrumental in overcoming some of them. We’ll showcase the critical role that DataJunction played in streamlining our data workflows and enhancing our ability to derive meaningful insights from our vast datasets.
Metrics are the foundation of data-driven decision-making, but at many organizations, they are scattered, inconsistently defined, and difficult to discover or trust. At Netflix, this challenge first became apparent in our experimentation platform, where reliable metrics are essential for interpreting test results. But the complexity of the original tooling made it very difficult to understand and introspect these metrics both in terms of their definitions as well as their values.
Initial Problem
Scattered metric definitions, redundant datasets, and pipelines are often a natural effect of a fast-moving company with a large and powerful analytical workforce. This is a common problem in big data-driven firms, and it is not easy to solve across multiple departments, which are often governed by somewhat different rules and regulations. An easy-to-use, well-governed, and centralized semantic layer can help with these issues. Our initial problem was most evident in our Experimentation Platform team, where the previous system required:
extensive business knowledge
familiarity with experimentation conventions
and complex engineering practices
This led to metric authoring processes that would take weeks, which was a prohibitive requirement for Data Scientists and Analytics Engineers who wanted to onboard new metrics to the Experimentation Platform.
Enter DataJunction
To address this problem and to set ourselves on the path to a successful semantic layer solution in the future, we looked at several candidates. Among other solutions we evaluated Mando (an internal framework), Minerva (an open source semantic layer from AirBnB), and DataJunction (another open source solution, “DJ” for short). All of them had some strength, but DJ offered one thing that the others did not at the time: a solid SQL parsing and SQL generation engine. At the time of the POC, DJ was also the only open-source solution that stored all its definitions in a connected graph, similar to how relational databases store metadata on their views and queries. Easy “SQL wrangling” with rich metadata was the main feature that convinced us to try it for our immediate use case.
DataJunction originated from a similar internal Facebook project created (around 2015) by the data science and infrastructure (DSI) team, mainly as an answer to the need for metrics portability. During several iterations of the Deltoid project — which was the main experimentation platform at Facebook at the time — users were required to rebuild and repopulate their metrics when they wanted to move to the next version of Deltoid. But after implementing DJ and abstracting all metric definitions the team offered seamless migrations by separating the concerns between the metrics and the stats computation platform. That project was subsequently renamed to MDF (Metrics and Dimensions Factory) and promoted as a generic semantic layer used widely by various departments. In 2021, one of the Facebook engineers (Beto Dealmeida), started the DJ Github project and built out some basic functionality. Then together with some folks at Netflix expanded the scope further, and soon after that the project was introduced at Netflix. Following that introduction, three Netflix engineers (authors of this blog) together with a couple of external contributors, most notably Nick Ouellet, have been building out the remaining features of the platform.
Architecture Decisions
A critical design constraint for building DJ at Netflix was resource scarcity. We refused to compromise on product quality, choosing instead to limit the feature set. Although DJ was clearly capable of addressing many simultaneous problems across diverse use cases, our lack of adequate resources and official support meant we developed it as a side project for over two years. Our hope was that demonstrating its value would eventually secure management attention.
API First, UI and Other Interfaces Later
A metrics platform doesn’t need a flashy front-end to deliver value — its core is the semantic layer, which stores a consistent set of dimensions and metrics and serves this information through a rich API service. You can see below how we structured the main components of DataJunction in the Netflix implementation. Our DJ services (in the middle) interact with the underlying data (on the left) and supply our access layer with the business definitions in the form of SQL w/ metadata or directly with data depending on the client request.
Consistent Graph First, Other Features Later
A complete semantic layer system can seem like an octopus, with its tentacles reaching out into many functional areas and can expand from a basic semantic metadata stored for some datasets to full dashboard functionality. Let’s call out some of them:
semantic metadata authoring and management and monitoring
metric and dimension query / definition generation
metric and dimension data generation (requires a query engine)
data visualization and data tracking
performance optimization (aka caching or materialization)
integration layer with other tools and
any / all the above functionality served as: UI, API, client libraries, MCP servers and more.
Of course it is extremely hard to provide the best in class functionality across all these layers, so with our small “unofficial” team we decided to focus on the most important piece: solid semantic layer engine (and API) with the ability to parse SQL as the input to the graph and generate SQL as the serving layer. That is the core of the system and everything else can be added later with less effort and w/o the need to rebuild the core.
Cube as The Perfect Consumption Protocol
Analytical multi-dimensional cubes have been a fundamental concept for decades, with their representation integrated across various data processing and analysis platforms. While definitions and features may vary between tools, they all serve the common purpose of encapsulating, or abstracting, a subset of semantic objects.
In DataJunction, we adopted cubes as first-class features for two main reasons: their familiarity to users and their suitability as a serving interface. They efficiently deliver both the semantic definitions (of metrics and dimensions) and fast data access. See an example of data “flow” graph (dotted lines) and dimensional relationships graph (solid lines) below.
We simplified the creation of basic cubes, allowing them to easily aggregate arbitrary collections of shared metrics and dimensions. Furthermore, accessing, managing, and visualizing these cubes is straightforward for any client integrating with DJ. Custom integrations, such as for Netflix’s internal fast Druid data analysis tool (Data Explorer → see below), became trivial to build, and we also made it easy to materialize these cubes directly in our Druid clusters.
One of DJ’s most powerful client integrations is the ability to link any DJ-originating metric definition back to the DJ ecosystem. This creates a valuable feedback loop: troubleshooting and introspecting business dashboards becomes simple if they display DJ-defined metrics that include links back to the definition source. This link then makes inspecting and running ad-hoc analysis, by modifying existing metrics, a trivial process. This integration is not only possible with our inhouse tools, but also with other well known open-source products, like Superset.
Experimentation at Netflix
Metrics are the backbone of experimentation. They translate data into signals that tell us whether a change is meaningful, safe, and worth scaling. Without trustworthy metrics and dimensions, experiments risk becoming inconclusive or misleading, so a robust metrics layer becomes crucial for data-driven decisions.
At Netflix, the original metrics layer integrated into the experimentation platform was overly complicated. Creating new metrics not only required tribal knowledge of experimentation data artifacts, but also familiarity with complex engineering workflows. This unnecessary friction meant that onboarding a single new metric could take weeks, slowing adoption of new metrics and hindering experimentation.
This is where DataJunction comes in: it provides a central hub for defining metrics and dimensions that can easily be shared and explored via the semantic graph. It also provides flexible, user-friendly interfaces (including a UI, API, and various clients), making it easy for users to author and manage their metrics and other semantic models.
Conclusions
With experimentation domain well supported by DataJunction, we would like to take on next steps to unifying of the general analytics at Netflix and to make it easier for Netflix users to both:
find and use metric definitions across verticals (defined in DJ)
easily access, modify and experiment with new metrics across Netflix data stack
That will require building out strong integrations between DJ and other tools, but that has been underway and it is one of the most enjoyable parts of this project, where most of the feature exists and we are simply enabling existing systems to exchange information in a structured and reliable way. With a system like DataJunction our internal LLMs can deliver accountable information about the business metrics as well as explanation of how they are defined and used across Netflix.
By Kevin Zielnicki, Guy Aridor, Aurélien Bibaut, Allen Tran, Winston Chou, and Nathan Kallus
Introduction
Personalization is everywhere on the internet. It shapes the products we discover, the stories we read, the music we hear, and the movies and TV shows we watch. At Netflix, personalization has been central to the member experience for decades — from the Netflix Prize to our modern recommender system that helps members navigate a large and constantly changing catalog.
But personalization is not only an algorithmic problem, it is also a measurement problem. How do we know how much value personalization creates? More precisely, how do we separate the appeal of a title from the value created by recommending that title to the right member at the right time?
In a new article in the International Journal of Industrial Organization — which we are also presenting at this year’s ACM Conference on Economics & Computation (EC ‘26) — we develop a model of member behavior, title choice, and personalized recommendations. The model lets us estimate how recommendations affect both whether members choose to watch and, if so, which titles they choose. In this post, we summarize our approach and main findings.
The Measurement Challenge
A natural first attempt at valuing recommendations is to ask: what share of viewing comes from titles that were recommended? This is an intuitive metric, but it fails to answer the causal question at hand.
The problem is that recommendations are not randomly assigned. A title appears on a member’s homepage precisely because the recommender system predicts that the member might want to watch it. If a member watches that title, was it because the recommendation caused the member to watch it? Or would she have watched it anyway because of her underlying preference for that kind of title? This is the core measurement challenge: recommendations are targeted to demand, so viewing a recommended title combines the effect of personalization with the member’s underlying preferences.
One way to solve this would be to run a large experiment that replaces Netflix’s personalized experience with an unpersonalized one. That would create clean variation — but it would also be a poor member experience. Personalization is a central part of how members locate valuable titles in a large catalog, so turning it off broadly is not an acceptable measurement strategy.
Instead, we take a hybrid approach. We build a behavioral model that separates members’ underlying preferences from the incremental effect of recommendations. The model uses the natural variation in the recommendation system, for example due to algorithmic exploration, to estimate how recommendations affect choice. Then, to validate the model predictions about title substitutability, we use small-scale A/B tests that “nudge” the salience of a handful of titles exogenously, generating ground-truth substitution patterns for a subset of titles. This lets us combine the scale and richness of modeling with the credibility of experimental evidence.
A Model of Member Choice
To measure the value of personalization, we need a model of what members would watch under different recommendation systems. Our model treats Netflix viewing as a day-by-day choice process. On each day, a member chooses among the titles available in the catalog, or she chooses not to watch anything. This gives us a concrete target to estimate: the probability that a member watches each title on a given day, as a function of their preferences, their viewing history, and the recommendations they see.
A simple version of this model would be too restrictive. It might assume, for example, that removing one title from the catalog shifts viewing toward all other titles in roughly proportional ways. But that isn’t how member choice works. If a member is considering a romantic comedy, the closest substitutes are likely other romantic comedies, not every title on Netflix equally. For similar reasons, two members may react very differently to the same recommendation.
To capture this complexity, we use a low-rank choice model. The model learns a representation of each title and a corresponding representation of each member’s current preferences. These representations are not limited to manually specified features like genre, cast, or language. Instead, they are learned from viewing behavior itself, allowing the model to capture nuanced similarities between titles that may be difficult to describe with coarse features, such as genre or release date, alone.
Our Model Attributes Choices to Dynamic Member-Title Affinity and the Effect of Recommendations
Member preferences are dynamic. What someone wants to watch today depends on what they have watched recently. A member who just finished a crime thriller may be in a different preference state than the same member after watching a stand-up special or a kids’ movie. Rather than estimate a fixed preference vector for each member, the model summarizes each member’s past viewing history into a current preference state. This lets us capture heterogeneous and time-varying tastes while also scaling to millions of members.
Our Model Architecture Allows Us to Scale to Millions of Members Efficiently
The key component for our purposes is that the model explicitly parameterizes the effect of recommendations. When a title is recommended, the model gives it an additional recommendation effect, or “bonus,” that increases its probability of being chosen. This bonus is a reduced-form way to capture two related mechanisms. First, recommendations can create awareness by helping members discover titles they may not have known about. Second, recommendations can provide information by signaling that a title is likely to be a good match.
Once estimated, the model becomes an engine for predicting counterfactuals. We can ask what would happen if a title were not recommended, if a different set of titles were recommended, or if the current recommender system were replaced with simpler alternatives. Because the model separately represents member preferences, title appeal, and recommendation effects, it lets us estimate not only how recommendations affect total viewing, but also how they change which titles are watched.
The model is only useful, however, if it captures real substitution patterns. The next step is therefore validation: comparing the model’s predictions to randomized experiments that directly perturb, on a small scale, the visibility that each title receives.
Validating the Model with Randomized Experiments
The model relies on an important assumption. After conditioning on the member, title, and state information available to the recommender system, we treat the remaining variation in whether a title is recommended as if it were randomly assigned. In our setting, this assumption is reasonable: we observe all of the information available to the recommender system, so we should be able to model its behavior accurately. But it is still an assumption. A useful model should not only fit historical viewing patterns; it should also predict what happens when recommendations change for external reasons.
Thus, to validate the model, we used randomized experiments that introduce variation in title visibility exogenously. These experiments mirror the kinds of variation that occur routinely when recommendation algorithms are updated: some titles receive more impressions, while others receive fewer. The key difference is that, in the validation experiment, this variation was prespecified so that we could estimate clean experimental benchmarks.
Specifically, we randomly assigned members to treatment arms that slightly nudged recommendations towards and away from different categories of titles. This let us measure diversion ratios: when a set of titles becomes less visible, how much viewing shifts to other titles, and how much shifts out of Netflix viewing altogether?
We then asked whether the model could reproduce those experimentally measured substitution patterns. We estimated the model on the control group, simulated the same recommendation changes, and compared the model-implied diversion ratios to the experimental ones. The agreement was strong: the model’s predicted diversion ratios had a correlation of 0.86 with the experimental estimates and an R-squared of 0.73.
Our Model Predicts Out-of-Sample Experimental Diversion Ratios Well
This validation gives us confidence that the model captures counterfactual substitution patterns accurately. Subsequently, we ask what would happen under more dramatic changes, such as different recommender systems.
Counterfactuals: Aggregate Consumption and Diversity
With a validated model in hand, we can move from measurement to counterfactuals. Instead of asking only what happened under the current Netflix experience, we can ask what would have happened if members had seen recommendations generated by a different system.
We compare the current recommender system to three baselines:
The first is random recommendations: every member receives titles selected uniformly at random from the catalog. This is not intended as a realistic product experience, but it helps isolate the value of having recommendations that are relevant.
The second is popularity-based recommendations: every member receives broadly popular titles. This is a natural non-personalized benchmark.
The third is a basic matrix factorization model, a classic personalized recommendation approach and a useful baseline for older generations of recommender systems.
In each counterfactual, we replace the recommended titles while keeping the rest of the choice environment fixed. This lets us estimate how much viewing would change if the recommendation policy changed, holding constant the catalog, members, and model of member choice.
The results show that the current recommender system generates substantially more engagement than each benchmark. Relative to the current system, random recommendations reduce engagement by 16%, popularity-based recommendations reduce engagement by 12%, and matrix factorization reduces engagement by 4%. These are large differences at Netflix scale. Even the comparison to matrix factorization — a personalized baseline — suggests that continued improvements in personalization translate into meaningful gains in how effectively members find titles they want to watch.
Personalized Recommendations Increase Engagement and its Diversity
Engagement is only part of the story. A recommender system could increase viewing while concentrating attention on a narrow set of already-popular titles. That would be a worse experience for members whose tastes are not well represented by those titles, and it would make poorer use of a broad catalog.
We therefore also examine consumption diversity: how broadly viewing is distributed across titles. The current system performs well on this dimension too. Popularity-based and matrix-factorization recommendations both substantially increase concentration, meaning that fewer titles receive meaningful viewership. Random recommendations produce slightly more diversity, as expected, but at a large cost to engagement.
Taken together, these counterfactuals show that the value of personalization is not just that members watch more. It is also that members are matched to a broader set of titles. The current recommender system increases engagement while preserving a wide distribution of viewing, reflecting the diversity of member tastes across the Netflix catalog.
Decomposing the Impact on Titles
The aggregate counterfactuals show that personalization increases engagement while maintaining broad consumption across the catalog. We can also use the model to ask a more granular question: why does a recommended title get watched?
There are three conceptually distinct channels:
The first is exposure: simply showing a title to a member can increase the probability that the member watches it. This captures the basic value of surfacing a title that may otherwise have been hard to find.
The second is selection: recommended titles are shown to members who already have a relatively high baseline probability of watching them. This channel doesn’t lead to incremental engagement, but it can smooth the discovery experience and help users feel that the recommender system understands their preferences.
The third is targeting: the recommender system may identify members for whom the recommendation itself is especially effective, meaning members who are much more likely to watch the title when it is recommended than when it is not.
The distinction matters because not all recommendation-driven viewing should be interpreted the same way. If recommendations worked only through exposure, then any reasonably visible surface could generate much of the same value. If they worked mostly through selection, then recommendations would mainly be finding members who were already likely to watch a title. Targeting is different: it captures whether the system is placing titles in front of members for whom the recommendation changes the decision.
Decomposing the Impact of Recommendations into Selection, Exposure, and Targeting
Our model lets us estimate these channels title by title. For each title, we can compare the predicted probability that a targeted member watches it when recommended to the probability that an average member watches it when not recommended. We then decompose that difference into selection, exposure, and targeting.
We first show that exposure is meaningful: showing a title to an average member roughly triples its consumption probability relative to the baseline. Exposure is not the main driver of differences in consumption, as mechanical exposure explains only about 7% of the gap under the current recommender system, while selection and targeting account for the vast majority of the difference and the targeting effect is nearly seven times larger than the exposure effect.
This pattern is especially informative when compared with simpler recommendation systems. Random recommendations are dominated by exposure because they do not personalize: differences in consumption mostly reflect differences in what titles are shown. Matrix factorization changes this by making recommendations personal, reducing the role of exposure and leaving exposure, selection, and targeting to contribute nearly evenly to consumption differences. The current recommender system goes further: its gains come less from mechanical exposure, but more from targeting the right titles to the right viewers.
Targeting is also not uniform across the catalog. It is strongest for mid-popularity titles: titles with enough potential audience to be broadly relevant, but not so much mass appeal that everyone already knows about them. Very popular titles need less help from targeting, while very niche titles may have too small an audience to target effectively. The largest gains come from the middle of the catalog, where personalization helps connect specific titles with specific member tastes.
Personalized Recommendations Give the Strongest Boost to Medium-Popularity Titles
Conclusion
Personalized recommendations are valuable because they help members navigate a large catalog and find titles they want to watch. They are also valuable to Netflix because they make the service more useful, more engaging, and better able to serve a wide range of tastes.
But measuring that value is not straightforward. Recommendations are targeted by design, so we cannot simply compare recommended and non-recommended viewing. At the same time, turning off personalization at scale would create a worse member experience.
Our approach combines a large-scale model of member choice with true experimental validation. The model lets us separate underlying title preferences from the incremental effect of recommendations, and the experiments verify that the model captures real substitution patterns.
Using this framework, we find that personalization affects both how much members watch and which titles they watch. The value of recommendations comes not just from exposure, but from matching the right titles to the right members.
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.