Release notes

Everything built for the Microsoft Marketplace listing — the buyer landing page with Microsoft sign-in, the fulfillment webhook, the metering and reconciliation jobs — has been in every release since 10.12.0, but the deploy never told the Manager which Entra tenant and apps to talk to. On staging and production the landing page answered "Setup isn't available just yet", the webhook rejected every token and the metering jobs returned quietly. All of it was live code doing nothing.

Building a full local test harness for the reusable-templates work meant driving every existing journey end to end with synthetic accounts, and that shook out a handful of real defects in code that has been live for months. None of them needs the templates feature, so they ship first, on their own.

Until now the only way to drive the platform from Claude was a tool running on one laptop that logged in by typing an administrator's email and password into the login page. That could never be given to a client, could never run anywhere but that laptop, and would have broken the moment two-factor authentication became compulsory. The Manager is now its own OAuth server: an app such as Claude registers itself, sends the admin through the normal FANDEMiQ login, and is granted access only to the accounts that admin ticks — so connecting an agent for one club does not hand it the other three. Nothing can be connected without two-factor authentication turned on, and if two-factor is later switched off, the connection stops working at its next token refresh.

Before a fan accepts a photo, the Camera App now checks it on their phone. If it is clearly blurry, too dark, washed out, or a file they have already sent this visit, one line on the review screen suggests taking it again. It is advice, not a bouncer: Accept always works, nothing measured leaves the phone, and there is no face or person detection. Separately, an Enhanced AI (Tier 2) FanMoment used to cut the fan out of their photo twice, once for a fallback picture it then threw away, so every paid moment spent about eleven seconds of the platform's slowest step on nothing. It now cuts out once. And the Camera App's scripts and styles were reaching fans uncompressed, about a megabyte more than needed on a stadium network; they are now compressed at the edge.

After fixing FanMoments and fan walls we checked everything else a deleted campaign or event leaves behind. Several paths still ignored the deletion. The background job that retries unsent emails would still email a fan their personalised story or fan wall. The fan's share link kept working. A film or audio mix already queued still rendered. A Smart Films request picked up just after a deletion still planned a film, and that planning costs OpenAI money. A story recipe filtering on a deleted campaign kept making and emailing stories. That last one was deliberate until now; it now stops, as agreed. None of this was happening on production, where no content sits under a deleted campaign or event. Restoring a campaign or event brings everything back.

After the FanMoment fix we checked everything else that hangs off a campaign. Fan walls had the same gap. Deleting a campaign leaves its walls in place with their switches on, so a wall set to fill automatically, start the next wall in a series, or refresh every half hour kept doing it. The AV hand-off page also kept listing that campaign's walls and films and emailed the AV team when they finished. None of this was happening on production (no walls or films sit under a deleted campaign there), but it would have the first time someone deleted a campaign with a live wall. The automatic wall jobs and the AV page now treat a deleted campaign or event as "stop". Restoring the campaign picks everything up again.

Fans on one event got two FanMoment emails, one of them from a campaign deleted long ago. Deleting a campaign only marks the campaign as deleted; its FanMoment stays switched on. The live FanMoment job only checked the FanMoment's own switches, so the deleted campaign kept making its picture for every fan it matched, and the email went out with it. The job now ignores FanMoments whose campaign or event is deleted. The email sender and the re-delivery sweep also refuse pictures already made for one.

The Clip Info popout asks the server which films, fan walls and audio mixes use a clip. That endpoint never checked whose clip it was, so any signed-in Manager user could type in other clip numbers and read the names of another account's films and fan walls. It now answers "not found" for any clip that isn't on one of your events, the same way every other clip action already did.

The Clip Manager only ever listed videos, so there was no way to delete photos in bulk, and the Content page never had a delete button at all (the help said it did). The Clip Manager now has Videos and Photos tabs: list, delete, restore and purge photos one at a time or in bulk, the same as clips. A photo still on a fan wall is refused on purge, and the reason is shown. Separately, on a rolling fan wall series that allows repeats, the fans who uploaded since the last wall now always get a tile on the next one; older clips only fill the space left, and the new fans are spread across the grid rather than grouped in the top rows.

A fan wall can now be given a name, just like a story or a FanMoment. The AV hand-off hub shows that name instead of "Video wall #8", which told the AV desk nothing about which wall was which. A wall with no name is shown by its grid and length, for example "5x7 · 20s" (a photo wall just "5x7"), and the editor's Name box shows that default as its placeholder. Each new wall in a rolling series is named after the first wall with its number, "Goal cam (wall 2)", so a series never lists as several identical entries.

A fan wall set to generate automatically can now keep going. Set Maximum walls and, once the first wall is built, another is built every time a full grid of new clips is available, until the maximum. With Exclude clips used in other fan walls on, each new wall only uses clips no wall has used yet; with it off, a new wall arrives after every full grid of uploads and clips may repeat. Each wall is its own fan wall, so earlier walls, their AV hub entries and share links are never overwritten. Separately, an automatically filled wall no longer zooms onto a silent clip: the fill now puts a clip with sound in the zoom position, closing the gap that sent prod's mosaic 8 fading into silence. A new Zoom to a random fan each time the wall is generated option picks a different fan with sound on every render.

Every AV hand-off link now carries a "What fans are saying" panel: the question, a one-line headline and up to five themes with their share, read straight from the same cached answer summaries the Manager's Answers report and the live dashboard already use — nothing here ever asks the model to build a new one. On a link with Show uploader emails switched on, each theme also carries a couple of verbatim quotes, and an "Answers" toggle opens the individual transcribed answers with a filter box, so the AV desk can pick a fan to feature. Each answer links straight to the tile it appears on in any fan wall, opening the uploader view already scrolled to and highlighting that tile. The uploader view itself now shows each fan's own answer under their tile, and the tile search matches it. Every piece of AI-written or fan-spoken text — theme labels, the headline, quotes, transcripts — is screened by the same rule the camera app's typed answers and live dashboard already use: the account's profanity list first, then Azure AI Content Safety when it's configured, with anything flagged or unscreenable simply left off the page.

A revoked or expired AV link used to land the AV team on the browser's bare "page can't be found". It now shows a FANDEMiQ page that says so with a smile and tells them to ask the event team for a fresh link. Deliberately, it is the same page for every dead link, whether it was revoked, expired, regenerated or never existed, with no account name or branding on it. A mistyped or guessed link therefore reveals nothing about which links once worked or whose they were, and it still answers with a 404. The open hub's own "no longer active" message now uses the same wording.

On staging the fan wall editor showed a broken image on every tile, although each clip's stills were in storage. Every staging deploy had been writing an empty storage address to the three staging apps. So every signed media link (clip stills, wall thumbnails, downloads) pointed at the Manager's own site instead of blob storage. The staging configuration step had been split in two to stay under GitHub's size limit, and the storage address stayed defined in the first half while only the second half used it. Each step runs in its own shell, so the second half saw nothing, and nothing complained. Production defines and uses it in the same step and was never affected.

On staging, every upload using one tester's email failed, while uploads with any other email worked. Two identity records shared that email, and the upload looked the fan up expecting exactly one. With two it threw "Sequence contains more than one element", after the clip or photo row had already been saved. So the fan saw a failed upload, and an uploader-less row was left behind. Duplicates can happen without a bug in that lookup (two first uploads at the same moment, copied accounts), so it now uses the oldest matching identity and logs a warning naming both, so they can be merged. The staging duplicate has been merged.

The AV hand-off page has been rebuilt from the "AV Hand-off Hub" design: dark by default for a control room, the account's logo and brand colours in the header, Ready outputs first and loudest, walls grouped by event on a group link, a pulse on anything that became ready while the page was open, and clear states for "nothing yet", "couldn't refresh" and "this link is no longer active". Every fan wall now has View uploaders: its tiles in order, each with a still and upload time, the tile the wall zooms into highlighted, and a search by tile number, so the AV desk can match the tile on screen to a person on the day. Uploaders' email addresses appear only on links created with Show uploader emails. Anyone holding such a link sees every uploader's email, so it can stay open at most 48 hours after the event ends and says "don't forward it" at the top.

stagcam.fandemiq.net sat on its loading dots for ever: it was never on staging PublicAPI's CORS allow-list, so the browser refused the app's very first API call. Testers had to use the raw storage address instead. Staging only; production's camera address was never affected.

Whoever plays the fan wall on the stadium screen is rarely whoever set the event up in the Manager, and until now the only way to get them a video was to wait for the render and forward a signed-in download link by hand. An admin can now create an AV hand-off link for one event or one event group — no login, no PIN — from a new AV hand-off panel on the event editor (Sharing tab) and the event group editor. The page it opens (/av/{token}) lists every full wall and film in scope with a thumbnail, its status, and MP4/ProRes/MXF downloads that refresh themselves every 30 seconds and always resolve to the latest render. When a full wall or film finishes, everyone on the link's notify list gets an email. While building this we also found and closed a real gap: FilmsApiController.FilmFile had no ownership check at all, so any signed-in user could download any account's film by guessing its id.

The Help page has always said every typed fan answer gets an AI content-safety check. It never did. Production carried an old all-purpose Azure key that works for image analysis but is refused by Content Safety, staging had no key at all, and neither had the service's address, so every check failed quietly and a failed check was treated as "clean". Typed answers were only ever checked against each account's own word list. Each environment now has its own Content Safety resource, the deploy wires it to PublicAPI, and a check that cannot be completed now refuses the answer and asks the fan to try again instead of letting it through. The live dashboard's answer themes use the same rule.

Ask fans a question on video and the big screen can now tell the crowd what they said. When an event on the Live Dashboard has transcription on, a new panel sits between brand exposure and value out: the question, the top themes from fans' spoken answers with their shares as bars, and a one-line read of the set, one question at a time. Nobody has to press "Build summary" mid-match: a background job rebuilds each question's summary once it has 5 answers, and again when the answers have grown by a fifth, at most every 5 minutes, which caps a busy question at twelve AI calls an hour. It deliberately never shows a fan's own words. The dashboard's link is on stadium screens, so the endpoint does not send quotes at all, and the theme names and summaries, which the AI writes from what fans said, are checked against the account's profanity list (and the content-safety service where it is configured) before they reach the screen. Anything flagged, or anything that could not be checked, is left off.

No product change. The venue-only browser check used to need a flag flipped by hand on the local test event before each run and flipped back after. The local seed now creates a second event, "Venue-only e2e", with the flag on, a Chicago map box, a text activity and a photo activity, so the check runs cold. It is idempotent and keyed on the title, and it re-asserts the properties the check relies on if a local admin has clicked them off.

No product change. Two of the camera's end-to-end checks, the venue-only refusal and the consent step never scrolling, had been failing before they tested anything: they were written before the activity chooser arrived (v10.36.2) and clicked the wrong thing on an event with more than one activity. They now share one walk with the location-wait check, all three pass against the local stack, and any future e2e that needs the permissions screen uses the same helper.

The same page, restyled for a television from the "Live Dashboard TV" design: a fixed 1920×1080 stage scaled to whatever screen it is on (a 4K set gets it at 2×, a 720p one at two-thirds), bigger type throughout, and nothing that needs a cursor — the map walks through its scopes on its own every 14 seconds ("auto view · UK") and calls out a pin every 7 seconds with the event's uploads and rate, the way a mouse hover would. Feed cards carry the upload's reference number. It switches itself on when the browser looks like a TV (a Smart TV, Fire TV, Chromecast or Android TV user agent, or a big landscape screen with no pointer), and can be forced either way with ?tv=1 or ?tv=0 on the dashboard address, which is then remembered on that device.

On production the Live Gallery's socket never established: behind Azure SignalR Service the hub has no ambient HTTP request, and the hub read its token from one, so every connection threw. The client retried for a minute, gave up, and the old last-resort page reload fired — which also threw away the scope you had chosen on the map. The hub now reads the connection's own HTTP context (the same in both modes), and the page never reloads: it polls the snapshot every minute while the socket is down, retries the socket until it returns, refreshes every ten minutes even when live so a missed push cannot drift the counters, merges each refresh into the numbers on screen rather than remounting the cards and pins, and remembers the map scope.

The live dashboard — the public page at your Camera App address plus /dashboard, for the big screen at the ground or a sponsor's phone — has been rebuilt from the "Live Dashboard" design, band for band. Across the top: the FANDEMiQ mark (click it for full screen), a LIVE pill that reads STANDBY when no event is accepting uploads, how many events are in play, the clock, a sparkline of uploads per minute for the last twenty minutes, uploads per minute, uploads, fans contributing, and a pipeline pill that says how long the last uploads took to reach the screen. Below it, a map of where the content is coming from — a pin per event sized by its uploads, the real upload positions dotted around each venue, scope buttons for Active events / Global / the regions your events are in, and a strip of event cards with each event's count and rate — beside a "Landing now" column where every finished upload lands as a card as it happens. Underneath, "Brand exposure" tiles sized by each recognised logo's share of detections with the last hour's change in share, and "Value out": earned media value by exactly the maths the Reports page uses, branded impressions, social echo, and how many FanMoments, stories, fan-wall frames and AudioMix clips the platform has made from the uploads. It still shows numbers, never fan content: cards name the event, not the fan, and no picture is put on the screen.

Describe the event to Florence — "home game v Arsenal, 14 March, Etihad, we want a fan wall and a FanMoment in the new kit, ask fans for their player of the match" — and it drafts the whole set-up: the event with its upload window and country, the questions fans will be asked (with record lengths and tags), the campaigns and what each is for, a fan wall that starts itself when enough clips arrive, and a FanMoment. The plan appears in the chat as a review card you can edit field by field. Nothing is created until you press Create; then everything is made through the same services as the Manager's own forms, with links to each thing, a list of what still needs a person (the map location, the FanMoment base image and test preview), and an audit row recording who confirmed it, the brief and the plan as applied. A generative FanMoment shows its cost per fan and cannot be created until the acknowledgement on the card is ticked. Florence can also add questions and campaigns to an event you have already created, as long as it is not live and nobody has uploaded yet — live events must be stopped by hand first. The same three steps are available to Claude Desktop and other agents through the MCP admin server.

Florence lived behind the Reports link. Now the same launcher sits on every page of the Manager — the events list, a campaign, the fan wall editor, the App Skin page, the reports dashboard and the platform admin pages — and it knows where you are: on an event's page, "how is this event doing" and "who uploaded most here" need no name. Opening the panel shows a "What's working" card before you ask anything: the last 30 days against the 30 before, the standout event of the last 90 days against your average, where uploads came from, how many fans have come back to more than one event and how many are on the mailing list, and today's AI Insights ideas when they have already been generated. Every line is a click away from the question behind it.

A split with a dozen rows read as a wall of numbers in a chat bubble. Florence now draws it: when the answer is a split, a trend or a share, the reply carries a chart drawn with the reports dashboard's own Chart.js setup and palette — brand purple first, DM Sans, the same axes and tooltips as the Overview page — with a one-line figure above it and a "Copy data" button below. Comparisons are a first-class question too: "the last 30 days against the 30 before", "the Cup Final against the rest of the season", "this platform's share then and now" each come back with previous, change and percentage change per row, and Florence explains a change with the splits that moved rather than a guess.

Florence, the reports assistant, could answer thirteen shapes of question and nothing else. Ask where the content came from, which phones fans used, how many opted in to marketing by country, who uploads most or who keeps coming back, and it had no tool to call — so it guessed or declined. It also could not find an event by name once an account had more than fifty, and it ran on the smallest model with its tool results chopped mid-sentence. This release gives Florence a data dictionary and one general query that splits any dataset by up to three things with the grouping done in the database, a fan directory that never shows the model an email address, event and campaign search, the platform's own recommendations as a tool, a stronger planner model, and a prompt that states plainly where the data starts and stops. The programme continues in docs/florence-programme.md: charts in the chat next, then Florence on every page, then setting an event up from a brief.

The Help & FAQ page had been showing "Unable to load help content" on every environment since May. The query that read it coalesced a navigation collection in a way SQL Server cannot translate, so it failed on every request while the health check stayed green, and the content behind it — four sections written in February — lived only in a database table nobody could see in git or update from a feature commit. Help now ships as files in the repository: one Markdown file per section under FilmilyManager/Help, read by the same endpoint and parsed the way the release notes are. Fourteen sections and 107 answers describe the platform as it is today, in the customer's names for things: the three event clocks, venue-only events, Calls to Action and the fan journey, campaigns and the five filter families, FanMoment tiers, ceilings and priority routing, fan walls and silent fans, films and Smart Films, branding and the App Skin, moderation and the Live Dashboard, reports and Answers, consent and data protection, translations, roles, and a troubleshooting list ordered by how often each thing actually happens.

CI marked both Recommendations API tests failed on 12 September even though every assertion in them had passed. The failure was in the tidy-up. The in-process test host was being told to stop twice — once by the test harness and once by the app's own shutdown, which the first stop wakes — and Hangfire's background server is the one component that throws if the second stop lands during its disposal. The tests never needed that server: every job client is mocked, so nothing was ever queued for it to run. It was only there because the test host boots the real Program. It is now removed from the test host, and a test pins that it stays removed.

The release notes page was a Markdown dump: one long column, every release at the same weight, nothing to find the one you wanted with. It is now the designed page from the platform website project — a sticky header with the version this Manager is running, a hero with the counts, filter pills by kind of change, a search box, a version rail down the left, and one card per release with its headline, its story and its changes grouped and colour-coded. The page still reads CHANGELOG.md — nothing moved into a database — and it understands every heading shape the file has used since February, so every release renders, not only the recent ones.

Three pieces of work were sitting on side branches, verified but never merged. This release brings them onto main in one go so nothing verified is left behind. Nothing here changes a schema.

Fan walls, films and personal stories used to carry a "Frame rate" setting with two options, 29.97 (NTSC) and 25 (PAL). Those are television standards; the clips are phone recordings, which default to 30 fps and occasionally 24, 25, 50 or 60 when a fan has changed a camera setting, and nothing on the web or social needs 29.97. The setting is gone from all three editors. The renderer now reads the frame rate of the source clips and encodes at the rate most of them share, snapped to a standard rate (29.97 counts as 30), falling back to 30 when nothing can be read. The broadcast .mxf keeps its own specification.

Minutes after 10.40.0 went live, the first fan wall opened in the editor had its Shuffle and Save buttons greyed out and a red line asking for a wall type. The new "video walls take videos, photo walls take photos" rule read the wall's stored types too literally: every wall saved before this week has the old "Any" as its input type, because the previous editor never set it, and the rule treated "Any + Video" as "no type at all". The same rule sat in front of the renderer, so those walls would not have refreshed either. A legacy wall is now what its typed side says it is, or what its tiles are, and it heals its stored types the first time it is saved. Only a genuine video-versus-photo conflict still asks for a choice.

Housekeeping after 10.38.0. The retired event banner is no longer part of the data model at all, so nothing running on production reads EventTheme.BannerMediaId any more. That is the first of two steps to removing it: this release stops reading the column, and the next release's migration drops it. Doing both at once would have given every event query a few minutes of errors between the column disappearing and the new image arriving, during a live event.

The event "banner" was a full-width image with exactly one job: the tile on the fan app's event list. It was never good at it. Since the list became the design's choice cards the tile is 44px square, and a banner squeezed into that read as a smear of yellow text — which is why the previous release stopped showing it and drew a glyph instead. The banner is gone from the event editor. In its place is Icon: upload a square image and the tile shows it; leave it empty and the app draws a glyph. Andy's call: "if we upload an icon its added, otherwise its a glyph."

A wall on production zoomed in on a fan and the crowd faded out into nothing. The fan's clip had a silent audio track: the microphone had produced nothing, the app had said nothing, and the platform had no way of knowing. Until now a clip's AudioScore had been a stub that wrote zero for every upload, so the editor could not tell a muted recording from a loud one.

Design 02 draws the activity cards as text: a title, one explaining line, a chevron. v10.36.2 had given each card an accent icon tile, and Andy did not want it. Gone. The event list keeps its tile, but no longer fills it with the event's banner: that banner is button art drawn for the full width of the screen, and squeezed into 44px it read as a smear of yellow text. The tile now holds a glyph from the icon font, the way the design draws its tiles.

The one screen in the Let's Get Engaged journey still on the old layout was the first one after Welcome: the list of events. It was drawn with the account's large yellow button art, floating title and all, while the design draws that step as dark choice cards with an accent icon tile. It now uses the same bands and cards as "Choose an activity", and so does the activity list itself — the design is explicit that a choice is never a block of solid accent, so the skin's large-button art is no longer used on either list.

The first wall rendered on 10.34.0 (the fan wall speed release) zoomed in on a fan whose clip was 5.5 seconds long, in a 10-second wall with "Loop clips" off. The fan stopped dead the moment the zoom reached them, and the soundtrack stopped with them, because the centre clip's audio was mixed with a "shortest wins" rule. Neither was new — the same wall on the old code did the same — but the new code made walls fast enough to notice. Both are fixed, and every kind of wall now has a local render matrix that proves it.

The screens looked like a cousin of the design rather than the design. The reskin in 10.31 had taken the design's numbers and poured them into the app's older scaffolding — a 10px page padding, 10px item margins, 90%-wide blocks centred in the column, spacers that grew — so every band landed a little off, and the selfie sat in a small square in the middle of a black screen instead of filling it. This release throws that scaffolding away for the seven designed screens and builds each one from the design's HTML: the same bands in the same order, the same paddings, radii, sizes and opacities, with only the six things a client owns — accent, accent ink, canvas, ink, display face, body face — read from the account skin.

Since this morning's v10.31.1, the photo and inline-video capture screens on production showed a fan a black box where their camera should be — with a working "Take Selfie" button under it. The camera was streaming fine; the frame holding it had collapsed to a 2px dot. The frame moved into a flex column in v10.31.1 so it could take the height that was left, and a flex item with margin: auto on both sides is never stretched: it shrinks to its content, and its only content is absolutely positioned, so it was zero pixels wide. The dev account's skin uses a capture frame style whose own margin rule happened to override the auto margins, which is why every local screenshot looked perfect.

A 5×5 fan wall at 1920×1080 took six minutes to render on production, using two and a half of the four CPUs it had. Twenty-five full-resolution 1080×1920 camera originals were being decoded, every frame, to paint twenty-five 384×216 tiles — the shortcut that swaps in a clip's small web encode only fired for tiles of 360 pixels or less, and 384 is not 360. Then the master was decoded three more times for the delivery file, the web preview and the stills. And before any of that, the wall sat in the queue for up to a minute waiting for a timer to notice it. Now it doesn't.

On the campaign page, Fan Walls and Films had a Show: dropdown and a six-item cap with Show More; FanMoments had neither. The old filter's options (favourite / complete / incomplete) never applied to a FanMoment — it is a configured scene, not a rendered output — so the section shipped with no filter rather than a meaningless one. Now it has one of its own.

The Answers report could only see answers from storified events, because the clip-to-question link was written on the story item and nowhere else. Ordinary events and Multi Video Upload activations — the ones that collect the most spoken answers — were invisible by construction. The camera now stamps the question on the clip itself at upload, so the link exists whatever kind of event it is.

The Answers report's empty state told admins to "switch answer transcription on for this account" — and there was nothing to switch. The account flag and the per-event override existed only in the database. The event edit now has the control.

Until now an event's location was a picture: the circle the admin fitted the venue into on the map meant nothing to the app, so a fan on their sofa could take part in a stadium-only activation just as easily as one in the stands. One new switch on the event, under the map, changes that — and it is eligibility, not decoration: the app checks the fan's position on the permissions screen they already see, and the server checks every upload again, so a fiddled client gets nowhere.

Two screens in the reskinned journey had quietly grown taller than a phone. On a video question, the moment a fan stopped recording the compact question band over the camera gave way to the 28px page title, the take dropped into a framed box under it, and the accept button fell below the fold — the fan had to scroll to keep their own video. And the permissions screen, with two cards plus a title, intro, hint, button and footnote, ran a few dozen pixels past an iPhone. The rule is simple and now enforced: no fan-app screen scrolls.

v10.29.0 rebuilt the permissions step to the guidelines and left every other screen in the old skin — which is why the consent screen still had full-width tinted rows and radio circles. This release brings the rest of the journey in line with the six-screen design: welcome, choose an activity, permissions, answer a question, your moment, and send us your moment. Same structure on every screen; colours, fonts, logos and copy still come from the account skin.

Since the v10.26.1 deploy on 7 September, every hourly retention purge on staging and production had failed before deleting anything. The purge composes the "still used by a live film or fan wall" test into its own query, but that test was bound to a different database context than the one running the query, and Entity Framework refuses to mix two. The Manager creates a fresh content context per service, so the two were never the same instance in a deployed environment; the single-context unit tests could not see it. The predicate now binds to whichever context is asking, and a new test runs the purge exactly the way production wires it.

A push to main took 18–19 minutes to reach staging and a production release 15–29. Almost none of that was the deploy: the images swapped in about a minute. The rest was the pipeline waiting on itself — tests in front of builds that did not need them, a second push queued behind the first one's deploy, a production release rebuilding images that staging had already verified — and six minutes per environment of writing configuration values that were already live: secrets, ingress ports, scale rules and the rembg sidecar's identity, each re-written on every deploy at fifteen to twenty-five seconds a call.

Now tests and builds run together, only the deploy step of each environment is serialised, a production release reuses the exact images staging ran, and every configuration write is compared before it happens. A push should reach staging in nine to ten minutes; a production release in eight to nine.

A camera deploy that changed the app but not its service worker left already-open tabs and home-screen installs on the old build until a fresh navigation. Each build now stamps its commit into the service worker, so every deploy is a new worker and open sessions reload themselves once, as the update logic always intended.

The camera's permissions step now follows the Fan App UI guidelines. Each permission is a card: an icon, the name, a "Required" pill where it applies, one plain line saying what it is for, and a pill toggle. A hint above Next says what still needs turning on, and a footnote reminds fans they can change their mind in their phone settings. Every colour and font still comes from the client's App Skin, so a dark canvas or a light one both read correctly.

The Manager's App Skin preview gains a Permissions slide, so a client can see this screen while choosing their colours. The new copy is editable and translatable like everything else.

The consent screens that arrived with the September privacy work were legally right and visually wrong. Fans were shown a "use my location" tick box sitting on top of a greyed-out Location switch — two controls for one yes. On the terms screen the explanatory paragraphs were scattered between the tick boxes, and anyone with a marketing opt-in configured saw the "happy to be contacted" sentence printed twice.

The Location switch is now the consent. The sentence a fan is agreeing to sits directly above it, in the client's own words and language, and the switch label stays whatever the client has called it. One tap records the answer and then asks the browser. The switch shows off for a returning fan until they tap it this session — a control that is already on is not consent. Nothing about what gets recorded has changed: the same module answers, the same wording hashes, the same ledger.

The rail had grown one item at a time and it showed: Content sat at the very top away from the rest of the media tools, Reports appeared twice, and on a normal-height screen the list ran off the bottom and painted Help straight on top of Translations.

It's now grouped by what you're actually doing. Set up — Events, Campaigns, App Skin, Branding. Watch what comes back — Content, Live Dashboard, Reports. The library — Media Manager, Clip Manager, Content Status, Shared with you, Translations. Lines between the three so you can see where one ends.

Reports is one item now, pointing at the new dashboard. The older report pages — Brands, Devices, Users, Emotions, Tags — haven't been rebuilt there yet, so they've moved to a "Classic reports" link at the bottom of that dashboard's own sidebar rather than being left with no way in.

v10.27.0's camera app never reached staging: the build's linter rejected a two-line HTML comment for mixing tabs and spaces. Nothing about behaviour changed; the comment is now indented the way the linter likes.

Same independent review as v10.26.1; these are the four we'd queued. Two of them are about what happens to a fan's words after they change their mind or their content is removed. Two are about being honest in the Answers report.

A fan's quoted words outlived their clip. When a clip was deleted — by an admin, by retention, or because the fan withdrew consent — its transcript went too, but the themed summary it had fed kept the quote in a cached column nothing else knew about. It could still be read by the report and by Florence. Now: deleting a clip drops the summary for that question; withdrawing speech consent blanks the fan's transcripts and drops the summary; and on every read, any quote that no longer has a living answer behind it is filtered out anyway. Rebuilding with no answers left now clears the cache instead of leaving it.

A network wobble could remove consent steps. If the camera couldn't load the consent screen from the server — a timeout, a brief outage, a server error — it assumed the server must be an old one and fell back to the single-tick screen from before consent modules existed. That skipped the age declaration and any blocking module for as long as the wobble lasted. Only a definitive "that page doesn't exist" now means "old server"; anything else retries, then shows the fan a clear message and a Try again button, and nothing proceeds on a guess. On the server side, face analysis now also checks for the Illinois / Texas / Washington release it asks for, rather than trusting that the app showed the tick.

Big events were summarised from the last 1,500 answers and described as the whole crowd. The grouping reads at most 1,500 answers per pass. It used to take the newest 1,500 and then present the result as if it covered every answer. It now takes a random 1,500 — the crowd at kick-off and at full time answer differently — and the report says plainly that it's a sample, how big, and that the counts are estimates (shown with a ≈).

Theme counts could add up to more than the answers. The model was asked for a count per theme and each was capped individually, so two themes could each claim all six of six answers and show as twelve at 50%/50%. The model now lists which answers belong to each theme; the count is derived in code, an answer can only be counted once, and a model that ignores the instruction is scaled to fit. Existing summaries are marked for rebuild so nothing built the old way is still on screen.

A second pair of eyes went over the last week's changes and found five places where the code did the right thing in the obvious case and quietly the wrong thing in the edge case. None had bitten a real fan yet. All five are fixed, each with the reviewer's own reproduction kept as a permanent test.

A fan who withdrew consent to transcription was still transcribed. The consent ledger never edits history — a withdrawal is a new entry, not a change to the old one. The transcription check only looked at the old entry, which still said "yes". It now looks for the withdrawal too, so changing your mind actually changes what happens.

Clearing FanMoment outputs could quietly regenerate them. Deleting a FanMoment output was designed to stop the retry sweeper. It did. It also made the photo look brand new to the other sweeper, the one that settles photos left undecided at the end of an event — which happily generated a fresh picture, charged for it, and emailed the fan again. Deleted history now still counts as history.

A storage hiccup during deletion could leave a fan's photo behind for good. Deletion removed the database record first and the files second. If the second step failed, nothing was left pointing at the files, so nothing could ever come back for them. Files go first now; if that fails, the record survives and the next hourly run tries again.

Retention could get stuck behind content still in use. The purge always took the oldest 200 items due for deletion. Anything still baked into a live fan wall is deliberately held back — but held-back items stay put, so an account with 200 of them at the front of the queue never got past them. Held-back content is now stepped over, and still reported.

Dashboards waited on transcription they didn't need. The "clip finished" signal to live dashboards had been chained after the answer-transcription step, so every clip queued behind AI work before the dashboard heard about it — and a transcription that gave up stopped the signal altogether. It now runs alongside, not in front.

FanMoment cuts a fan out of their photo before it composites or regenerates them, and that cut-out is the slowest thing in the pipeline. We're looking at whether a GPU makes it fast enough to matter, which turned up a nastier problem than "is it faster": when the graphics libraries are missing or the wrong version, the machine learning runtime doesn't complain. It quietly carries on using the processor instead. A GPU replica that isn't using its GPU looks exactly like one that is, only slower — and you'd have paid for the GPU either way.

The service now says which one it actually picked, in its logs and on its health endpoint. If it fell back, that's visible rather than something you have to infer from a stopwatch.

Nothing changes for what's running today: with no provider set it uses the processor, exactly as before, and the processor is always kept as a fallback so a replica with a bad GPU still serves rather than refusing to start. The experimental GPU build is a separate image that nothing deploys — it can't break staging or production.

Set a video Call to Action — "tell us your player of the match, you have ten seconds" — and until now you got several hundred videos and no way to know what was in them short of watching every one. The answers were there. Nobody could read them.

FANDEMiQ now transcribes those answers and groups them. Not counted — grouped: five hundred fans naming a player will give you "Saka", "Bukayo", "number 7" and "saka obviously", and a straight tally of that returns five hundred results of one. The new Answers report reads them as a set, works out which ones mean the same thing, and shows you the themes with real counts and real quotes. Florence can answer straight out too — ask her what fans said about the new kit and she will tell you.

Two things we were deliberate about. Quotes are exactly what fans said, never tidied and never generated, because this ends up in front of sponsors. And grouping runs when you press the button, not when the page loads, so two people looking at the same event see the same numbers.

Transcription is off until you switch it on, per account or per event. When it is on, fans get their own tick for it — separate from the terms — and anyone who says no still takes part and still gets their video. We simply do not turn their words into text. The report tells you how many declined, so a smaller number of answers reads as what it is rather than as a fault.

Every page in the Manager carries a footer with the running version, linked to these release notes — except the five pages you see before you log in. Those had their own hand-written footer with just a copyright line, so the one screen you can always reach without signing in was the one screen that couldn't tell you what was deployed.

Login, Forgot password, Reset password and both confirmation screens now show the version and link to the release notes, reading the same live value as everywhere else rather than a number typed into the page.

Set a photo Call to Action and the fan reads your prompt before they take the shot. Set a video one and, on most events, they saw a camera and nothing else — no title, no instructions, no clue what you wanted them to say.

The text was there the whole time; the fullscreen video camera was simply painted on top of it. Photo CTAs only go fullscreen when there's a lead-in video to play, so they never hit the problem, which is why this looked like a setting that video CTAs were missing.

The prompt now sits over the camera, and it gets out of the way: three seconds after recording starts it fades out, leaving the fan a clean frame. Stop and retake and it comes back. Photo CTAs with a lead-in video, which had the same blind spot, now show their prompt too — it stays up until the picture is taken, since there's no recording to fade out of.

There was no way to remove a FanMoment output from the list. Test runs and failed attempts stayed there permanently, and a screen full of old errors makes the real ones hard to see.

Each row can now be deleted, and there's a button to clear all the failed ones at once. Completed outputs are never touched by the bulk clear, so a fan who actually received their picture keeps it. Nothing is destroyed — the record is hidden from the list and any delivered image is left where it is.

One thing works differently from how it looks: deleting a row removes every attempt for that fan's photo, not just the line you clicked. That is deliberate. The system counts failed attempts to decide when to stop retrying, so removing only some of them would convince it to start again — and on a generative FanMoment, retrying costs money. The confirmation says so.

A reliability review found several places where something going wrong looked, from the outside, like it had gone right.

The biggest was file storage. When a file was replaced with different content of exactly the same size, the upload was skipped and the old content stayed — reported as a success. Storage errors were caught and reduced to a plain "didn't work", losing the diagnosis. And a fan's FanMoment scene image failing to load was treated as "there is no scene", so the fan received their cut-out on a blank background instead of the sponsor's artwork, with nothing recorded as wrong.

The camera app had two related problems. Its request timeout only covered the response headers, so a stalled download could hang indefinitely, and a timed-out request was never actually cancelled. And when loading the event list failed, the app could get stuck believing a request was still in flight, so refreshing did nothing until the fan reloaded the page.

Uploads that hit a genuine storage problem now tell the fan exactly that, with the same message as before, while the technical detail goes to the log rather than to the phone.

Yesterday's change shrank what was written to GitHub's build cache so it would stop deleting itself. The next deploy then got stuck: the images built and uploaded in about a minute, and writing to GitHub's cache carried on for fifty-two minutes before the run was stopped by hand.

That backend had now failed in every way it could — it exceeded its size limit and evicted the layers the next build needed, it was consistently the slower of the two caches, and finally it stopped responding altogether. It has been removed. The container registry keeps the full cache, has no size limit, and finishes in seconds.

The build step also gained a time limit, so a cache that stops responding fails quickly and can be retried, rather than quietly consuming an hour.

One honest cost: builds on a pull request now start cold, because a pull request has no registry credentials. Nothing else changes.

Deploys spent most of their build time uploading a cache that was about to be thrown away. GitHub allows a repository 10 GB of build cache and deletes the oldest entries once you go past it. Every build was writing two to three gigabytes — one blob alone was 942 MB — so the repository sat just over the limit and each build quietly deleted the very layers the next one needed.

The evidence was a rebuild of an identical commit twenty-five minutes after the first: it should have been almost instant, and instead it rebuilt from scratch. On the video-processing image, 352 of 402 seconds went on uploading cache, against about 50 seconds of actual building.

The full cache still lives in the container registry, which has no size limit and is what makes a normal deploy fast. What goes to GitHub's store is now the smaller final-image portion, which fits inside the quota and therefore survives. A smaller cache that stays is worth more than a bigger one that keeps being deleted.

A deploy took about 25 minutes. Shipping the code took 42 seconds. The rest was the pipeline dutifully writing every single setting — connection strings, storage URLs, CORS origins, CPU and memory — onto every container, on every deploy, whether or not a single one of them had changed. On the production run measured before this change, that was 13½ of 16 minutes spent setting values to what they already were.

The settings are still checked on every deploy, exactly as before — that guarantee is why they were being written in the first place, and configuration silently drifting is a genuinely bad way to lose an afternoon. What changed is that the pipeline now reads each app first and only writes where the live value actually differs. Same protection, without the wait. Anything it can't confidently compare it writes anyway, so the safe outcome is the slow one, never the wrong one.

The version stamp also moves into the same operation that swaps the code. It used to be applied a few minutes earlier, which meant that during every deploy there was a window where the footer advertised a version the site wasn't running yet.

Pressing Resend on a FanMoment that had failed reported success, marked the row as sent, and emailed the fan a link to a not-found page. The output had errored, so there was no picture behind the link — but the sender never checked, and the share page did. Two systems disagreeing about the same output, with the fan finding out.

The sender now applies exactly the test the share page applies: an output that never produced an image cannot be emailed. Where there is nothing to deliver, the button is replaced by "Nothing to send" and the screen explains that the FanMoment needs re-running first. When a send genuinely doesn't happen, the row no longer claims it did.

Also fixed: a FanMoment share page returned a server error, rather than the picture, for any account that hasn't set up an app skin.

FanMoments were failing on live. The picture a fan gets is built in two steps — cut the fan out of their photo, then place them on the campaign's scene — and the first step was dying. Not occasionally: the service behind it was being killed and restarted in a loop.

The cause turned out to be nothing to do with the size of anyone's photo. The off-the-shelf background remover we were running holds on to the memory it uses for one picture so it can reuse it for the next, rather than handing it back. The result is a service whose appetite grows after the first request and then never shrinks — it survived picture one and was killed on picture two, every time, which is why this looked so much like a random intermittent fault. It also meant every previous attempt to measure "how much memory does this need" measured the hoard rather than the need, and kept arriving at numbers far larger than the real answer.

We now run our own build of that service. It hands memory back after every picture, and it uses one fixed, pinned cut-out model instead of whichever the tool happened to default to — the default was a model that cannot finish a single picture inside the largest container this platform can run. Steady memory use went from "grows until killed" to a flat 1.7 GB. Cut-out quality went up rather than down: the new model correctly separates a person from a cluttered background — bookshelves, a guitar case, an office behind them — where the old fallbacks merged nearby dark objects into the subject.

The service also now refuses to work on more than one picture at a time, and says so plainly when a cut-out fails rather than quietly returning the original photo with its background intact. A fan should never receive a picture that looks half-made; if we cannot do it properly, the job fails, retries, and is swept up again later.

Open the uploader list on a fan wall that hasn't collected enough content yet and it said "No uploaders found". Read literally that means "we don't know who these people are", which is a frightening thing to see next to a wall of faces — the first assumption is a consent or terms-and-conditions problem, and the real answer was much duller: the wall simply has nothing in it yet.

A fan wall only assigns its slots once the campaign has enough distinct content to fill every one without repeating anyone. Until then it holds no uploaders, because it holds no clips. The message now says so and shows the arithmetic: how many slots the wall needs, and how many the campaign currently matches. A 5×5 wall with three recordings against it reads "It needs 25 and the campaign currently matches 3", which is the whole story in one line.

Separately, and more seriously: a fan wall built from photos never reported its uploaders at all. Every slot came back as anonymous no matter how many of those fans had given us an email, and the CSV a sponsor gets came back empty. Fan walls have accepted photos as well as video for a long time; the uploader list only ever looked at the video. It now looks at both.

Building a fan wall before an event has any content, you can upload a few of your own files to check the layout. Feed it video — which is what a video fan wall wants — and every tile came back as a broken-image icon. The preview was drawing each tile as a picture, and a picture frame cannot hold a video. Videos now render as videos, showing their first frame, and the tile you click still opens and plays.

Files the browser genuinely cannot open (iPhone HEIC photos are the usual one) now say so by name, rather than leaving you to guess which of the files you picked was the problem.

Separately, two behind-the-scenes search functions had drifted out of step with the filters they are called with. The campaign descriptor list — the tag cloud showing what the AI has spotted across a campaign's content — was failing every time it was asked, and the event stats popup had quietly gone the same way for a second time. Both work again, and there is now a test that fails the build the next time a new filter is added to some of the search functions but not all of them.

You could always say "only fans in this part of the ground". You could never say "and everyone else gets this instead" — there was no ELSE. The nearest thing was a second campaign with no filters at all, and because that one accepts every photo, the fans in the first campaign matched it too and received both sponsors' pictures.

Events can now send each photo to a single campaign. Give the campaigns a priority, and a photo goes to the first one that accepts it and no others. Put the zone campaigns at the top and an unfiltered campaign at the bottom, and that last one becomes the catch-all: everyone the campaigns above didn't claim. Four sponsor zones at one match, four different backdrops, one picture each — which is the thing that wasn't possible before today.

It is off by default and nothing changes on an event that doesn't turn it on. The campaign list shows the order the rules are actually evaluated in, marks the catch-all, and warns about the two ways this gets set up wrongly: no catch-all at all, or an unfiltered campaign sitting somewhere other than last, where it silently swallows everything and starves the campaigns beneath it.

One honest trade-off, stated in the admin screen rather than discovered later: when the first campaign in the order filters on location, faces or tags, that question can't be answered until the photo has been analysed, so those FanMoments arrive after analysis rather than the instant the photo lands. An unfiltered campaign at the top is unaffected. The alternative was guessing early and emailing some fans the wrong sponsor's picture, which cannot be taken back.

Three things were wrong with removing a fan's photo, and together they meant the platform did not do what our published retention schedule says it does.

Deleting photos in bulk from the admin screens operated on the wrong table. The code was copied from the video equivalent and never switched over, so selecting a photo soft-deleted whichever video happened to share its id — someone else's content — while leaving the photo the operator picked exactly where it was. Nobody would have seen it happen.

The single "purge" button did nothing at all: it raised an error every time. That made our data processing agreement's promise of per-item erasure "immediately through the admin platform" untrue for photos, where the only way one ever left was the retention clock.

And a hard delete missed the FanMoment images. Those are a composite of the fan's own face, stored in a different place from the photo, so the deletion tidied away the records pointing at them and left the pictures themselves sitting in storage — still reachable by any link already sent out.

In production the fan-facing API sits behind Azure Front Door. That means the network address the platform sees is the door's, not the fan's — and we were reading it as though it were the fan's.

Three things depended on it, all shipped in the last fortnight. The jurisdiction stamp, which decides which consent screen a fan is shown, what age line they see, and whether mood inference is allowed to run. The consent record's address fingerprint, which we describe as per-fan evidence — in reality every fan arriving through the same door produced an identical value, so it evidenced nothing. And the per-address rate limit, which pooled everyone behind one door into a single allowance.

Staging could never have shown this: its camera app talks to the container directly, with no door in between.

Front Door does pass the fan's real address along, but that header can only be believed when the request genuinely came through our own door — otherwise anyone calling the container directly could name their own country and pick their own consent screen. So it is honoured only when the door identifies itself with the id we expect, and ignored otherwise.

The fix that shipped in 10.16.0 closed fan-media enumeration for new content and left everything older than 18 August open. Verifying the live production deploy found two of six guessed addresses still returning a real fan photo.

The cause was a piece of reuse that looked right and was not. The signing helper deliberately keeps honouring older, unsigned links, because share links are emailed to fans and breaking them would strand content people already have. The integration addresses are not like that: they are generated fresh inside every API response and never sent to anyone. Grandfathering them protected nothing and kept the whole historical library reachable by counting. They now require a valid signature or the owning account's token whatever their age.

Items five to ten of the review's top ten. One of them turned out to be a smaller problem than reported and a different one turned out to be bigger, which is the useful kind of surprise.

The bigger one: three environment config files had been sitting in the repository since the original code import, carrying a customer's production API key, our email-sending key and the mailbox password. An ignore rule was added months later, which does nothing to a file already committed. Checking what production actually runs proved something reassuring and something awkward at once — those files are excluded from the container images, so none of it was live config; but that also means the Manchester City webhook integration has not been firing at all. The keys are out of the current code and the build now fails if anyone commits one again. They remain in git history, so all four still need rotating, and that needs you and Man City.

The smaller-sounding but more useful fix: the mobile API answered HTTP 200 to everything, including failures, with the real result hidden in the response body. Nothing that watches HTTP could tell a working event from a broken one. Failures now return a real status code, and the fan still gets the same specific message, because the app was already written to read it. Alongside that, caught exceptions were being written into logs as plain text rather than as exceptions, which is why they never appeared in the platform's own error tracking. They do now.

Share pages were the other real risk. They are served from the same web address as the admin dashboard, and a client's own "script tags" field is placed on that page as-is — so a script saved by any member of any account could act as whoever opened the link, including us. The page now runs in a sandbox with no access to the admin session, saving script tags requires account-management permission rather than mere membership, and the field is no longer sent to fans' phones, which never used it. The permanent fix is to move share pages to their own web address; that needs a DNS change and is tracked.

Finally, two quieter ones. A single failed render used to freeze every other fan wall and film queued in the same minute, because a failed job in the queue never counts as "finished" and everything chained behind it waited forever. And the retention purge — which deletes fan media hourly on production — had no test covering the one check that stops it deleting content still in use.

Opening an event's campaigns page could render nothing at all — no heading, no error, not even a spinner. It looked like the page had simply given up, and there was nothing to click.

It had. Three separate crashes could cause it, all of them triggered by an account or event with no data behind it yet — a brand-new client, or an event that has been removed. Underneath them sat the real problem: the page waited on three things loading at once and had no handler for any of them failing, so a single failure left it stuck mid-load forever while the loading indicator switched itself off. One missing line of error handling turned three small crashes into an entirely blank screen.

All three crashes are fixed, and the page now says what went wrong instead of showing nothing. If an event genuinely isn't there — deleted, or belonging to another account — you get "Event not found" and a link back to your events, which is the honest answer.

The event country was a two-letter text box. Type "UK" — which is what most people type, and which is not an ISO code — and the event quietly ended up with no country at all: strictest consent flow, no emotion inference, no warning that anything had gone wrong. It is now a searchable dropdown of every country, and you can find one by name or by code. The same for US states, which is where the Illinois and New York face-analysis rules hang off. Changing the country away from the US now clears the state too, so moving an event to France and back to the US can't silently re-arm Illinois' rules.

The three data-protection dropdowns were also squashed into three columns too narrow to hold them and overlapping each other. They are two rows of two now.

A read-only review of the whole codebase turned up four things that were wrong in a way nobody would have noticed from the outside: not crashes or slow pages, but doors that had been left open and a delete rule that was quietly overriding our own retention promise. All four are fixed here.

The worst of them was arithmetic. The short code in a fan media link is not a secret — it is the row's database id, shifted and encoded, plus a check character from a random number generator seeded with that same id. Anyone who worked that out could count upwards through it. We had already spotted this once and closed it for the share links we email to fans; the copy of the same pattern on the integration API had been left open, so every fan photo, clip and personalised video on the platform could be pulled with no login and no token. Those links are now signed, and a link that is not signed only opens for the account that owns the content.

The admin dashboard had six media routes with no authentication at all — not weak authentication, none. Every neighbouring endpoint in the same files had it; these six had simply been missed, and they served rendered fan walls, audio mixes and story previews for any client by integer id. There is now a test that walks every endpoint in the admin API and fails the build if one of them loses its lock, because "somebody forgot" is exactly how the first six happened.

There was also a leftover debug endpoint from before our time on this codebase, gated by a permission that every Director happens to hold and that checked nothing about which club you belonged to. It returned a clip and everything the AI had derived from the faces in it. It is deleted, and so is the permission.

Last, the one that was actively costing us: a storage rule was deleting every original fan photo and video 90 days after upload, regardless of what retention period the client had bought and regardless of whether that clip was still baked into a live fan wall. It also sat two days away from deleting the key file that signs everyone's login session. It has been removed from both environments.

Until now every fan on the planet saw the same terms tick. That was fine when the only thing we asked for was an email address; it is not fine when a fan in Illinois has a statutory right to a written release before their face is analysed, a fan in Berlin must be told an AI is estimating ages, and a fan anywhere must be asked separately before we take a precise location.

The capture screen is now composed on the server for each fan and each event. Everyone gets one base screen with one tick. On top of that, the fan's jurisdiction (resolved inside the platform, never sent to a third party) adds what their location requires: the AI transparency line, the Illinois release, the Texas and Washington notice, and a precise-location opt-in that is off by default everywhere. Client switches add the marketing tick and the AI-made-output notice. If the fan's location cannot be resolved, they get the strictest set, not the loosest. Under-age fans get an honest "I'm under 13" link that switches them to anonymous participation instead of a dead end that invites a false date of birth.

And the ledger finally records what it claims to. Every tick is its own row, stamped with which module it came from, the country and state the fan was resolved to, how that was resolved, and a keyed hash of the address it came from. The wording behind every hash is stored the moment the screen is composed, so "show me exactly what this fan agreed to" has an answer even after the terms have been edited a dozen times.

Two decisions taken with this release: emotion inference is on by default and switches itself off wherever the law says it must (EU/EEA fans or events, staff or student audiences, unknown locations), and the retention purge is live on both environments.

Our public data-protection page has been honest about its gaps for a while: fan media is "deleted after 90 days", an IP-based location lookup "still runs when a fan refuses location", and a few things were "not yet implemented". This release closes the ones that were actually wrong today, and adds the switch that the EU's AI Act now makes necessary.

The big one is emotion. Estimating a fan's mood from their face is an "emotion recognition system" under the EU AI Act — high-risk from December 2027 and already prohibited outright for staff and students. It used to run for every fan on the planet with no way to turn it off. It is now opt-in per account (and per event), and the platform refuses to run it for anyone in the EU or EEA, or at any event whose audience is employees or pupils, whatever the setting says. Age and gender estimation carries on, because that is transparency-only.

Location got the same treatment. If a fan says no to sharing their location, that is the end of it: the app no longer quietly asks our server to guess where they are from their IP address, and the second geolocation provider that guess used to fall back to has been removed entirely. Every new upload records whether its coordinates came from the device with the fan's permission or not at all, and the heatmaps only plot the ones that did.

And the 90-day promise finally has something enforcing it. A retention job now hard-deletes clips and photos (and everything the AI derived from them) when their time is up, and forgets the contact details of fans who have nothing left on the platform. It ships counting, not deleting, until each environment has had its numbers checked.

Until now, a fan's consent lived in exactly one place: a tickbox in the camera app. The app checked it, the server trusted the app, and nothing anywhere recorded what was actually agreed to, when, or to which version of the terms. If anyone ever asked "show me this fan agreed" — a regulator, a rights team, a fan themselves — the honest answer was that we couldn't.

This release gives the platform a consent ledger: an append-only record of every terms acceptance (including a fingerprint of the exact terms text that was on screen when the box was ticked), every marketing opt-in and opt-out, and every club-sharing choice — each one tied to the specific photo, clip or text it covered. Records are only ever added, never edited: a withdrawal doesn't erase the original grant, it sits alongside it, so the history stays honest in both directions.

The camera app also lost a few doors that should never have existed. It was possible for a link to arrive with terms "pre-accepted" or the marketing box pre-ticked — a pre-ticked box isn't consent, so links and scripts can now fill in your email address and nothing else. And club sharing has flipped from opt-out to opt-in: new fans are not shareable with partner organisations unless they actually say yes.

Turning the packaging check back on in the last release had an obvious cost: every proposed change now took about twenty minutes to come back green. That's long enough to stop what you're doing and go elsewhere, which is exactly how small changes turn into slow days.

Three things were causing it, and none of them was the check itself being thorough.

The three services were being packaged one after another, though nothing about them depends on each other — so they now happen at the same time. Proposed changes were also starting from scratch every time: the shortcut that lets a build reuse the previous one's work was only ever saved on the main line, never in a form a proposed change could read. And the release notes file was being handed to the packaging step so early that editing it — which every release does, by definition — threw away all the reused work for the admin service and forced a full rebuild.

Roughly twenty minutes down to about five, and releases stop paying a needless five-minute penalty for updating this very file.

Every proposed change is supposed to get its packaging instructions test-built before anyone merges it — the step that catches "this won't even assemble" before it reaches a real environment. That check has never run. Not once, on any change, ever.

It wasn't broken so much as unrunnable: the check was labelled as belonging to the production environment, and production is locked to accept only finished, merged work. So the check was refused permission to start before it did anything, failed in about a second, and reported red. Because it had always been red, the redness stopped meaning anything.

The practical cost: a packaging mistake stayed invisible until the deploy that followed the merge — the worst possible moment to find out, and one that blocks everyone else's work too.

It now runs on every proposed change, and it builds all three services for real.

The welcome page new customers land on after buying through Microsoft had just started showing its version number correctly. Now that number behaves like it does everywhere else in FANDEMiQ — click it and the release notes open in a new tab.

Small thing, but it's the first page a new customer ever sees, and the one Microsoft reads when reviewing the listing. It should look finished.

Our infrastructure is described in code, so it can be rebuilt from scratch and can't drift into a state nobody remembers creating. Two separate descriptions had grown up claiming ownership of the same thing — the servers the platform actually runs on. One of them, the older one, had fallen months behind.

That's more dangerous than it sounds. Applying the stale description would have quietly deleted most of the credentials those servers use — the AI keys, the image-analysis keys, the internal ones the services use to talk to each other — along with their permission to fetch new software builds. Nothing would have failed loudly. FanMoments, photo analysis and deployments would simply have stopped working, at whatever moment someone next ran a routine infrastructure update.

There's now one owner. The deployment pipeline owns the servers, and re-applies every setting on them each time it runs, so they can't drift. The infrastructure description owns the durable things around them — the network, the databases, storage, the vault. We verified the fix by asking Azure to plan the change before and after: the four servers went from "about to be modified" to not appearing at all.

A correction to the previous release. The 10.12.0 notes said the database now scales itself. That work is written and ready but is not switched on yet — it needs an infrastructure update, which is precisely what the ownership clash above was blocking. Both environments are still on the old fixed-size plan. It's now unblocked and waiting on a quiet window, because switching it over briefly interrupts the database and shouldn't be done during an event.

Automatic scaling is always slightly behind: it notices load, then takes about a minute to add capacity. That delay lands exactly on the opening minutes of an event — when the most fans are uploading and the platform looks its slowest.

It doesn't need to guess any more. We already know when every event opens for uploads, so the platform now brings extra capacity online shortly beforehand and stands it back down once the event is over and the backlog has cleared.

One deliberate restraint worth knowing: it never changes capacity settings during an open event. Changing them restarts the services, which is fine half an hour before kick-off and the last thing you'd want mid-match. During the event itself the normal automatic scaling takes over, which is what it's good at.

Off by default — it's switched on per environment once the permissions are in place.

A go-live readiness audit of staging turned up something uncomfortable: the platform had almost no way of telling us when it was failing. Application Insights was set up in both environments, the connection string was being handed to every service on every deploy — and no service had ever actually used it. Thirty days of nothing. The exception alert that was meant to email us when things broke was watching an empty resource, so it could never have fired, not once.

That is now fixed and verified: telemetry is flowing, and the alert that was decorative for months can finally do its job.

Three more failures were hiding behind the same blind spot. Background job failures were recorded only in a dashboard nobody can reach — 198 of them had piled up on staging unseen. Application errors were being carefully written to a database table that nothing on earth reads. And a single malformed row in one campaign could stop every render on the platform — every fan wall, every film, every audio mix, for every client — while deleting the evidence on its way out.

Also worth knowing for matchday: if an event is saved without "public" ticked, every fan opening the app is told there are no active events. The API reports complete success while doing it. That now raises an alarm within five minutes.

The league view has gone from a plain stack of tables to a proper dashboard. Seven headline tiles across the top — clubs, events, fan uploads, campaigns, films, fan walls and spend — each with its own icon and a one-line "so what", greyed out when there's nothing to report so your eye goes straight to what's actually moving. Below that, the usage map, a ranked club leaderboard with numbered positions, and the spend rollup sitting beside a per-club breakdown.

Two genuinely new things: a period picker in the header so you can look back over the last twelve months of spend, and an Export button that drops the whole dashboard — leaderboard and spend rollup — into a CSV.

And a fix worth calling out: the usage map has been rendering blank. Google retired the heatmap layer we were using from their Maps API, so the call was quietly failing and the map came up empty every time. It now draws the clustered activity itself and zooms to wherever your fans actually are. Still aggregate-only — clustered counts, never individual fans or content.

Follow-up to the 10.9.3 rebuild. The page content was running full-bleed and hugging the right edge of the screen with no gutter — not what the design shows. Now the content is capped and centred (max 920px wide) with proper side padding, exactly like the mockup, so it sits comfortably in the middle of the canvas instead of stretching wall-to-wall.

The v10.9.1 pass only nudged a colour — this one actually rebuilds the Smart Films page to the design. The three settings now read as one aligned row: Target film length is a proper dropdown that matches How often, both sitting flush with Maximum films at the same height, each with a clean chevron. The buttons got a real system — a solid purple Save settings beside a crisp purple-outline Preview this film (no more washed-out grey), with a matching Preview a film button on the empty state. Badges are uppercase, cards breathe a little more, and the whole thing finally looks like it was drawn on purpose. Under the hood nothing dangerous changed — Generate still generates, cadence and run history still work.

The exact same tidy-up we just did on the Films page, now on the FanMoment scene editor. Its "purple" badge was carrying the old drifted lavender; we nudged it onto the real FANDEMiQ brand token so it matches the Films page, the App Skin menu and the rest of the Manager to the hex. Nothing else moved — pure visual alignment.

A small but honest bit of housekeeping on the Smart Films page. Its lavender was a hair off the FANDEMiQ brand purple — close enough that nobody would file a bug, wrong enough that a designer would twitch. We nudged it onto the real brand token so the icon tiles, badges and film thumbnails match the rest of the Manager to the hex, and switched the film timestamps to our proper mono typeface. No behaviour changed — Generate, cadence and run history all work exactly as before. Just tidier.

We've reworked how a league sits above its clubs, around a simple, privacy-first principle: a league sees the numbers, never the fans. A league now gets a rich, aggregate picture of every club — a leaderboard, per-club drill-downs, and a live usage map of where activity is happening — but it can no longer see a club's actual fan photos, clips or email addresses. Each club's fan base stays the club's own.

In return, the league becomes a fan-acquisition engine for its clubs. When a league runs its own fan engagement and content comes in, it can now find the right content and hand it to the right club. Say the league spots a wave of Manchester City fans — it selects them and shares them down to the Manchester City account. The club gets a "Shared with you" inbox, reviews the batch, and on Accept the content and those fans (with their contact details, subject to consent) land in the club's own account, ready to engage.

And the Netflix-style content browser we built for leagues has moved to where it's most useful: every account now has it as a "Content" page for finding its own fan content — now with brand search (filter to the photos where a given brand was detected).

The biggest structural change to FANDEMiQ yet — and the one that unlocks league-sized deals. Accounts can now be organised into a league (a master account) sitting above its clubs (sub-accounts). Every club still runs completely independently, exactly as before — nothing about a standalone account changes. But link a few clubs under a league and that league gets a brand-new, read-only League area. There's a cross-club dashboard: a leaderboard of which clubs are busiest, combined fan-engagement totals, and a monthly spend rollup. And there's a content library that browses every club's fan photos and clips as one big Netflix-style wall — rows that organise themselves by club, by what the AI sees in the content (crowds, celebrations, flags…), and by the busiest locations, named automatically ("Old Trafford", "Etihad Campus", a city or a county). Search runs against the AI's read of the content itself, and every filter — club, campaign, date — narrows the wall instantly. The league can look but never touch: it's pure oversight, with a hard boundary so a league only ever sees the clubs actually linked to it.

Setting up how your Camera App looks just became a lot more pleasant. The App Skin page — where you choose your colours, fonts, header shape and behaviour — has been rebuilt from the ground up. Everything now lives in one clean card with icon tabs across the top, your live phone preview sitting alongside it, and a tidy Save / Discard bar pinned to the bottom. The old grid of checkboxes became friendly on/off switches (each with a plain-English line telling you what it actually does), colour pickers now show their hex value at a glance, and the busiest tab is split into clear numbered steps — Appearance, Behaviour, Fan sign-up, Images and Fonts. Every setting that was there before is still there and works exactly as it did — including click-the-preview-to-jump-to-a-setting — it just looks and reads a whole lot better. We also added a Discard changes button so you can back out of edits without reaching for the browser refresh.

Client-branded fonts stopped showing up in the Camera App — a beautifully set-up skin (say, Oswald for headings and Inter for body) was landing as plain browser Times. The fonts themselves were fine and correctly attached to the skin; the trouble was one missing setting on our storage. Brand fonts live as files on our storage account, and the browser politely asks permission (a "CORS" check) before using a font from another address. That permission had never been switched on, so every request was quietly refused and the app fell back to its default lettering. We turned the permission on across staging and production, baked it into our infrastructure blueprint so it can't go missing again, and taught the app to fall back to a clean sans-serif — never Times — on the off chance a font can't be fetched.

The heat-map on the Camera App's live dashboard was leaning on a mapping feature Google has retired. We'd been holding it together by pinning an old, frozen version of Google's maps engine — a ticking clock, not a fix. So we rebuilt the heat-map ourselves: the same glowing view of where your fans are, now drawn on our own canvas with no dependency on the removed feature. It's off the deprecation treadmill for good, and the Camera App always runs the current maps engine again.

The heat-map on the Camera App's live dashboard had gone dark. It leaned on a Google Maps account that had been deleted out from under it, so every load hit a wall and flashed "Something went wrong." We repointed it at our live maps account, and the map's back to plotting where your fans are — no new sign-ups, no new keys, just the lights switched back on.

We finished the Films makeover. Your generated films now appear as clean, scannable rows — each with a one-tap play button, when it was made, its length and how many clips went into it, and an at-a-glance status (Ready, Processing or Error). Click any film to watch it in a branded pop-up player, with download right there. Before any films exist, a friendly empty state points you at what to do next.

We also refreshed the icons down the left-hand navigation so they line up with the rest of the FANDEMiQ interface — same menu, cleaner glyphs.

The Camera App got a proper tune-up under the bonnet — uploads are quicker and far more reliable, the app loads lighter, and we squashed a lurking bug that could take the whole Camera App offline for a branded event.

The headline: uploads were being quietly rate-limited. A single Story (a photo and a video) is nine or ten separate requests behind the scenes, and the old cap — ten requests a minute, shared across everyone on the same network — meant a fan at a packed stadium (where hundreds share one connection) could hit the ceiling and watch their upload silently give up. The cap is now per-device and far more generous, and the app backs off and retries politely instead of surrendering on the first "no". Video also uploads in bigger chunks, so there's less chatter over the wire.

We also trimmed the start-up: the QR-code page only desktop visitors ever see is no longer downloaded by every phone, fonts no longer hold up the first paint, and the background image is roughly half the size.

And a genuinely nasty latent one: an account that had quietly accumulated a few access tokens over time (which happens naturally) could make the Camera App fail to load entirely on its custom domain — an endless spinner. Fixed, and pinned down with tests so it can't sneak back.

Two bits of polish. The live operator dashboard now greets you with an on-brand screen instead of a bare error when there's nothing to show yet — a clear "Live dashboard isn't switched on yet" message (pointing you at the Allow Dashboard Stats toggle), a proper loading state, and a graceful error state, all co-branded with your logo. New events now have Allow Dashboard Stats switched on by default, so the dashboard just works out of the box. We also fixed the dashboard map, which had stopped loading after a Google Maps change removed the old heatmap component. Separately, the Story cut-out preview now loads near-instantly (it was fetching a full-resolution, multi-megabyte image; it's now a lightweight preview).

When you removed a fan's background AND set a Frame as their backdrop AND turned on Scale Media to size/position them, the rendered story showed the fan on black instead of in front of the frame. The scale/position step was compositing the cut-out onto a solid black background, which wiped out the transparency before the frame could be drawn behind — so the frame ended up hidden. It only happened with Scale Media switched on (plain cut-outs were fine). Fixed: a scaled cut-out now keeps its transparent background, so the Frame shows through and the fan sits in front of it as intended.

Story recipes that output a video were failing during generation — the main video actually rendered fine, but the very last step (grabbing the preview thumbnail from it) crashed, which marked the whole story as failed. The cause was a tiny formatting slip in how the render engine passes its thread-limit settings to ffmpeg: a missing space glued two options together (…threads 2 + -y → 2-y), which ffmpeg rejects. It only bit commands that begin a certain way, which is why films, mosaics and image stories were unaffected but video-story thumbnails weren't. One-character fix, with a test that fails loudly if it ever regresses. (Discovered while testing the new Story cut-out — the cut-out itself was not the cause.)

Ticking Remove background on a Story image part now updates the big preview on the left to show the actual cut-out — the fan lifted off their background, sitting in front of the Frame (which becomes the backdrop) — instead of a small separate thumbnail. It's a true preview of what the finished story will look like. This also fixes the preview failing to load for non-admin users (the image request wasn't carrying the account context, so it came back blank).

Same clever Smart Films engine underneath — but the Films (Global) page now looks the part. A proper page header with a title, a "Global" badge and a one-line explainer; the settings wrapped in clean cards with helpful hints under each field; a real on/off switch for automatic generation (that politely waits until you've acknowledged the charges); and the branding-inheritance note turned into a clear info panel instead of grey small print. The run-history table got the same tidy-up. Nothing about how films are made changed — it's purely a nicer place to set them up.

The background-removal trick FanMoments has always done — lifting a fan cleanly off their surroundings — is now available on image parts inside the Story builder. Tick Remove background on any image part and two things happen: the editor shows you a live cut-out preview of the image you've added (checkerboard behind it so you can see exactly what's transparent), and at the event the fan's own captured photo for that part gets the same treatment as they take part — no green screen, no manual masking. It uses the very same cut-out engine as FanMoments, so it's fast, free, and looks identical to what you already trust. Video parts don't offer it (there's nothing to cut a still out of), and anywhere the cut-out service isn't switched on, Stories render exactly as before.

The render server's logs showed jobs now running properly and dying minutes in — the last gap between "fits on my machine" and "fits in the container" turned out to be the memory allocator itself: on Linux it pre-carves arenas per CPU core of the host machine and happily triples a video encoder's real footprint through fragmentation. Three final tightenings: the allocator is capped at two arenas, the video engine's filter threads are capped to match the CPUs it actually has, and renders now run strictly one at a time per server (they saturate both CPUs anyway — busy events get more servers, not more crowding).

Confession time: the last three releases each fixed a real memory problem, and none of them was the one crashing production. The database finally told the whole story — the wall was a modest 3×3, but ten fans qualified for personal walls at once, and the job runner cheerfully started all ten video renders simultaneously on a machine with the memory for about three. Every restart it tried all ten again. Renders now run through a dedicated lane capped at two at a time per server — matching the CPUs they'd fight over anyway — and when there's a genuine backlog the platform spins up more servers instead (whose autoscaler, it turns out, had been silently watching the wrong database's queue and holding an unusable credential — both now fixed). The three memory diets from 10.6.8–10.6.10 stay: each render is now several times cheaper than it was this morning, and at two-at-a-time the sums finally work.

Two rounds of taming the video renderer's memory made every render cheaper — and the crashes kept coming, 15 seconds after each attempt started. That was the tell: the server was falling over before any video work began. The actual killer was the database query that loads a personal wall's details: it pulled the wall, every tile, and every language variant of its audio track, overlay, and filter image in one combined query, and the database multiplies those lists together — a large branded wall came back as thousands of duplicated rows carrying megabytes of clip metadata each, gigabytes in seconds. The query now fetches each list separately (identical results, a handful of slim queries), and the "Stop" button on personal fan walls now genuinely stops renders that were already queued.

The 10.6.8 memory fix proved itself on photo walls but production promptly found the next appetite: walls built from video clips. Decoding the full-resolution wall video spins up one decoder thread per CPU core on the host machine — each holding a wall-sized frame — which quietly ate another 2GB+ and could still take the server down on bigger walls. The decoder is now told to keep just two frames in flight, cutting a 6×6 video wall's render from 2.4GB to 1.2GB (an 8×8 fits in 1.7GB). Photo and video walls of any realistic size now render personal fan walls comfortably.

Turning on personal fan walls was quietly taking down the video processor. Each personalised render — the one that zooms from the full wall into a fan's own tile — asked for memory proportional to the wall's total resolution (a 6×6 wall wanted about 4GB just to zoom), which was more than the production server had. The render was killed mid-encode, retried a few minutes later, and killed again, forever — so no personal walls were ever finished and no "your video is ready" emails ever went out. The zoom is now rendered in bite-sized segments that never need more than a few hundred megabytes, regardless of wall size, and it's about three times faster too. Same zoom, same sharpness, a fraction of the appetite.

Event and campaign cards now show a consistent set of headline numbers everywhere you see them — the events list, an individual event, and each campaign — in the same order: Users, Locations, Clips, Photos, Films. The new one is Locations: how many uploads arrived with a GPS position attached, so you can see at a glance how much of your content is map-plottable. Paired with last release's live updates, these tick up on their own during an event.

Uploading an MP4 (or any video) into the Media Manager was failing with a server error, while images uploaded fine. The cause was in how we saved the small preview thumbnail that videos generate: on our cloud servers the thumbnail's filename was being stored with its full storage path attached, which overflowed the database field and rejected the whole upload. Photos never hit this because they don't produce a separate thumbnail. Videos now save their preview correctly and upload cleanly.

The numbers on your event and campaign cards — Films, Clips, Photos, Users — used to load once when the page opened and then sit still. During a live event that meant refreshing the page to see fresh uploads land. Now any card on screen quietly re-checks its counts every minute, so clips and photos coming in during an event tick upward on their own. No refresh, no clicking — just leave the page open and watch it fill up. Cards you've scrolled past stay quiet, so it stays light on the server.

The App Skin area has a new QR Code tab. It generates a QR code that opens your camera app — styled in your brand colour with your logo in the centre — ready to drop onto signage, screens or print. Preview it live, copy it to the clipboard, or download it as a high-resolution PNG or a print-ready SVG. If your brand colour is too light to scan reliably, the code automatically switches to dark modules (keeping your logo) rather than producing a pretty code no phone can read.

The Costs report has always been visible to clients — that's the point, they can watch their running spend. But the "Cost settings" editor behind it lets you change the underlying rates and free allowances, and those are FANDEMiQ's commercial terms, not the client's to edit. That editor is now restricted to platform administrators: the button is hidden for everyone else, and the endpoints refuse non-admins outright. The Costs table itself is unchanged for clients.

The event stats popup (the chart icon on an event card) was showing an empty white panel where the charts should be. The real culprit turned out to be a database function that had drifted out of sync with a recent search change, so the whole stats query errored out. That's fixed, and two display problems went with it: the charts were rendering at zero height (invisible even when the data loaded), and the map defaulted to a zoomed-out view of the entire globe when an event's photos had no GPS. The popup now loads the audience/device charts properly and frames the map on the event's own venue.

Cloning an event with "Clone FanMoments" ticked copied every FanMoment on the campaign — including ones that had been deleted — so a removed FanMoment could quietly reappear on the copy. It now clones only live FanMoments, matching how fan walls and stories already skip deleted items.

A broad maintenance sweep. Reports now behave sanely when you tick every filter box, cloning an event can bring its FanMoments along (safely), the event stats popup actually shows stats again, a pile of dead code and dependency vulnerabilities are gone, and the build is a lot quieter.

The App Skin "Plausible domain" box used to be a blank you had to guess at. It now defaults to the camera app's own address (e.g. app.fandemiq.net/msg) — which is exactly the site name to create in your Plausible account — so wiring up web analytics for a new account is a single Save. Clear the field to turn tracking off.

Two annoyances caught during live testing of auto-generated fan walls. First, a campaign card could insist "0 clips" for up to an hour after fans had uploaded — its counts were cached for an hour while the event header refreshed every minute (and the wall generator, checking the database directly, was already happily rendering those "non-existent" clips). Campaign counts now refresh every minute like everything else. Second, a wall whose content had arrived could still sit waiting up to five minutes before anyone noticed it was ready — the readiness scan now runs every minute, so walls start rendering within about a minute of the last needed upload.

The mystery of the slow admin pages is solved. On every single request — every page, every click, every background job — the platform was quietly re-verifying that its database schema was up to date, taking a database-wide lock while it did so. That meant every signed-in request paid a one-to-three-second toll and then queued behind every other request paying the same toll. Local development skipped the check entirely, which is why it always felt fast on a laptop and slow in the cloud. The check is gone (deployments already verify the schema before any code goes live), and signed-in pages are now several times faster — with requests finally running in parallel.

With fan walls rendering again, we turned to why they were ever slow. The answer: the renderer was doing far more work than the eye can see. Intermediate files were encoded at true mathematical losslessness (several times the compute, ten times the file size, zero visible difference), every wall got a full second re-encode even when no effect changed a single pixel, and the final video was compressed with the slowest settings ffmpeg offers. All three are fixed — plain walls now skip the second encode entirely by copying the video stream, and every wall encodes meaningfully faster. Faster walls, smaller storage bills, and noticeably less compute per render.

The revived renderer got all the way to producing the fan wall video on staging, then tripped on the very last step — generating the little preview thumbnails. The setting that controls how often to grab a still frame was shipping as zero (its real value lived in an environment-specific config file that never makes it into the cloud image), and "one still every zero seconds" is an impossible frame rate that crashed the thumbnail encoder. The renderer now treats a missing/zero value as "one per second", and the shipped defaults have been corrected.

The revived render engine worked perfectly in local testing but fell over on the first real render in the cloud: a leftover configuration setting pointed it at an empty path for the FFmpeg program, so it couldn't launch. The renderer now falls back to finding FFmpeg on the system path (where it's always installed) whenever that setting is blank, so it no longer depends on a config value that isn't reliably present.

An archaeology dig into "why do fan walls take so long?" found something better: on the current cloud infrastructure they weren't slow, they were impossible. The video-rendering engine still expected a worker fleet from the old Kubernetes days — a fleet that no longer exists — so every fan wall, film and audio mix quietly failed the moment it started. The renderer now runs right inside the processing service (which has had FFmpeg on board all along), and fan walls render again. While we were in there, we fixed the crash that hit auto-start walls created on campaigns that already had plenty of content.

Clients can now watch their running costs the way they watch their uploads. A new Costs section in Reports shows, month by month, exactly what's been used — fan contacts captured, AI images generated, videos processed, emails sent, fan walls and films produced, and every paid AI call in between — with each line priced at the account's rates after its monthly free allowance is used up. Not an invoice, but a very honest preview of one.

Every FanMoment image the AI generates now carries three non-negotiable instructions baked into the prompt, whatever the campaign's scene prompt says. Think of it as the studio's house style guide: heads the right size, skin tones true to the fan, logos exactly as the brand intended.

When Smart Films replaced the random film generator, we left its three retired campaign settings in the database as ghosts — insurance in case we needed to roll back. The new engine has proven itself locally and the ghosts have now been laid to rest.

A detective story: fan wall pages on the live site would sometimes hang for minutes, and the culprit turned out to be a single innocent-looking line that asked the database "do we have any users yet?" — on every single request, while holding up the only available thread. The platform was politely serving logged-in requests one at a time, like a bank with one teller. The teller now remembers the answer. Also, fan walls that are waiting for more content now tell you how much they're waiting for.

The FanMoment — AI Scene editor has been rebuilt to match the new FANDEMiQ design language. Same brains, much better face: everything you need to configure a FanMoment now lives in tidy cards on the left, with a proper test bench pinned on the right so you can see exactly what fans will get before you flip it Live.

A shared media file whose stored copy had gone missing (long story: an old background job once ate two font files) would take the whole request down with a server error. Now the platform shrugs gracefully — if the file lives somewhere public, you're sent there; if not, you get an honest "not found" instead of a crash.

Automatic films used to be a slot machine: random clips, random cuts, and no off switch — hundreds of near-identical films if you let it run. This release replaces the whole engine. FANDEMiQ now reads the AI video analysis of every fan clip (what's happening, who's cheering, exactly when) and plans each film like an editor would — to your brief.

The old Reports page was five static cards and a scheduled CSV email. This release replaces it with a proper analytics dashboard — graphs, filters, leaderboards — plus Florence, an AI analyst who answers questions about your account's data in plain English.