Administration

This page is for platform admins: the Klyo operators who work across Organizations to onboard clients, watch for failures, and check what is deployed. A platform admin is a Klyo-level role, separate from your role inside any one Organization.

What works today

Onboarding (declaring a client's project, probing it, enabling APIs, creating the bucket, storing the Creatomate key), the cross-org organizations and users consoles, the monitoring and failure console, the credit ledger, the language model registry, and the system version page are all wired. One thing it does not do is create Google Cloud projects for clients; see the note in onboarding.

Onboarding an Organization

Onboarding connects an Organization to the Google Cloud project that will run its generation and hold its assets. The flow lives in the admin organizations console, where you pick an Organization and open its setup panel.

1. Declare the data plane: the client's Google Cloud project, region, and assets bucket.
2. Probe it. Klyo checks the project against a checklist of requirements and reports each as pass, fail, blocked, or not-yet-checked.
3. Fix the gaps: enable a missing API on the project, or create the assets bucket, straight from the checklist.
4. Add the Creatomate render key, stored as a Secret Manager reference. Klyo keeps the reference, never the secret value itself.

Klyo reaches the client project through a single shared service account that the client grants roles to. The setup panel shows that service account and the roles to grant.

The setup checklist

The checklist has required and optional items. The required ones decide whether the Organization is ready:

• Required: Klyo can reach the project, the Cloud Storage API is on, the assets bucket exists, the per-Organization task queues are provisioned, and the Creatomate render key is configured.
• Optional: Vertex AI (for generation), billing linked, Display & Video 360, and Google Ads.

An Organization moves from draft to ready when the required checks pass, and flips to error if a ready Organization later regresses, for example if a role grant is revoked. That state change is recorded as an Action, so a regression shows up in the activity and failure views.

Klyo does not create projects

Onboarding probes and configures a project that already exists. Klyo does not create the Google Cloud project for the client. The "provisioning" state exists in the model but is not used, because project creation is not part of the app.

Moving an Organization to another project

Sometimes an Organization has to change the Google Cloud project or bucket it runs on: the client moves to their own project, a bucket was created in the wrong region, or a trial project is replaced by the real one. Once the Organization holds any assets, the project, bucket, and region fields on the setup panel are read-only, and a data plane move is how they change. The move lives in the same setup panel, on the Provisioning tab.

The move exists because the fields on their own are only labels. Changing them by hand leaves every asset pointing at a bucket that does not hold the file, and nothing warns you. The move copies the files first, checks they arrived, and only then changes the labels.

It runs in five steps, and you drive each one:

1. Declare the destination project, bucket, and region. Nothing is touched.
2. Prepare. Klyo checks the destination, switches on the APIs it needs, and creates the bucket with the same settings the current one has. The Organization keeps working normally on the old project the whole time, so if the destination turns out to be wrong, you can fix it and prepare again at no cost.
3. Copy. Files are copied straight from one bucket to the other, in batches. You can leave and come back; the next copy picks up where the last one stopped. The Organization is still fully live.
4. Wait for work to finish. Once the copy is done, the Organization's data plane is frozen. Klyo then waits until nothing is still running.
5. Cut over. Klyo copies anything that changed, checks every file exists at the destination, switches the Organization over, re-checks the project and the AI models, and unfreezes.

What the freeze means for the Organization's users

A frozen Organization is not locked out. People can still sign in, read everything, browse campaigns and assets, plan, and edit. What they cannot do is start something new that writes files: a generation, a render, an upload, a feed sync, or an activation pack. Each of those refuses with a message saying a move is in progress, and works again as soon as it finishes. Anything already running keeps running, which is the point: the cutover waits for it.

Tell the client's team before you freeze, and pick a quiet window. Expect the freeze to last about an hour in the worst case, since every running job has a time limit inside that.

What the move cannot fix

If the client's feed holds full gs:// links to the old bucket in a text column, those links stop resolving after the cutover. That data lives in the client's own feed, not in Klyo, so the move cannot rewrite it. Klyo counts how many it found and reports the number at the end; pass it to the client so they can update their feed.

The old bucket and project are left alone. Klyo never deletes them, so a rollback is available while the Organization has not done any new work, and switching the old project off afterwards is a deliberate step someone takes by hand once the client is happy.

Channel connections

Before a campaign can activate, someone connects the ad channels it will publish to. A connection is one authorized account (a YouTube channel, a Google Ads account, or a DV360 advertiser) that Klyo can act through. Any member can see the connection list read-only (its health, accounts, and last check) on the Organization page's Connections tab, since the list holds no secret. Creating, re-checking, and disconnecting stay Organization admin (or platform admin) actions. On the Activation plan step, every activation target still shows: one whose connection is missing is locked with a "Connect X to unlock" pointer, not hidden.

Each provider connects its own way:

• YouTube and DV360: sign in with a Google account. Klyo opens Google's consent screen, and after you approve it keeps only a reference to the refresh token (in Secret Manager), never the token itself. YouTube then lets you pick which of the account's channels to use.
• Google Ads: Connect asks which of two ways you want, and either one on its own is enough. Sign in with Google is the same handshake as above, then you pick which Ads account to use; it stops working if that Google account loses access or the grant is revoked. Link under Klyo's manager account stores no token at all: accept the manager link invitation from Klyo's manager account (the chooser names its customer id) inside Google Ads first, then enter the account's Customer ID. A manager (MCC) account is listed but not selectable, since it only manages others and cannot run a campaign.

A channel usually holds one account. It can hold more than one (two Ads accounts, two channels), and a Campaign then picks which of them it activates through; the "+" on a connected row is what adds the second.

When you reach connections from an activation surface (the queue's health strip or a connect link), finishing the sign-in returns you to the step or queue you left.

A DV360 connection also authenticates the nightly Reporting pull: a Tracked Campaign reads through the same connection, so keeping it healthy keeps its KPIs flowing.

Klyo re-checks each connection's health and shows it (connected, needs attention, or reconnect); a connection that goes bad notifies the Organization's admins. Health does not wait for a manual re-check: the auto-activation drain, a failed push, and the metrics pull each record what they find and ring the same admin alert. A validation also catches a partial consent, a permission left unticked on Google's consent screen, and flags the connection with the missing permission named instead of passing as connected and failing later. Before you disconnect one, Klyo shows how many activations still reference it.

Nothing tells Klyo that someone revoked a grant in their Google account, so a connection nobody has pushed through would otherwise sit on its last verdict. A background sweep re-checks any connection whose last check is over 30 days old, a few per Organization per run so a big list spreads over consecutive sweeps. A probe that cannot reach the provider at all records no verdict, since a provider outage is not a broken connection; it comes back up for a re-check a few hours later. By hand, Re-check all above the list re-probes every connection at once, and a row whose last check is over a week old turns that date amber to invite one.

A row's Details button opens the connection in full: how Klyo reaches the account (a Google sign-in, or a manager link that stores no personal grant), the permissions the grant carries, who connected it and when it was last verified, and every creative released or hosted through it, newest first. That usage list is the answer to "what breaks if I disconnect this".

Proving a connection works

A health check authenticates the stored credential and reads the account name back. That is a read, and the permission that actually fails at release time is the write. So a connection can be proved end to end at the moment you set it up, from its Details panel, in two deliberate steps:

1. Send test creative pushes a bundled sample video live through the connection, using the same code path a real release uses. The result is harmless on purpose: a YouTube upload is private, a Google Ads Demand Gen ad is created paused (it cannot serve or spend), and a Campaign Manager 360 creative is assigned to no placement.
2. Open the provider's own console and confirm with your eyes that it arrived where you expected.
3. Remove the test creative takes it down again. The connection remembers exactly what it created, so the removal is precise; if a removal fails, the reference stays on the row so you can retry rather than lose track of something live.

Both steps are admin-only and neither runs by itself. Two provider notes: the Google Ads test needs the YouTube test to have run first, because a video ad has to reference a YouTube-hosted video (the same order a real release follows), and a Campaign Manager 360 test leaves an archived creative behind, since its API offers no delete. DV360 has no test at all: its release path is a manual export, so there is nothing to put live and the button is absent rather than broken.

Sharing a connection with a child organization

Connections do not inherit the way templates, assets, and catalogues do (see Organization families). A connection is the authority to publish and spend on a live ad account, so the parent grants it deliberately, one connection to one child, from the connection's Details panel. No grant means the child cannot see the connection at all.

A child that has been granted one selects it exactly like its own wherever a channel is picked: publishing, hosting, handoff packs, auto-activation, the ad group browser, and Tracked Campaigns. It can also re-check the account's health, so it can diagnose a degraded account without waiting on the parent. It cannot disconnect it, point it at a different account, share it onward, or run the end-to-end test above: those write to the owner's credential or their live ad account, and Klyo refuses them by naming the owner.

Revoking a grant takes effect on the child's next read. Work already published keeps its activation history, exactly as a disconnect does.

Google Ads needs a developer token

Live Google Ads calls, including listing accounts, need Klyo's Google Ads developer token to be configured. Until it is, a signed-in Google Ads connection reads "not configured".

Cross-org consoles

Platform admins get views that span every Organization:

• Organizations: list every Organization, see who created it, create new ones, and open one to onboard it.
• Users: a directory of every user, filterable, with the ability to suspend and restore.
• Monitoring: cross-org Actions and generation jobs, with stat cards and filters, and the failure console for acknowledging failures. Opening an Action here also shows the actual provider request behind a generation or render (the prompt, model, resolution, and reference assets sent to Google or Creatomate), a platform-admin-only view that regular Organization members do not see. An LLM usage tab audits every assistant turn: who asked, the question, which tools ran, token counts, and failures. Two more tabs span the platform: Language models, the model registry, and Credits, every Organization's credit account with the overdrawn ones first. See Activity and failures.

Credits

Credits are how one Organization's spend is metered. Every real cloud cost Klyo causes is priced on a platform rate card: language-model tokens (an input and an output rate per 1,000 tokens), each generated image, each voiceover, each generated clip (priced per second by the model and resolution it ran at), and each Creatomate render. That cost is converted to credits by the Organization's own rate, cents per credit, and debited from a weekly balance. The Credits tab on the Organization's setup panel is where you read and set all of it.

• The stat band reads the balance left this week, what has been spent since Monday, and the weekly limit.
• The balance is restored to the weekly limit every Monday. Changing the limit takes hold at the next reset; it does not move the current balance.
• Metering never blocks a call. A campaign that runs past its limit keeps working and the balance goes negative, which is the signal to raise the limit or talk to the client, not a stop.
• The ledger lists every movement newest first: a debit for a priced operation (with what it was for), an adjustment you made by hand, and the weekly reset. Filter it by kind.
• Adjust posts a manual movement: a positive amount grants credits, a negative one corrects the balance down, and the note you write stays on the ledger row.

An Organization has no credit account until you set a rate and a weekly limit; creating one opens the balance at the limit. Monitoring carries a cross-org Credits tab that lists every account with the overdrawn ones first.

Language models

Klyo's AI features (the assistant, ideas, storyboards, ad copy, brief drafting) run on a Gemini model you choose per Organization, and the choice comes from a platform registry rather than free text.

The registry lives on Monitoring's Language models tab. Each entry carries its model id, its endpoint, optional per-model prices, and a status: unverified until it has been tested, verified once it answered a live call, retired when it is kept for history but no longer offered on a slot. Test makes that real call and records the version the endpoint actually served, because Google's model-listing API is unreliable and a wrong model id fails opaquely rather than with a clear error. Only a verified model can be assigned to an Organization. A blank price bills at the platform flat rate.

The assignment lives on the Organization's own Language models tab, which has two slots:

• Default model, what every AI feature uses. Left on Platform default, the Organization falls back to the built-in platform model.
• Deep thinking model, the harder-reasoning option offered for tougher turns. Left off, Deep thinking is unavailable for that Organization and everything uses the default.

Each slot takes an optional thinking level, how much internal reasoning the model spends before answering, trading latency and cost for a better answer. Saving re-probes each set model on that Organization's own data plane, so a model that cannot be reached there fails the save with the provider's own message instead of breaking later mid-campaign. An Organization with no data plane yet cannot save a slot at all.

No EU residency guarantee

Every model is served from the Vertex global endpoint today, whatever a registry entry's endpoint label says, so no assignment carries an EU data residency guarantee. Regional serving needs a Vertex region that has been configured and tested, which is why it cannot be picked yet.

System

The system page reports the basics of what is running: the service name, its version, and the deployment environment (dev, staging, or prod), with a plain note on what each environment means.

What you can do today

• Onboard an Organization: declare its project, probe it, enable APIs, create the bucket, and store its Creatomate key.
• Read the live setup checklist and the Organization's readiness state.
• Move an Organization to a different project and bucket, with the files copied and checked before anything switches over.
• Manage Organizations and users across the whole platform.
• Watch cross-org activity and acknowledge failures.
• Connect the ad channels (YouTube, Google Ads, DV360) on the Organization settings page, and watch each connection's health.
• Open a connection's details to see how it is reached, what it may do, and every creative released through it.
• Set an Organization's credit rate and weekly limit, read its ledger, and adjust the balance by hand.
• Register and live-test a Gemini model, then assign an Organization its default and Deep thinking models.
• Inspect the provider request behind a generation or render Action.
• Check the running version and environment.