The Operating Model

Why this exists

Rapoport Studio builds digital platforms and AI-powered infrastructure. We work on things that matter — not because we were asked, but because they matter. The studio does not sell hours. The studio builds systems that keep working when we are not around.

This whitepaper exists because the way we work is itself the product. We are a curator of teams who use AI as the orchestration substrate of a platform, not as a feature bolted on. That sentence has consequences — for how engagements are scoped, how specialists are assembled, how decisions are recorded, how deliverables are owned, and what we decline. The pages below describe those consequences in the order a prospective client (or specialist, or partner) would need them.

What we publish here is also the contract. The same prose lands inside your repository as openspec/_methodology/rapoport-studio-engagement.md when an engagement begins. There is no marketing version on top of an internal version — there is one version, and you are reading it.

Curated teams, not staff augmentation

Most agencies operate one of two ways: a fixed staff that ships every project (limits the work to the staff's expertise), or a Rolodex of freelancers stitched together per engagement (limits the work to whatever the Rolodex covers). Both lose to a third shape — a curated team, where the studio assembles a hand-picked group of specialists around the shape of your problem, not around our pre-existing roster.

The difference is concrete:

The brief generates a demand vector — a list of disciplines the work actually needs (OpenSpec authoring, business-model validation, domain expertise in clinical psychology / law / finance / regulated industries, product copy, brand design, security review, accessibility review, compliance review, frontend, mobile). New disciplines join the demand vector the moment an engagement legitimately needs them.
The studio's matching layer suggests candidates from the network. Pavel and the client review the shortlist together and confirm the roster. Matching is suggestion; the human picks.
Every specialist on the team is trained, NDA'd with the studio entity (not with you), and certified before they touch a paid engagement. The client signs one NDA — with the studio. The studio's downstream obligations flow through to each specialist.

The curated-team shape composes with any stack and any organization size. The studio's deliverable is markdown that compiles in your team's heads — specifications, decision records, drift reports — not a parallel team that costs as much as yours.

A consequence worth naming: the studio's network is not a vendor pool. Specialists work inside the studio's canvas surface alongside an AI substrate that holds the conversation. They do not receive access to your repository, your secrets, your database, or your tracker. The work is bounded, auditable, and revocable — the curated-team shape only matters if it stays inside those bounds.

Five-persona role taxonomy

When a team forms around an engagement, the work itself organizes along five soft-routing axes. We call them personas, but they are framings, not job titles. Most specialists wear two or three of them across an engagement.

Persona	What this persona attends to	Example questions it asks
Architect	The shape of the solution — what gets built and how the pieces fit.	"Where is the boundary between this engagement and the rest of the platform?" "Which capability spec does this proposal amend?"
Domain	The truth of the field — what is technically or legally or clinically real.	"Is that retention claim defensible under GDPR Art. 5?" "Does that pricing assume a market that exists?"
Tech	The execution constraints — what can ship in this stack, in this timeline, with this team.	"Will this work under Cloudflare Workers' execution-time limit?" "What does the migration look like at 100× the current row count?"
Business	The economics — what makes the engagement worth doing for the buyer and for the studio.	"What is the unit economics floor below which this is unprofitable?" "Who is the buyer for this output? What do they pay?"
Ops	The operational reality — what happens after delivery, who owns it, how it degrades.	"Who is on call when this breaks?" "How does retention decay if the team that ships this leaves?"

The personas are also the modes in which our AI substrate (next section) frames a draft. When a specialist requests an Architect-shaped version of a proposal, the substrate produces a draft skewed toward boundaries and capability mapping; when a Business-shaped version is requested, the same content reorganizes around revenue logic and price sensitivity. The output is a soft framing cue, not a different document.

A team rarely has one human per persona. A senior practitioner carries three or four personas comfortably; an engagement-specific specialist (a clinical psychologist, a banking regulator) usually carries one — Domain — with depth that no other team member can match. The persona vocabulary lets the team route work without rebuilding the cast.

Engagement charter

The studio operates in one of three engagement modes per project. The mode is declared at kickoff and recorded as the engagement's first decision. It defines what the studio touches in your environment, what access it asks for, and what artifacts it produces.

Deliverables-only mode (default). The studio authors OpenSpec changes; your team implements them. The studio never commits code into your repository. The deliverable is the spec triplet — proposal.md, design.md, tasks.md — packaged under openspec/changes/<slug>/ and shipped as a patch or tarball your team places in their tree. You own implementation, review, merge, deploy. The studio owns spec quality and domain modeling.

Hybrid mode. Same authoring loop, plus the studio may draft code for selected tasks via fork-PR onto a studio/<slug> branch in your repo. Your team reviews, edits, and merges (or rejects). The studio's bot never targets main directly, never opens or modifies CI workflows, and never installs new top-level dependencies without prior design.md approval. Hybrid is appropriate when your team wants the studio's authoring discipline plus implementation acceleration on bounded tasks without giving up code ownership.

Full mode. Same authoring loop, plus the studio writes code on forge/<change-slug>/<task> branches and opens PRs to main. Your team's review remains the final gate; final merges to main are always yours. Full mode is appropriate when the studio is the primary engineering bandwidth on a project — the relationship is closest to "studio runs the build, your team owns the product."

In every mode, the same hard out-of-scope list holds:

No edits to openspec/current/. The studio drafts changes; your team performs the live amendment to current/ at archive time. The ## <Title> (applied YYYY-MM-DD from change <slug>) pattern is documented for your team to apply, not for the studio to apply.
No direct merges to main. Always your team.
No infrastructure ownership. Cloud accounts, secrets, DNS, deploys, runbooks — yours.
No secret access. The studio never receives, holds, or transmits your secrets. Sample env vars carry names, never values.
No on-call. The studio is asynchronous. Response SLA is business days (Moldova, EET/EEST), not 24/7.
No legal or compliance opinion. Surfaced in specs as constraints; the legal opinion is your team's.

The mode is reversible. Escalating from Deliverables-only to Hybrid mid-engagement is a documented decision; revoking it is the same. The studio does not unilaterally escalate.

Specialist network

The specialist network is the studio's compounding asset. It is also the answer to the question why curated teams beat staff augmentation. Three properties stack:

Prose-style OpenSpec discipline. Every specialist writes against the same proposal.md / design.md / tasks.md shape. Cross-engagement reuse becomes possible because the artifacts have the same skeleton.

A shared substrate. Every specialist conversation runs in the same canvas with the same AI substrate, with auditable turns. A specialist's session is reviewable, replayable, comparable across engagements.

Specialist-contributed prompts and tools. Over time the network's accumulated prompt augmentations become the studio's compounding asset. A new business-model validator joining in 2027 inherits everything 2026's validators learned. When a contribution survives three independent engagements with positive quality signals, the studio promotes it to the common library — and the contributor is named in the prompt's metadata.

The network's discipline list is open by design. Examples of disciplines the studio runs today:

OpenSpec authoring — write the spec triplets in the studio's house style. The load-bearing specialist on most engagements.
Business-model validator — probe monetization, pricing, unit economics. Stress-test proposal claims with numbers.
Domain expert (clinical, legal, finance, regulated industry) — anchor design claims in domain reality. Catch what generic AI substrates hallucinate.
Product copywriter — voice, tone, microcopy. Especially when the product runs in a non-English market or in a regulated emotional register.
Brand / UX designer — tokens, components, surface composition.
Security reviewer — threat-model the spec; gate the design choices.
Accessibility reviewer — read ui.md / design-system.md against WCAG.
Data-privacy / compliance reviewer — GDPR / HIPAA / sectoral regs.
Frontend / mobile specialists — implementation discipline for surface specs.

The list grows with demand, not in advance.

Specialists are not freelancers; they are network members who pass a two-axis training cycle (OpenSpec authoring + business-model validation) and reach one of four tiers — Apprentice, Certified Reviewer, Certified Author, Senior. Tier dictates eligible engagement scope: only Certified Authors can author root drafts; only Seniors can senior-review another specialist's training changes. The barrier to entry is high (NDA + training + certification), which is the point — it filters out volume-shaped competition.

Spec-driven methodology

Every meaningful change in a studio engagement is drafted as a prose-style OpenSpec triplet. Three files per change, in one folder:

openspec/changes/<slug>/
├── proposal.md   # Why + What changes
├── design.md     # How (interfaces, data shapes, boundaries, decisions, open questions)
└── tasks.md      # Phased checklist for the implementer

There is no specs/ directory, no per-capability delta files, no Requirement blocks. The methodology's central insight is that prose carries decisions better than form. A proposal.md is a single document a person can read in one sitting and disagree with paragraph-by-paragraph; a fragmented spec is the same content scattered across templates that resist disagreement.

Each change records decisions and open questions inline as numbered references — D-<prefix>-1, D-<prefix>-2, Q-<prefix>-1. These survive past archive: future agents reading the codebase can find the why of a given line by tracing it back to the decision that ratified it. The decision-as-source-of-truth pattern is what makes the corpus self-documenting; it is also what makes the studio's prompts and AI substrate behave reliably across engagements.

When a change ships, your team performs the live amendment: append a dated section to the relevant openspec/current/<capability>.md file in the form ## <Title> (applied YYYY-MM-DD from change <slug>). Then rename openspec/changes/<slug>/ to openspec/archive/YYYY-MM-DD-<slug>/. The studio does not perform this step — it lives entirely on your side. The studio re-reads your current/ at the start of every new change to stay aligned with what your team has accepted.

The corpus is the studio's credibility artifact. We publish ours at github.com/rapoport-studio/openspec as a living example — the charters and templates the studio operates under are visible there as plain markdown, the same shape that lands in your repo at kickoff. If you want to see how the studio thinks before engaging, read it.

A longer treatment of the prose-style discipline lives in the lab as The OpenSpec method, in production.

AI substrate

AI is the orchestration substrate of a platform, not a feature bolted onto it. That is the studio's thesis. In practice it means the studio operates three coordinated CLIs that participate in every engagement.

Muse — the spec-authoring substrate. Muse is the AI personality that drafts proposal.md / design.md / tasks.md triplets in the studio's canvas surface. It runs in modes — Architect (active), Builder (active for studio-internal Forge orchestration), Scout and Canvas (deferred). When a specialist joins a canvas, Muse loads their personal prompt augmentations and tool list alongside its base configuration — so the conversation gets the specialist's domain framing without the specialist having to re-explain it each session.

Forge — the build executor. Forge turns approved OpenSpec proposals into pull requests. forge build <RAP-issue> orchestrates plan, code, migration, and verification phases against a Linear-tracked issue, opens a PR titled <LINEAR-ID>: <task title>, and the PR enters your team's normal review. Forge respects every boundary from the engagement charter — no direct merges, no current/ edits, no secret access, no on-call.

Maestro — the telemetry and routing surface. Maestro is the operator's lens. maestro lineage <issue> shows the full event trace from spec authoring through build through PR — every LLM turn, every cost, every reviewer hand-off. The studio uses Maestro to audit its own work; clients use it (when present) to verify that the spec we delivered matches the code that landed.

All three CLIs emit structured events to a shared event log. The studio's audit posture is every turn is reviewable. There are no "what did the AI do?" mysteries — the trace is the answer.

The substrate is operated by humans, not the other way around. The studio does not run unsupervised agents. We do not deploy autonomous loops into production codebases. We do not pretend that AI replaces the specialist; the specialist's prompts and tools extend the substrate, and the substrate's drafts anchor the specialist's review. The discipline is bidirectional.

A longer treatment lives in the lab at Agent-native, not AI-powered.

Engagement lifecycle

Every studio engagement moves through five stages. The boundaries are clean enough that you can tell where you are at any moment.

1. Discovery (3–4 weeks, fixed scope). A short, paid discovery engagement — fixed-scope and NDA-bound — produces the engagement's domain map. Mirror's seven canonical steps (actors, resources, states, transactions, integrations, communications, metrics) get filled in collaboratively across the canvas with you, the relevant specialists, and Muse. The deliverable: a signed-off domain map and the first batch of OpenSpec changes drafted. Discovery may stand alone if you only need the map.

2. Spec authoring. Each meaningful change is drafted as a proposal.md / design.md / tasks.md triplet inside the canvas. Specialists supply domain claims, contradicting positions, and tone calibration; Muse drafts the structural prose and citations; the engagement's lead arbitrates and ships. Each triplet is tied to one Linear issue.

3. Implementation. This stage's shape depends on the engagement mode. In Deliverables-only mode, your team implements; the studio ships drift reports on request. In Hybrid mode, the studio drafts code for selected tasks via fork-PR; your team reviews and merges. In Full mode, the studio writes implementation on forge/<change>/<task> branches and opens PRs to main. The boundaries from the charter hold absolutely in every mode.

4. Delivery. When all tasks for a change merge, your team archives the change folder and amends the relevant capability spec. The studio runs a final drift audit on request — forge audit <module> reads your current spec against the implemented code and reports divergence as a markdown report.

5. Retainer (optional). When an engagement carries continuing change pressure — a roadmap that will produce three to ten more changes — the studio carries a retainer arrangement that keeps the curated team available without re-onboarding cost. Retainers are explicitly scoped: a monthly cap on changes drafted, a clear notice-period for termination, and the same boundaries from the original charter.

The lifecycle's shape is deliberately front-loaded. Discovery's value compounds across every subsequent change because the domain map carries forward; the implementation stage is consequently faster than a cold start of the same scope. We have written about the four-week discovery rhythm in the lab at The four-week discovery.

Deliverable ownership

The IP cascade is the simplest possible:

Your specs are yours. Every proposal.md / design.md / tasks.md the studio authors during your engagement is delivered to your repository and is yours to keep, edit, or fork. The studio holds no claim on the prose after delivery. If the engagement ends, the specs remain in your tree and continue to work — they are markdown, they do not depend on a runtime, and your future agents can read them whether or not the studio is involved.

Your code is yours. In Hybrid and Full modes, every commit the studio authors is on a branch your team reviews and merges. Once merged, the code is in your repo under your team's name (or under the studio's bot account if you prefer to record the authorship that way — the engagement's Appendix B records the preference). The studio does not retain shadow copies, alternate branches, or "studio-internal" versions of your code.

Studio methodology is the studio's. The prose-style OpenSpec discipline, the canvas substrate, the specialist training curriculum, the studio's prompts and tools — these are the studio's IP and are licensed to your engagement for the engagement's duration. After the engagement closes, the methodology continues to be visible on the public mirror; your engagement-specific application of the methodology stays in your repo.

Specialist contributions are governed by the base NDA. Every specialist has signed an NDA with the studio entity that includes IP assignment of work-product to the studio under their compensation contract. The studio in turn flows the obligations through to you: the specialist's deliverable into your engagement is yours; the specialist's general methodology improvements (e.g. prompt augmentations that get promoted to the common library) remain studio IP.

The escape clause: the engagement charter delivered to your repo carries an off-ramp that is explicit. Close the engagement. Take the spec. It still works.

Quality system

Quality in the studio is not a checklist — it is a set of structural defenses against the failure modes that actually happen.

Audit signals, not velocity metrics. The studio does not track specialists by hour-counts or velocity. Per-engagement signals include senior-review delta (number of structural critiques senior reviewers add before delivery; should fall over time), client revisions requested (should fall), spec-fidelity audit score (forge spec drift report against the specialist's authored capabilities), and implementation feedback when code lands.

Drift response. If a specialist's signals degrade across two consecutive engagements, status moves to under_review in the registry. A senior reviewer pairs with them on the next engagement; if signals don't recover in the next two engagements, the specialist moves to inactive. Their contributed prompts and tools remain in the library; their access is revoked.

Spec hygiene reports. On request, the studio runs forge audit <module> and forge spec <module> against your openspec/current/ corpus and reports drift between specs and code. Read-only against your repo. The output is a markdown report, not a PR — your team decides how to respond.

Decision-record discipline. Every architectural decision is captured inline as D-<prefix>-N in the relevant design.md. Open questions are captured as Q-<prefix>-N. Both survive past archive. The next engineer reading the codebase six months later can find the why without an oral-history conversation.

Quarterly network review. The studio reviews network-level signals quarterly: median certification time, median engagements per specialist per year, specialist-contributed prompts promoted to the library, engagement-client satisfaction. The targets are informational, not contractual — they are how the studio measures itself.

The quality system is built into the artifact, not bolted onto a separate process. A studio engagement that lands with clean decisions.md, clean forge audit output, and a falling senior-review delta is one whose quality is verifiable by inspection. We prefer artifacts that compile in your team's heads over commitments that compile only in a PowerPoint.

What we don't build

The shape of the studio is as much defined by what it declines as by what it accepts. We have written about this elsewhere — read What we don't build for the full treatment.

The short version: we don't run unsupervised agents in your environment; we don't take on engagements without a discovery phase; we don't compete on price below the studio's published floor; we don't sell hours; we don't promise that AI replaces a specialist; we don't operate on weekends or holidays; we don't onboard specialists without training; and we don't write code we can't put under review.

Each of these refusals is structural — saying no to them is what makes the rest possible.

How to engage

Engagements begin with a brief. If your work fits the studio's shape — a multi-month, retainer-grade engagement where the operating model above is the right fit — the path is:

Submit a brief. Tell us what you're trying to build and what's getting in the way. There is no template; we read prose.
Discovery conversation. A short, paid discovery engagement (fixed scope, 3–4 weeks, NDA-bound) produces the domain map and the first batch of changes. Discovery may stand alone if that's all you need.
Engagement decision. After discovery, both sides decide whether to continue into a full engagement. The mode (Deliverables-only / Hybrid / Full) and specialist roster are confirmed; the engagement charter lands in your repository; work begins.

The studio is not the right shape for every project. We are not a good fit for: short-burn agency work, staff augmentation, AI-powered MVPs that need to ship in two weeks, engagements without clear deliverable ownership, or projects where the studio would be asked to break its hard out-of-scope list. If you recognize your project in any of those, we will respectfully decline.

If you recognize your project in the rest of this whitepaper — write to us. How to engage →