Professional pilot package
Offer version 1, 5 September 2026. This package defines a repeatable offer for review. A completed and signed SOW/DPA and verified deployment/data prerequisites are required before client-data onboarding.
Supported data and jurisdiction matrix
| Capability | Current implementation | Requirement before client use |
|---|
| Country / account context | One scope recorded in the pilot agreement | Agree jurisdiction and taxable/sheltered context; no approved tax calculation pack is claimed |
| Declared weights, costs, concentration | Frozen user-declared snapshot and reproducible arithmetic | Adviser reconciles source statements and missing TER |
| Adviser target scenario | Versioned target weights compared with declared weights | Adviser owns the assumptions; no return or tax forecast |
| Look-through / publisher data | Unavailable in the pilot snapshot | Verify product identifiers, current publisher holdings and commercial use rights |
| Tax / wrapper pack | Version marked unavailable | Approve a sourced jurisdiction/account pack and its effective date |
| Branding, PDF, JSON, approval record | Firm name, printable approved report, versioned export and actor/time history | Test tenant access, reviewer roles and the final client copy |
Public methodology and source boundaries. Reusing a data file does not grant redistribution rights. The starting commercial offer excludes unlicensed data.
Standard statement of work
The parties complete a signed order identifying the customer and supplier legal entities, authorised signatories, billing addresses, applicable tax treatment, effective date and agreed governing law. The order incorporates this offer version and the completed DPA annexes.
- Package: €1,500 setup + €299/month for 25 total pilot reports, or €3,000 setup + €599/month for 50. One jurisdiction/account context, firm-name branding, onboarding and one named review workflow. Setup is paid before onboarding; monthly charges start on the agreed service date. The signed order names invoice due dates and cancellation notice.
- Acceptance: both parties approve a fictional sample, reconcile declared calculations, test organisation isolation, and demonstrate draft → review → approve → PDF/JSON. Unavailable analyses remain visible. A material failure against these checks must be remedied before client-data acceptance.
- Change control: additional reports, custom ingestion, embedded/API integrations or jurisdictions require a written price and delivery scope before work starts. No free custom implementation or open-ended report allowance.
- Responsibilities: the firm verifies lawful client-data use, checks inputs, sets models and approves interpretation. The supplier operates only the agreed illustration and review service. Neither the software nor its sample authorises custody, execution or a suitability decision.
- Timeline and exit: proposed four-week sequence begins after signed prerequisites. The order states support hours, acceptance dates, payment/refund treatment for unmet scope, termination, export/deletion and any retained billing records. Do not assume a production SLA or certification.
- Signatures: the final order includes the parties’ completed commercial/legal details and signatures. This public document is a drafting basis, not an executed agreement.
DPA path
For the firm's client-report processing, define the firm’s controller role and Metruvo’s instructed processor role in the signed processing schedule. Use the European Commission controller/processor standard clauses as the contract basis. These Article 28 clauses do not themselves replace a required international-transfer mechanism. The EDPB role guidance explains why actual processing responsibilities must match the agreement.
| Annex | Complete before signing |
|---|
| Parties and contacts | Legal entities, roles, addresses, privacy contacts and authorised signatures. |
| Processing description | Purpose: adviser-reviewed portfolio illustrations; subjects: firm users and clients; categories: contact/account identity, holdings, declared values and reviewer notes. Prohibit tax identifiers and special-category data unless separately agreed. Define duration and deletion/export instructions. |
| Measures | Verified bearer authentication, organisation policies, reviewer permissions, TLS deployment, data/backups encryption evidence, access logging, incident assistance, rights-request handling, restore testing and review cadence. |
| Subprocessors and transfers | List contracted legal providers, purposes, regions, transfer safeguards and authorisation/change-notice process. Verify actual tenant configuration and contracts. |
The completed agreement must cover documented instructions, confidentiality, security, subprocessors, assistance with rights and incidents, return/deletion and compliance evidence. Send the completed schedule and legal questions to enterprise@mrfreire.net for review before client onboarding.
Security, privacy and processors
| Component | Data / boundary | Deployment evidence required |
|---|
| Application hosting (Vercel configuration) | HTTPS requests, portfolio/report computation and operational logs | Project region, log/body policy, access restrictions and provider agreement |
| Supabase / PostgreSQL | Auth identity, tenant records, frozen reports and approval history | Actual database region, backups, least-privilege role and RLS tests |
| Stripe | Billing identity, payments and consented experiment metadata | Account contract, enabled product configuration and retention |
| Sentry, when configured | Error diagnostics; excluded from pilot report payloads | Actual scrubber behavior, DSN destination and retention |
| Market data | Reference inputs only where licensed | Provider rights, source date and approved jurisdiction pack |
This is a component inventory from the repository, not a claim of verified live processor contracts, SOC 2, enterprise SSO or a penetration test. No client portfolio should enter the pilot until the configuration and signed subprocessor schedule are verified.
Qualification requests retain firm/contact information for 90 days unless an agreed customer relationship creates a separate retention basis. Optional lead analytics attribution expires after 30 days and is cleared on analytics withdrawal. Operators run the database purge daily; application mutations also perform analytics cleanup. Contact enterprise@mrfreire.net for lead erasure. Signed-in account deletion includes authored professional revisions and review actions; firm agreement records can remain for other members.
Data flow
Client browser
│ HTTPS + verified bearer (professional features)
▼
Application API ── tenant transaction ── PostgreSQL
│ ├─ frozen portfolio snapshot
│ ├─ versioned adviser target/commentary
│ └─ reviewer / approval actor and time
└─ approved view ── browser PDF / JSON export
Qualification form ── contact consent ── private lead table ── operator discovery record
Optional analytics ── separate opt-in ── strict event schema ── 30-day session table
Billing ── Stripe signature-verified webhook ── purchase access
API and export contract
Authenticated POST /api/pilot creates an immutable draft revision. Supply a saved report owned by the submitting account for its first revision. The server derives tenant, author, original snapshot and source hash from verified context; it does not trust a submitted approval identity.
{
"report_id": "ec14e81d-c488-482d-b882-002aa3cdc217",
"previous_revision_id": null,
"commentary": "Declared cost coverage is incomplete; position C has no supplied TER.",
"model_version": "adviser-model-2",
"targets": [{ "ticker": "A", "weight": 0.5 },
{ "ticker": "B", "weight": 0.3 },
{ "ticker": "C", "weight": 0.2 }]
}
201 { "id": "ca13879c-5e6d-4c1b-9913-123c6d1b14b3" }The UUIDs above are fictional schema examples. PATCH /api/pilot accepts revision_id, action (“review” then “approve”) and limitations_acknowledged: true. Only current organisation owners/admins can approve. Editing creates a new draft; it does not inherit approval.
Export schema v1 contains firm, jurisdiction, report/revision IDs, model version, adviser commentary/targets, the frozen snapshot with calculation/data/tax versions and unavailable fields, snapshot hash, author/time and review/approval actors/timestamps. Approved PDF and JSON are available in the review workspace. These exports contain client financial information and must follow the firm's delivery policy.
Implementation and validation record
- Qualify the firm using the public form and agree the discovery time.
- Sign scope and DPA; verify processor regions, source licences and input rights.
- Configure the existing organisation’s pilot agreement, scope, expiry and allowance through the trusted database operations process. No public endpoint grants a pilot agreement.
- Apply migrations and test role/tenant access; run the fictional report from draft through approved export.
- Record the demo, objections, time spent and scoped acceptance criteria.
- Invoice the signed package through the agreed billing process; do not label a lead or demo as a paid pilot.
Validation target: 100 selected firms, 15–20 discovery calls, 8–10 demos and 3 paid pilots. Stop and review after 20 qualified losses if three paid pilots do not close. Record identical offer version, quoted package, objections, scope changes, measured review time and report use. Obtain client permission before publishing a case study. No prospect outreach, paid pilot or case study is claimed by this package.
Named contact: enterprise@mrfreire.net.