<!-- source: openspec/changes/establish-studio-entity-baseline/design.md -->

<!-- source: openspec/changes/establish-studio-entity-baseline/design.md -->

# Design — establish-studio-entity-baseline

> Companion to [`proposal.md`](proposal.md). Captures the rationale, alternatives, and implementation contract behind the five baseline decisions. Phase 1 ratifies the decisions that do not depend on external registration outputs (D-SEB-1, D-SEB-2, D-SEB-4). Phase 3 ratifies the decisions that need real registration values (D-SEB-3, D-SEB-5).
>
> All decisions ratify as `D-SEB-N` in `openspec/decisions.md`; all open items track as `Q-SEB-N` in `openspec/open-questions.md`. Reverting a ratified decision requires a follow-up change proposal that names the original D-SEB-N and supersedes it.

---

## Inputs

This change is grounded in primary Moldovan law and one external advisor consultation. Sources are catalogued in [`research/01-moldova-laws-and-sources.md`](research/01-moldova-laws-and-sources.md):

- **Lege nr. 77/2016** — IT Park law (residency, single 7% tax, allowed CAEM codes, 70% rule). Validity extended to 2038.
- **Lege nr. 135/2007** — SRL law (share capital, founders, management organs, founding-act format).
- **Lege nr. 220/2007** — state-registration law (procedure, fees, supporting documents).
- **Codul fiscal** (Lege nr. 1163/1997), § X art. 367 — single-tax mechanics for IT Park residents; Lege nr. 318/2025 layers 2026 amendments on top.
- **CAEM-2** — economic-activity classifier (BNS Ord. nr. 28/2019), the closed list from which the principal code must be drawn for IT Park residents.
- **FinExpert** — external accountant/registration partner; named operator-side counterparty for registration mechanics. No advisor card yet — to be drafted by `establish-studio-legal-baseline` when FinExpert is contracted.

The studio has no in-house tax practice; nothing below is legal or tax advice. Falsifiable factual claims (formulas, deadlines, allowed codes, statutory minimums) are checked against legis.md / SFS / MITP citations in the research file.

---

## D-SEB-1 — Entity form: Moldovan SRL

**Decision.** Operate as a Moldovan *Societate cu Răspundere Limitată* (SRL), single-founder / single-administrator at Phase 2 onset, multi-asociat-ready per Lege 135/2007 as amended by Lege 229/2023.

**Rationale.**

1. **Liability shielding.** An SRL is a separate legal person with its own patrimony (Codul civil § Persoane juridice; Lege 135/2007 art. 1). Founder personal assets sit outside the entity's commercial risk surface. The two alternatives — *Întreprindere Individuală* (II) and *Persoană Autorizată* (PA / persoană fizică care desfășoară activitate independentă) — both leave the founder personally liable for business obligations. For a studio that signs ToS / DPA with EU/IL clients (`publish-legal-bundle/research/01-commercial-lawyer.md § 3.7`), shielding is a baseline requirement, not a nice-to-have.
2. **IT Park eligibility.** The IT Park residency regime under Lege 77/2016 is offered to legal persons. PA / II forms cannot register as IT Park residents — that alone forces SRL even before liability is considered.
3. **Counterparty fitness.** EU enterprise clients, Romanian agencies, and the Israeli market expect a *limited-liability legal person* on the other side of a signed ToS / DPA. PA / II surface as "freelancer with a tax ID" and degrade the studio's positioning per `openspec/current/positioning.md`.
4. **Multi-asociat optionality.** Lege 229/2023 (amending Lege 135/2007) removed the 50-founder cap and merged the founding act with the statute into a single document. The SRL form now scales from single-founder to any future co-founder / investor structure without re-incorporating. The "Multi-founder / external investor structures" out-of-scope item in `proposal.md` is preserved precisely because the SRL form already accommodates it.

**Alternatives considered.**

- **II (Întreprindere Individuală).** Simpler registration, no statutory minimum capital, but personal liability and IT Park ineligibility — rejected on liability and tax-regime grounds.
- **PA (Persoană Autorizată).** Lower friction for solo-founder phase, but same liability and IT Park-eligibility problems plus weaker counterparty optics — rejected.
- **Foreign entity (e.g. UK Ltd, EE OÜ, RO SRL).** Each requires the founder to relocate the tax-residency story, opens reverse-charge / permanent-establishment complexity in Moldova, and forfeits the IT Park 7% regime — rejected as a strict downgrade for a Moldova-resident founder.

**Implementation contract.**

- `_methodology/studio-entity-baseline.md § 1 Operating entity` MUST state: form = SRL; IDNO = `<assigned at Phase 2>`; registered office = `<assigned at Phase 2>`; sole founder + administrator = Pavel Rapoport (current state); founding-act type = combined per Lege 229/2023.
- `_legal/vendors/finexpert.md` (owned by `establish-studio-legal-baseline`) MUST reflect FinExpert as the registration counterparty for filing with Agenția Servicii Publice.

---

## D-SEB-2 — IT Park residency adopted

**Decision.** Apply for, and operate under, Moldova IT Park residency. Tax regime = single 7% tax per Codul fiscal art. 367, replacing income tax, payroll, social, medical, road, real-estate, and local taxes (Lege 77/2016 art. 15).

**Rationale.**

1. **Stacked-tax replacement.** Under the standard regime, a salary-paying SRL pays 12% corporate income tax + ~24% social contributions + 9% medical contribution + payroll on the salary side. IT Park's single 7% applies to gross revenue (not profit), with a statutory minimum (see § Minimum-tax floor below). Even at modest revenue, the all-in burden of the IT Park regime is materially lower than the standard regime so long as headcount stays small and revenue stays above the floor.
2. **Compliance compression.** Replacing seven separate tax flows with one monthly IU17 return collapses the studio's compliance surface. For a studio whose Engineering and Finance attention are scarce relative to Engagement, this matters.
3. **Counterparty signalling.** IT Park residency is recognised in MD/RO/IL/EU procurement contexts as a non-trivial regulatory bar — it requires a real CAEM-coded activity profile and ≥70% qualifying revenue. For positioning purposes (`openspec/current/positioning.md`) it signals operating substance.
4. **Long-tenor stability.** Lege 77/2016's validity was extended in 2024 from 10 years (to 2028) to 20 years (to 2038). The regime is therefore stable through the studio's planning horizon.

**The 70% binding scope.** Lege 77/2016 art. 8 enumerates a closed list of CAEM codes. The studio's principal CAEM code (D-SEB-3) MUST be drawn from that list, and ≥70% of annual revenue MUST originate from activities mapped to codes on that list. This binds the studio's saleable scope: training, consulting, SaaS, hosting, and post-production all map to specific allowed codes (62.02, 63.11, 58.29, 59.12 etc.), but unrelated revenue (e.g. physical-goods resale, leasing of non-IT equipment) erodes the 70% margin and is therefore disallowed without prior modelling.

**Minimum-tax floor.** Codul fiscal art. 367 § 7 imposes a minimum that overrides the 7%-of-revenue computation: monthly tax ≥ 30% × forecasted average wage × number of employees. For 2025 the forecasted average wage was set at ~16 100 lei/month, putting the floor at ~4 830 lei/employee/month (~270 EUR at current rates). This floor is paid even at zero revenue. It is the single most important fact for the engagement-economics model in `_methodology/rapoport-studio-engagement.md § Pricing floor (pending D-POS-PRICE)` and for cohort modelling in `_methodology/specialist-network.md`.

**Alternatives considered.**

- **Standard regime (12% income + payroll + VAT 20%).** No 70% scope binding, no minimum-tax floor, full deductibility of expenses. Net-better only at headcounts and revenue mixes where the single-tax floor crosses over with the income+payroll path — see `Q-SEB-1` for the crossover point. Today's headcount = 1; standard regime is strictly worse at this scale.
- **Non-resident IT Park structure (parent abroad, MD branch).** Possible but adds cross-border substance, transfer-pricing exposure, and forfeits the simplification benefit. Out of scope for a founder-resident-in-MD studio.

**Implementation contract.**

- `_methodology/studio-entity-baseline.md § 2 IT Park residency` MUST record: residency contract number, effective date, principal CAEM code, secondary CAEM set, and a one-paragraph statement of the 70% scope binding with explicit examples of in-scope vs out-of-scope revenue.
- `_methodology/studio-entity-baseline.md § 3 Tax regime` MUST state the 7% rate, the minimum-tax formula in symbols, the current-year numerical floor, and the list of taxes replaced (per Lege 77/2016 art. 15). The numerical floor MUST be updated when the forecasted average wage for the calendar year is published by MMSPS / SFS.

---

## D-SEB-3 — Principal CAEM code (deferred to Phase 3)

**Decision.** Pending. The principal CAEM-2 code will be selected from the closed list in Lege 77/2016 art. 8 (catalogued in `research/01-moldova-laws-and-sources.md § 2`) based on the studio's dominant revenue source at the time of IT Park application. Decision is taken by the operator in coordination with Mila / FinExpert and ratified in Phase 3 of this change.

**Candidate slate and provisional ranking.**

| Rank | Code | Activity (RO/EN) | Why it might be principal |
|---|---|---|---|
| **1 (likely)** | **62.01** | Activități de realizare a soft-ului la comandă — Custom software development | Forge / Muse / Maestro engagements with clients are bespoke software work; this is the natural "primary activity" for a Specialist-Network-led studio that bills for prose-style spec authoring + executed implementations. |
| 2 | 62.02 | Activități de consultanță în tehnologia informației — IT consulting | Discovery / audit / methodology engagements where deliverable is advice, not built software. If the engagement portfolio tilts towards consulting-only, this becomes principal. |
| 3 | 58.29 | Activități de editare a altor produse software — Publishing of other software (SaaS, licences) | Becomes principal once a productized SaaS surface (e.g. `mitp.md`-like hosted offering) generates ≥35% of revenue. |
| 4 | 62.03 | Activități de gestionare a mijloacelor de calcul (facilități de tehnologia informației) — Computer-facilities management | Reserved option if a hosting-as-deliverable line ever emerges. |

The current expectation is **62.01 as principal**. The decision is *not* ratified at Phase 1 because:

1. The wording on the residency application binds the studio to the chosen code as its declared dominant activity for the 70% computation.
2. FinExpert's recommendation on the MITP filing language has not been captured.
3. The studio has not yet booked its first revenue under the SRL, so "dominant" is forward-looking.

**Alternatives ruled out at Phase 1.**

- **74.10 (specialised design — 3D, web design, motion).** In the IT Park allowed list but mis-frames the studio as a design house; rejected on positioning grounds (`openspec/current/positioning.md`).
- **85.59 (IT education / courses).** Allowed code, but the studio's `_methodology/specialist-network.md` is internal capability-building, not a market-facing course offering; rejected.
- **82.20 (call centres on modern IT).** Allowed code but unrelated to anything in the studio's roadmap; rejected.

**Implementation contract.**

- Phase 3 PR MUST update `_methodology/studio-entity-baseline.md § 2 IT Park residency` with the chosen principal code, the FinExpert/Mila rationale paragraph, and an explicit statement of which revenue lines map to that code.
- Phase 3 PR MUST ratify `D-SEB-3` in `decisions.md` with the selected code; the candidate-slate table above is preserved in the design history (not re-litigated) for revisitation if the studio's primary activity shifts later (e.g. SaaS pivot).
- If a code other than 62.01 is selected at Phase 3, the Phase 3 PR MUST also rewrite `proposal.md § Why § Services scope` to reflect the new dominant activity. The proposal explicitly anticipates 62.01 as the working assumption.

---

## D-SEB-4 — Secondary CAEM code starter set

**Decision.** Register the following CAEM-2 codes as secondary activities at the SRL registration step (irrespective of which code D-SEB-3 selects as principal):

- **62.01** — Custom software development
- **62.02** — IT consulting
- **62.09** — Other IT services (catch-all for activities not falling under 62.01–62.03)
- **58.29** — Publishing of other software (SaaS / licences)

This is the minimum set. Additional codes from the IT Park allowed list MAY be registered if the operator's near-term roadmap names a concrete activity that maps to them.

**Rationale.**

1. **Cost of registration vs cost of addition.** Adding a CAEM code at registration time is free of incremental fee under Lege 220/2007 art. 4 (the registration fee is per-act, not per-code). Adding a code later requires an amendment filing with ASP, which costs both time and a separate state fee. Pre-registering the obvious adjacencies is strictly dominant.
2. **70% rule is per-revenue, not per-code-count.** Registering many secondary codes does not erode the 70% guarantee — only revenue mix does. So there is no scope penalty for a broad secondary set.
3. **Why these four specifically.**
   - **62.01 / 62.02 / 62.09** together cover every IT services line the studio plausibly bills: bespoke build, advisory, hybrid. Whichever of 62.01 / 62.02 wins D-SEB-3 as principal, the other two MUST exist as secondary so revenue can be coded against them without amendment risk.
   - **58.29** is the cheap optionality for a future SaaS line. If the studio ever ships a productized offering (e.g. Forge-as-a-service, hosted Muse), revenue codes against 58.29 without an ASP filing.

**Codes deliberately *not* in the starter set, with closure trigger.**

| Code | Activity | Closure trigger to add |
|---|---|---|
| 58.21 | Game publishing | The studio takes on a games-related engagement or product. |
| 63.11 | Data processing / hosting | The studio offers managed-hosting as a billable deliverable (vs hosting-as-implementation-detail today). |
| 63.12 | Web portals | The studio runs an externally-facing portal as a product, not as marketing collateral. |
| 72.11 / 72.19 | Scientific R&D | The studio takes on a research-grant-funded engagement. |
| 74.10 | Specialised design | The studio formally markets design-only engagements (contradicts `positioning.md` today). |
| 59.12 | Post-production / VFX | The studio collaborates with a video / motion studio on a billable engagement. |
| 85.59 | IT education | The Specialist Network productizes its training as a public course. |
| 82.20 | Modern-IT call centres | Not anticipated. |

**Alternatives considered.**

- **"Register every allowed code at incorporation."** Tempting because of the no-marginal-fee argument, but generates downstream noise: each registered code creates an obligation in the annual statistical report (ISAPTI17) to report whether it generated revenue, with explanation required if zero. Keeping the secondary set tight to genuinely-likely activities is the cleaner ops position.
- **"Single principal code only; no secondaries."** Forces an ASP amendment the first time a billable hour falls outside the principal scope; ruled out as friction-positive.

**Implementation contract.**

- Phase 2 PR (registration cycle) MUST file the SRL with principal = `<D-SEB-3 outcome>` and secondaries = {62.01, 62.02, 62.09, 58.29} ∪ any operator-roadmap-justified additions.
- `_methodology/studio-entity-baseline.md § 2 IT Park residency` MUST list the full registered set and, for each code, one-sentence "what revenue codes against it" so future operators (or specialists) can route invoices without re-deriving the mapping.

---

## D-SEB-5 — Statutory share capital amount (deferred to Phase 3)

**Decision.** Pending. Lege 135/2007 art. 21 (as amended by Lege 229/2023) sets no statutory minimum for an SRL — the founder declares any amount. The concrete figure will be captured at Phase 3 from FinExpert's recommendation and the operator's preference.

**Considerations the Phase 3 ratification MUST address.**

1. **Signalling vs capital efficiency.** A symbolic share capital (e.g. 100 lei, 1 000 lei) is legally sufficient and minimises tied-up capital, but lands awkwardly on counterparty due diligence — EU enterprise procurement sometimes filters on share capital as a (weak) proxy for substance.
2. **Founder loan vs share capital.** Working capital injected by the founder as a loan is repayable without dividend tax; injected as paid-in capital becomes equity and exits via dividend (subject to applicable tax). Phase 3 MUST distinguish the two and state which mechanism funds month-zero operations.
3. **Future co-asociat dilution.** If the share capital is symbolic, admitting a co-asociat later requires raising the capital to a non-symbolic level *and* dividing it — two filings instead of one. Setting a "reasonable" capital at incorporation (e.g. 5 000–20 000 lei) leaves headroom for a single-filing later dilution.
4. **Reporting cost.** Higher share capital does not change the IT Park single-tax computation (which is gross-revenue-based) and does not materially change annual-report costs.

**Provisional working assumption** (for proposal-modelling purposes only; not ratified): 5 400 lei (approx. 300 EUR), divided into 5 400 părți sociale of 1 leu each. This is the value used in `establish-studio-legal-baseline` placeholder text and matches a common FinExpert recommendation for solo-founder MD SRLs.

**Implementation contract.**

- Phase 3 PR MUST ratify `D-SEB-5` in `decisions.md` with the chosen amount, the par value per part socială, and a single-sentence rationale that names which of the four considerations above drove the choice.
- `_methodology/studio-entity-baseline.md § 1 Operating entity` MUST record the ratified amount.

---

## Open questions (Q-SEB-N)

The three open questions enumerated in `proposal.md § Modified Capabilities § open-questions.md` are restated here with their *closure trigger* and the *artifact* that closes them, so the Phase 3 / Phase 4 PRs know exactly what to write:

### Q-SEB-1 — Single-tax floor crossover

**Question.** At what employee count N does the IT Park single-tax floor (`30% × forecasted_avg_wage × N`) cross over with the standard regime (`12% × profit + ~33% × payroll`), making IT Park net-negative?

**Why it matters.** Determines whether scaling the studio past a threshold headcount forces a residency exit. Today N=1 so the question is theoretical, but the Specialist Network's cohort-1 model in `_methodology/specialist-network.md` projects multi-specialist activation.

**Closure trigger.** Explicit operator decision based on a real cohort-economics model (revenue per specialist × cohort size × utilization). Not closeable at Phase 1 — no real numbers.

**Closes by.** A follow-up change `model-it-park-crossover-economics` (not yet scaffolded), or as an appended decision in `_methodology/studio-entity-baseline.md § 3 Tax regime`.

### Q-SEB-2 — VAT registration

**Question.** Does the studio need a separate VAT (TVA) registration? Moldova's general VAT threshold is 1.2M lei annual turnover (Codul fiscal). IT Park residents are exempt from VAT on services to MD residents, but the reverse-charge mechanism on imports of services (Anthropic, OpenAI, Supabase, Vercel, GitHub invoices) applies regardless.

**Why it matters.** Determines whether monthly TVA12 filings are required in addition to IU17, and whether cross-border vendor invoices need reverse-charge treatment in the bookkeeping flow that `_legal/vendors/*` cards reference.

**Closure trigger.** FinExpert advice + actual numbers from the first full quarter post-registration.

**Closes by.** Phase 4 PR amends `_methodology/studio-entity-baseline.md § 4 Reporting calendar` with TVA12 status (filed monthly / not filed / reverse-charge-only).

### Q-SEB-3 — Annual audit logistics

**Question.** Cost, auditor selection, and timing for the mandatory annual audit (Lege 77/2016 art. 8 § 5: IT Park residents file an audited annual financial report by 30 April).

**Why it matters.** Audit is a hard deadline with a real cash cost (typical range: 15 000–40 000 lei for a small SRL). The studio's first audit is roughly 14 months after registration; preparing for it earlier reduces the risk of a 30-April scramble.

**Closure trigger.** First full audit cycle completed.

**Closes by.** Phase 4 PR amends `_methodology/studio-entity-baseline.md § 4 Reporting calendar` with the engaged auditor, audit timing window, and observed cost.

---

## Cross-references to other capabilities

The baseline is load-bearing for several downstream capabilities. The cross-references below name the *receiving* file and the *contract* this change supplies it.

### Engagement charter — pricing floor

- **File:** [`openspec/_methodology/rapoport-studio-engagement.md § Pricing floor (pending D-POS-PRICE)`](../../_methodology/rapoport-studio-engagement.md) (line 578).
- **Contract this change supplies.** The numerical monthly cost floor (~270 EUR/headcount in 2025), expressed as a formula (`30% × forecasted_avg_wage_year × N_employees`) so the receiving file can re-evaluate when the forecasted average wage updates.
- **Where the receiving file consumes it.** D-POS-PRICE's resolution must take this floor as a hard lower bound on the engagement-fee model. The receiving file does not duplicate the formula — it cites `studio-entity-baseline.md § 3 Tax regime`.

### Specialist Network — cohort-1 economics

- **File:** [`openspec/_methodology/specialist-network.md`](../../_methodology/specialist-network.md).
- **Contract this change supplies.** The per-headcount monthly tax floor and the headcount-multiplier shape — i.e. the floor scales linearly with N, so cohort sizing decisions cannot ignore it. Q-SEB-1 is the crossover question the cohort model will eventually have to answer.
- **Where the receiving file consumes it.** The cohort-economics section (currently sketched, not enumerated) cites `studio-entity-baseline.md § 3 Tax regime` and uses Q-SEB-1 as a forward-reference until that question closes.

### Legal counterparty identification — placeholders in ToS / Privacy / DPA

- **File:** [`openspec/changes/publish-legal-bundle/research/01-commercial-lawyer.md § 4.1`](../publish-legal-bundle/research/01-commercial-lawyer.md).
- **Contract this change supplies.** Phase 2 produces the concrete IDNO and registered office. Phase 3 promotes both into `_methodology/studio-entity-baseline.md`, at which point `publish-legal-bundle` can close its `[IDNO to be inserted]` and `[address to be inserted]` placeholders.
- **Where the receiving file consumes it.** Section 4.1 of the commercial-lawyer report carries the placeholders today. Closure is a coordinated PR at `publish-legal-bundle` time — not in this change.

### Vendor cards and AI policy

- **File:** [`openspec/archive/2026-05-13-establish-studio-legal-baseline/`](../../archive/2026-05-13-establish-studio-legal-baseline/) (archived 2026-05-13) and any follow-up change that re-opens `_legal/vendors/` for additions.
- **Contract this change supplies.** Nothing structural — `establish-studio-legal-baseline` owns `_legal/vendors/*` and `_legal/policies/ai-usage-policy.md`. This change supplies one specific vendor: the operator commits to filing `_legal/vendors/finexpert.md` as part of the Phase 2 registration cycle, since FinExpert becomes the studio's registration / accounting counterparty.
- **Where the receiving file consumes it.** `_legal/vendors/finexpert.md` is authored under the existing `establish-studio-legal-baseline` vendor-card template (see `archive/2026-05-13-.../design.md § Шаблон карточки вендора`).

### Data residency — Moldova not EU-adequate

- **File:** [`openspec/archive/2026-05-28-inference-data-residency-routing-decision/`](../inference-data-residency-routing-decision/).
- **Contract this change supplies.** The plain-text jurisdictional fact: Moldova has no EU adequacy decision under GDPR art. 45. Law 195/2024 (Moldovan data-protection law harmonized with GDPR) is enacted but effective only 23 Aug 2026; until that date Law 133/2011 applies. EU → MD transfers therefore require SCCs or another art. 46 transfer mechanism. This fact is authored once in `studio-entity-baseline.md § 5 Cross-references § Data residency` and cited from the residency-routing change.
- **Where the receiving file consumes it.** `inference-data-residency-routing-decision` does not duplicate the adequacy analysis; it cites `studio-entity-baseline.md` and proceeds to the routing rules.

---

## What this design does *not* cover

To keep the design contract sharp, the following are explicitly *not* design concerns and live elsewhere:

1. **Registration procedure.** Document set for ASP, application packet for MITP, signature mechanics — operator work with FinExpert, captured outside the repo. `tasks.md § Phase 2` lists the operator-side checklist; this design does not duplicate it.
2. **Concrete numerical values.** IDNO, registered address, residency contract number, share capital amount, principal CAEM code — all deferred to Phase 3 ratification.
3. **The text of `_methodology/studio-entity-baseline.md`.** Phase 3 deliverable; this design names the section structure and the contracts the doc must honour, but does not pre-write the prose.
4. **Banking, payment-processor, and treasury arrangements.** Out of scope — owned by a separate, not-yet-scaffolded change that will follow registration.
5. **Trademark / brand registration.** Out of scope — separate filing path with AGEPI; will be its own change.

---

## Status

Phase 1 design complete. Three of five decisions ratified (D-SEB-1, D-SEB-2, D-SEB-4). Two deferred to Phase 3 (D-SEB-3, D-SEB-5) with provisional working assumptions noted. Three open questions documented (Q-SEB-1 to Q-SEB-3) with explicit closure triggers.
