Team name: Lala land Track: Creative Lane: Build
Short summary
Lala Land moves a ghostwriter's client voice profile out of the writer's Doc and ChatGPT Project and into the client's own AI Passport: a revocable, read-only pass the client grants, not a copy the writer keeps. The client authors and controls their voice profile, sees every time it's read, can revoke it in one click, and can hand it to a new writer without the old one having anything left to withhold.
Inspiration
A ghostwriter's setup for a new client looks roughly like this: a Google Doc called VOICE_[CLIENT].md, and a ChatGPT Project whose custom instructions are that doc pasted in, with ten of the client's past posts underneath it. The doc holds their register, their banned phrases ("thrilled to announce," "humbled"), their no-go topics, and the handful of biographical facts the writer is allowed to assert on their behalf.
This workflow isn't hypothetical, it's what ghostwriters describe publicly, and it's a sensible way to work. But look at it from the other side. The executive whose voice that is has never read the document. They can't correct it. They can't see when it's used. When the retainer ends in March, nobody deletes anything, and in August their voice profile is still sitting in a Doc, a Project, and an assistant's long-term memory. And when they hire a new writer, they can't take it with them, and the new writer spends six weeks rediscovering that they hate em-dashes.
Nobody in that story did anything wrong. That's the point. The failure mode here isn't a malicious freelancer, it's the honest default: a personal profile that lives permanently in someone else's tools, invisible to the person it describes.
We built Lala Land because that document is in the wrong place. It belongs in the AI Passport of the person whose voice it is.
What it does
Lala Land turns a client's voice profile from a copy the writer keeps into a pass the client grants.
- Kickoff. Instead of the voice questionnaire they already send, the writer sends a pass request. The client sees a standard AI Passport consent screen: Understudy Workspace requests: Voice → read, 90 days.
- The profile is authored by its subject. As the writer learns preferences ("they'd never write 'humbled'"), the workspace proposes them to the client's passport. They land in the client's inbox and are only written if the client approves.
- Runtime read, not copy. When the writer drafts, the assistant reads the pass at generation time. Nothing is pasted into project instructions. Nothing is written to assistant memory. When the draft is done, the context is gone from the writer's side.
- Receipts. Every read logs to the client's passport: Understudy Workspace read voice.register, voice.lexicon.avoid on 4 Aug.
- Termination. The pass expires on the retainer end date, or the client revokes it in one click.
- Transfer. A new writer requests a pass. The client grants it. The voice moves with them, and the old agency has nothing to hand back and nothing to withhold.
What's actually in the pass
The whole design rests on this being small. A Voice Pass carries six fields:
| Field | Contents | Why this is the minimum |
|---|---|---|
voice.register |
3–5 descriptors: "first-person, plain, short sentences" | Descriptors, not writing samples |
voice.lexicon.avoid |
Banned words and phrases | A negative constraint that leaks nothing |
voice.samples.ref |
Pointers to N client-approved published posts | Public URLs, read at runtime |
topics.deny |
No-go list: family, previous employer, the 2023 layoffs | A negative constraint |
claims.factual |
The bounded facts the writer may assert: title, tenure, alma mater | Separate sub-scope, grantable separately |
boundaries.disclosure |
Must output disclose AI assistance? | One bit |
Access is read-only, runtime-only, no export, no retention, bound to one named workspace, expiring on the retainer end date.
The pass explicitly never touches: email, calendar, DMs, drafts, the client's full posting history, company internal data, engagement metrics. It holds the shape of someone's voice, not their life.
The best thing we found in this design is that claims.factual makes the output better and smaller at the same time. The most common failure in AI-assisted ghostwriting is invented biography: the model generalises from a past post and writes "in my years at McKinsey" for someone who was never there. The fix is a short, bounded, client-approved fact set. Privacy and quality point the same direction, which almost never happens.
Who controls it
The client. Not the writer. This is the design decision we'd defend hardest.
The intuitive build is the other way round: the freelancer holds a passport and grants their style context to clients. That's wrong in an instructive way: it puts the personal-data grant on the side of the party with less power, so "connect your context" quietly becomes a condition of getting paid. Lala Land inverts it. The person whose voice it is holds it. The writer holds nothing and grants nothing; their only lever is to request.
What can be revoked
| Trigger | What happens |
|---|---|
| Retainer ends | Pass lapses on its expiry date. Next read fails. Receipt log freezes and stays visible to the client. |
Client revokes claims.factual only |
Voice matching continues; the assistant can no longer assert any biographical fact. Useful during a job change or an NDA period. |
Client adds a topics.deny entry |
Applies at next read. Already-published posts are unaffected; we say this plainly rather than implying otherwise. |
| Client pauses (sabbatical, PR crisis) | Pass suspended, not deleted. Profile survives; access doesn't. |
| Client switches writers | Grant new workspace, revoke old. Voice transfers; agency lock-in breaks. |
| Writer's workspace is compromised | One-click revoke. Runtime-only means there's no stored payload in the breached project. |
How we built it
We went Build lane, and deliberately chose schema over prototype. Three artifacts:
- The Voice Pass definition: fields, scopes, sub-scopes, expiry, and an explicit
excluded:block naming what the pass never touches. - A revocation state machine: Requested / Active / Suspended / Lapsed, with every trigger above drawn as a labelled transition, including the honest dead end where revocation can't reach already-published work.
- Three screens: the consent request, the receipt log with one anomalous read highlighted, and the revoke action with what the writer's assistant sees on its next read attempt.
We picked this format because each judging criterion is a mechanism question. A schema and a state diagram answer mechanism questions directly. A deck can only describe them.
Risks we designed against
A Voice Pass is an impersonation kit. The exact bundle that makes ghostwriting good (register, banned phrases, no-go topics, verified facts) is also the ideal prompt for a fake resignation post or a spear-phish from "the CEO." We mitigate with runtime-only reads, single-workspace binding, one-click kill, and claims.factual as a late-granted separate sub-scope. We won't overclaim here: none of this stops a writer copy-pasting context off their own screen. Lala Land reduces default leakage and creates an evidentiary trail. It is a disclosure and accountability control, not an exfiltration control, and selling it as the latter would itself be the misuse.
Revocation doesn't un-train. If an assistant has already absorbed the voice into long-term memory, revoking stops future reads and deletes nothing. v1 restricts passes to assistants accepting a no-retention flag, and the receipt log gives a contractual no-retention term something to point at.
Receipts become surveillance of the freelancer. This is the one we didn't see coming. A control feature for the client is a timesheet for the writer: a log showing they read the context at 11pm Sunday and not at all Wednesday tells a flat-fee client exactly when and how much they worked, which the client never bought and the writer never agreed to sell. Our fix: receipts default to category-and-day granularity, not timestamps; reads batch per drafting session; and the log is symmetric; the writer sees exactly what the client sees.
What we learned
The strongest objection to this project is that it's a trust-and-contract problem wearing infrastructure clothes: the client picked this writer, an NDA plus a shared Doc covers it. Working through that changed what we think the product is for. An NDA can forbid misuse, but it can't give you your asset back: it can't hand an executive their voice profile so they can walk it to a new writer. Portability is the thing only a passport delivers. And a contract term about "voice data" has no evidentiary substrate today; you can't point at anything. The receipt log is that substrate. The passport and the contract are complements, not competitors.
We also learned that the adoption story has to cost the user nothing. The pass request doesn't add a step to the relationship: it replaces the voice questionnaire the writer already sends at kickoff.
What's next
v1 is one pass type, one relationship shape, and one integration surface. After that: multi-writer studios (one client, several granted workspaces), the same pass shape for adjacent relationships that have the identical problem (executive coaches, speechwriters, agency comms leads), and a public voice.samples.ref convention so the pass can point at published work without ever holding a private archive.
Log in or sign up for Devpost to join the conversation.