From Business Case to System Specification

The ask

The client team reached out with a strong business case and a live problem. They already ran a production company making shows the classical way — a writers' room with multiple contributors: someone invents a character, someone else writes dialogue, someone else builds out the world, the setting, the supporting cast. An idea starts as almost nothing and gets sharpened over months by everyone who touches it. Attribution across that process is genuinely hard — many hands shape the same asset before it ships.

The idea was to introduce attribution and idea-provenance mechanisms — a way of tracking who contributed what to a piece of IP as it took shape.

The deeper problem was ownership. Along the way, contributors don't end up owning the IP they help generate, and can't monetize it — even though their reputation depends heavily on the contributions they make and the ideas they produce. Authorship and proper credit matter for a creator's future standing, and the process wasn't built to preserve either. The idea was to use crypto and web3 to fix that: tokenize the IP, and build an attribution and reputation system around idea generation and content creation. My job was to fit this into an engineering process first.

Presence on a project isn't the same as value added — the classical film industry already weighs several factors to tell them apart: when a contribution happened, how much it actually shaped the final output, who else was in the room, and a contributor's track record, since reputation and past work colour how a new contribution gets read. The plan was a set of processes that could estimate a creation's "potential," with each person's actual contribution as one input. Who is better positioned to judge that than the people who were actually in the room? The mechanism measures contribution through peer evaluation: the team assessing itself, rather than an external judge with no visibility into the process. That's a classical reward-division problem, complicated by a specific wrinkle: the judgments involved are unverifiable, even after the fact, and subjective. Peer evaluation mechanisms are the field's answer to exactly that pairing, and Bayesian Truth Serum (Prelec 2004) was our point of departure — the full mechanism is covered in Attributing Contribution.

Discovery and requirements

Discovery started with a review of what the client team already had: several documents covering system vision, draft processes and value flows, example token representations and flows, token use cases, one candidate metric for reputation (EigenTrust), and a market/competitor assessment. Findings from that review revealed that the vision was clear, and subsystems were already named informally — a writers' room, a licensing system, a character pool, a producer program — but everything lived in descriptive language and high-level diagrams. No formal requirements, no state space, no mathematical model on which to specify and build the mechanisms.

We ran a quick discovery process to gather the information needed to finalize the formal scaffolding of agent, role, mechanism, and subsystem mapping, plus early-stage identification of a candidate reputation mechanism. We covered system goals and requirements, stakeholder and role definitions, value flows, subsystem definitions, metrics, stocks and flows, governance structure, and token functionality. The effort here was narrowing the idea down to a formal representation quickly enough to build every subsequent phase on top of it.

Segregating into three subsystems

The business case decomposed into three logically separate subsystems designed for each stage of an asset's life: produced, evaluated, monetized.

Production — segmented, sequential, peer-judged

The production process itself is segmented and sequential: one person's (or team's) world-building feeds the next person's dialogue feeds the next person's art. That structure is exactly what makes truthful, subjective peer evaluation usable in the first place — because contribution happens in a visible sequence, the people immediately upstream and downstream of a given contribution are positioned to judge it, even though no outside party could. The production subsystem's job is narrow and concrete: given that stream of peer judgments, define how much of an asset's output shares get allocated to each contributor along the way. See Shared Ownership of Creative IP.

Reputation — portable status, measured from outside

Peer evaluation inside one project answers "who contributed what, here." It doesn't answer a harder, separate question: how does a contributor carry that record with them — into the next project, in front of people who weren't in the room? The reputation subsystem exists to turn a series of internal peer judgments into a portable, externally legible signal: participation in successful projects, a track record of specific skills or capabilities, something a future collaborator or backer can actually read from the outside. See Attributing Contribution and Reputation as a Measurement Layer.

Monetization — tokenized IP, pro-rata, for two constituencies

Once an asset exists, it needs to be sold, and whoever contributed to its value needs to earn from that sale in proportion to what they put in. Tokenization is the mechanism: the IP is represented granularly, as tokens, and revenue from the finished asset flows pro-rata to the tokens outstanding — so the market for the shared creative IP and the reward split for the people who built it are the same instrument.

There's a second factor beyond craft quality, though: how well an asset is known and promoted also drives what it's worth. Hype and promotion are themselves value-adding activity, not just the writing and world-building that produced the asset in the first place. So ownership couldn't stop at the production team — it had to extend to the people who made the idea big: the community and fanbase around the IP, carrying the same reputation and ownership-token logic outward to a second constituency alongside the first.

Three subsystems, one for each of these design problems — segmenting them let each get the mechanism it actually needed, rather than forcing peer evaluation, portable reputation, and market pricing into one monolithic scheme.