The AI StudioSample engagement · what we build
Sample · Client details anonymized
The AI StudioSample engagement · what we build
Sample · Client details anonymized
The build specification for the AI Studio Platform: what we deliver, how it is architected, in what order we build it, how we prove the answers are correct, and how you know it is done. Written so a technical reader on your side can verify exactly what they are getting.
The AI Studio Platform, including the eleven builds that cover 14 of the 57 evaluation opportunities.
Day 60: the Platform delivered and accepted, with all of your roughly 160 employees able to sign in. Day 120: all eleven builds delivered and accepted, training done, handover complete.
System by system, from the first connector onward - Section 09. That section is the reason this document is trusted.
Everything that follows is the detail behind it.
The proposal tells you what the platform does. This document tells you what it is made of and when each piece arrives.
It is the build specification for your AI Studio: what we deliver, how it is architected, in what order we build it, how we prove the answers are correct, and how you know it is done. It is a companion to two documents you already hold: the AI Opportunity Evaluation and the AI Studio Proposal, including its Connecting-the-Dots crosswalk of all 57 opportunities.
Not a description - a test. Something a person can watch happen and then say yes or no about.
So the delivery schedule and the money schedule cannot drift apart.
The boundary is the ceiling and the floor. We deliver at least it, and we never quietly widen it.
Anything absent from the in-scope list is out - that sentence is what makes the list worth writing.
Reachable two ways - a plain-English Console for everyone, and a full Builder Workspace for power users - over a shared connector layer that safely brokers your real systems, wrapped in an audit, secrets, provisioning, and cost-control spine.
A dedicated Linux server (current LTS), hardened to production standard - key-only access, firewall, intrusion protection, automatic security updates, full auditing - provisioned in your name. Sized from a capacity audit we run in the first two weeks against your real user count rather than from a generic spec.
The Studio has its own login. Your people sign in with their own Studio accounts, managed inside the platform. We chose this over tying into a single corporate sign-on because your divisions run on different systems; a self-contained login keeps the platform working no matter what changes on your side. Their group (set by you) decides what each person can see and do.
Each user runs in their own sealed workspace with its own memory and its own injected keys. Work, data, and spend are isolated per person. Keys are never stored in the system image and never written to logs - injected at runtime, removed when the session ends.
The Console (plain-English chat where anyone can ask questions and build their own automations) and the Builder Workspace (a real development environment with full build tools, a web terminal, and direct server access for power users). Both come off the one login. Group decides which a person gets.
Each of your systems gets its own dedicated, secure broker between the AI and the data. Read-only by default. Sensitive fields walled off. Every query capped and time-limited, and a hard allowlist means nothing destructive can run. Detailed in Section 05.
Each user, and the company as a whole, gets a persistent, durable memory. The platform learns your business and stops asking to be re-taught. Loading that memory is the first step of every single interaction.
A protected vault for per-user keys, a complete audit log of every request, a live cost dashboard by user, and spend caps you set per group. This is the CFO’s instrument panel.
The platform splits its AI workload into two groups, because the two kinds of work have different cost shapes, and it runs across every major model provider so each job uses the right tool.
Your serious builders do heavy, hands-on work in the Builder Workspace. Each gets their own named model accounts (roughly $200/month for the primary reasoning model, plus a smaller secondary account), so they build essentially without limit at a fixed cost and always have the newest models. Around five to start, a couple per division. They log in with their own named credentials - which is also what cleanly separates a power user from everyone else.
Your other roughly 155 employees never hold a personal AI subscription. They sign in to the Studio and the platform runs the AI for them, billed through your central accounts and metered to each person. It scales per request, meters cleanly, and feeds the cost dashboard, the audit log, and the caps. It is the only setup that gives you central visibility and control - which is what your company-wide AI policy needs.
| Purpose | Routes to |
|---|---|
| Reasoning, analysis, writing, agents | The strongest reasoning model - the backbone |
| Images, creative, design assets | Image models from the major providers |
| Real-time and web-flavored work | The model with live web access |
| Long-context and high-volume work | Fast, low-cost long-context models |
Employees are sorted into groups, each with its own spend cap and model access. You start people conservative and move the heavier users up as real usage shows who needs more, so you stay inside a controlled range. The exact group structure is set with you during setup.
Your AI usage runs roughly $6,000 to $9,000 per month, billed directly to you. Where you land in that range is your decision. With Studio Care at $3,000 to $4,500 a month and the server at approximately $300/month, the typical all-in is about $11,000 per month, fully under your control. Section 15.
Rather than connect to a fixed short list, the platform is built to reach anything connectable. During the evaluation and build we map every database, site, and third-party tool worth connecting, and we connect everything we can. Each system gets its own dedicated connector, read-only by default, with any write path explicit, narrowly scoped, and audited.
| System | What it holds |
|---|---|
| ERP (NetSuite) | Finance: general ledger, payables, actuals vs budget |
| Spend platform (Ramp) | Spend and accounts payable, including the invoice flow the categorization core codes |
| Primary ticketing vendor (API + analytics platform) | Ticket data and the vendor analytics platform |
| Cloud SQL warehouse (Microsoft SQL on Azure) | The two-year ticketing record your team maintains - 60M+ rows |
| Second ticketing system (AXS) | In use on some shows |
| Daily-count platform (Real Count Pro) | Daily ticket counts and audits across every show |
| CRM feed (Hive) | Customer and marketing data pulled from the ticketing vendor |
| Operations database (Airtable) | Offers, historicals, venue rebates, ticket build info |
| Secondary-market reporting (Elevate) | Resale sales reporting |
| Documents (Google Drive / Microsoft 365) | Show files, documents, and shared storage |
Connecting a system does not mean everyone can see it. Access is scoped per team and per group, based on your decisions: a division sees its own data, sensitive systems are restricted, and you decide who can ask what. The granular, fine-grained scoping inside a single system is Full Studio work.
Least privilege - dedicated service accounts, read-only by default. A hard wall around sensitive data. Deterministic guardrails - query caps, timeouts, and an allowlist that makes destructive operations impossible on read connectors. Schema caching - the system learns your data structures once.
That two-year record is large and, as your team has told us, it is not indexed and has no dedicated DBA. We will not add indexes to a production database you depend on without your explicit permission. The connection design - a read replica, a copy on the platform side, or a small set of indexes agreed with you - is decided jointly inside that build rather than assumed by us.
Each person’s group is set by you and decides which surfaces they get (Console or Builder Workspace) and which systems they can reach.
A division sees its own data, not the whole company’s, unless you grant it.
A complete, queryable audit trail of who asked what, against which system, when.
Per-group caps, a live cost dashboard by user, and the ability to dial any user up or down. No single person can run up a large bill.
All keys held in a protected vault on your server, injected at runtime, never baked into images, never written to logs.
Key-only access, firewall, intrusion protection, automatic security updates, full auditing - production standard from day one.
Everything below is built, hardened, documented, and handed over under the Platform. Anything not on this list is what your team builds inside the platform, or what we build under a later engagement.
Each one has a defined thing that is delivered and a defined test that says it is done. Two checkpoints in between prove pace without creating a contractual event.
Day 60 splits the engagement into two things you can judge separately. The platform is a product - it either works or it does not. The builds are a program - they land one at a time. Bundling both into a single end-of-engagement acceptance is how delivery disputes are made. And the builds are worth more when they land on a platform people already use: a build delivered into an empty platform gets evaluated as a demo; the same build delivered into a platform the team has lived in for two months gets evaluated as a tool.
This sample states the schedule as day counts from signature because a sample has no signature date. The delivered document states two calendar dates anchored to the actual build start and confirms them in writing on the day of execution: if execution lands later, both milestone dates move by the same number of days.
This is the question that matters most, and it deserves its own section. Building the platform is our risk to carry. Proving that a plain-English answer matches what is actually in the ERP, or the spend platform, or the ticketing record, is something neither side can do alone. We are close to the software and you are close to the data - so accuracy is verified together, in a defined loop, from the first connector onward.
You designate one person per system at kickoff, so nothing waits on “someone” to look at it. The ask is small and specific: roughly two hours per system, in the week after that system goes live.
No connector counts as delivered at Milestone 1 unless its owner has verified it and signed off. No build counts as delivered at Milestone 2 unless the answers it produces have been checked against the source the same way. Acceptance is not us saying it works. It is your own people confirming that the numbers match.
If the platform returns something incorrect, fixing it is our job - never a change order. What we need from you is the one thing we genuinely cannot supply: a person who knows what the right answer looks like.
Accepted when all six are demonstrated on your instance, with your data, with your people present:
Accepted when all four are true:
Training is included and it is not metered against a stopwatch. What we care about is that your people are genuinely self-sufficient by the end, so the shape is set with you rather than fixed in advance here.
From around Day 30. Small, hands-on, and deliberately early, while the platform can still be changed by what your people say about it. These sessions are as much us learning your workflows as your people learning the platform.
From Day 60. As each division comes on, its people get walked through the Console, what they can ask, and what they can build. Rolled out group by group rather than in one large session.
Through the rest of the engagement. Group sessions on a regular cadence plus one-on-one time per power user, aimed at the point where your builders are creating agents without us.
We are not asking you to fix a training calendar at signature and we are not going to hold you to one. The schedule is set with you as the roster and the rollout order firm up.
The platform, the code, the agents, and everything your team builds - from day one.
Your IT can move the whole platform to any host, anytime. Portability is a build requirement, not an afterthought, which is what lets us honestly say you are never locked in.
At handover we strip every credential of ours and any of our data off the server. If you keep us on for Studio Care, we retain exactly one clean management account for support - and nothing else.
Any parallel engagement - for example a paid-advertising platform - is contracted separately and is not part of this build or price. It can connect to the platform through a read-only data feed so that data and your business data answer questions together.
The platform is read-only by default, by design, to protect your data. Building agents that write into a high-value live database is next-level work: a deliberate, scoped build with a backup and redundancy strategy, so a bad write can never cost you real data. A later engagement, never a default.
What your team builds inside the platform. We are available to build them with you under the Full Studio or a later engagement.
The subsidiary settlement automation is scoped by the PCI review, as the evaluation specifies. The income-recognition build generates a file for review and posts nothing on its own. The venue-expense build is current-data scope; the legacy backfill is a scoped add. The post-event survey build is the survey slice; the full advancing repository is a later engagement.
Studio Care at $3,000 to $4,500 a month, set at signature against the tier you choose, keeps the system tuned and current: monitoring and uptime checks, auditing it, reviewing spend against caps, adding connectors, fixing what breaks, and swapping in better and cheaper models as they ship so your platform keeps getting sharper instead of frozen in time. Non-critical issues are answered by the next business day. Critical issues - the platform is down, a breach is suspected, or spend is running away - are answered same day on a best-effort basis.
Day-to-day administration (adding users, adjusting caps, granting connector access) sits with your own administrator inside the Admin Console, which is deliberate: you should not need us to run your platform.
| Ongoing cost | Per month | Note |
|---|---|---|
| AI usage | $6,000–9,000 | Runs the whole company on the best model for each job; you set the caps |
| Studio Care | $3,000–4,500 | Section 14 |
| Server | ≈ $300 | Sized for ~140 metered users on the connector layer plus your power users on heavy models |
| Typical all-in | ≈ $11,000 | Every dollar visible to you by user, by group, and by day |
All three billed directly to you, in your name, with no markup. Commercial terms and the payment schedule are in the Proposal and Exhibit B below.
The evaluation’s recommended starting set, at no change in price. They cover 14 of the 57 opportunities, including the entire top five, the full quick-win cluster, and all three deployments of the categorization core.
The included builds are delivered to your power-user group first: the people in finance, ticketing, and booking who own the workflow each build serves. That is deliberate. It puts each build in front of the person who can tell whether it is right, under the verification loop in Section 09, before it is opened wider. Extending any build to a broader group is a configuration change you can make yourself once its owner is satisfied, not another build.
| # | Build | From the evaluation | Accepted when | Boundary |
|---|---|---|---|---|
| 01 | Natural-language finance reporting | F3 | Named power users ask plain-English questions of connected finance data and get correct answers, read-only enforced, every query in the audit trail, and at least one recurring report previously built by hand is reproduced. | Read-only by design. |
| 02 | The categorization core, deployed three ways | F1 · WA7 · Mk5 | All three deployments are running with human confirm or override in front of them, and accuracy is measured against a human-coded sample before each rollout. Deployment 1: pre-coded invoices in front of the AP workflow. Deployment 2: ad-invoice coding. Deployment 3: venue-expense mapping, alongside build 5. | Never autonomous. Nothing posts on its own. |
| 03 | Subsidiary settlement automation | iEO1 | The Monday settlement cycle automated to the scope the PCI review permits, running and observed for at least one cycle. | Scoped with the PCI review, as the evaluation specifies. |
| 04 | SQL warehouse connector | T3 | Read-only connection live, probe green, the two-year record queryable in plain English at usable latency, sensitive fields walled off, every query logged, revocable by you at any time, and verified against the source under Section 09. | Access provided by you. Connection design agreed jointly per Section 05. |
| 05 | Venue-expense auto-populate and offer flagging | B1 · B6 | New offers auto-populate venue expenses from current data, absorbing the 400-to-550 offers-per-year goal without proportional hiring. Material deviations on rent, fees, and scaling are flagged for human review; the system flags, it never blocks. | Current-data scope; the legacy pre-2024 backfill is a scoped add. |
| 06 | ZBA daily transfer automation | F12 | Daily zero-balance transfers computed and executed or filed per your control policy, deterministic, logged. | Deterministic. |
| 07 | New-vendor completeness check | F13 | New vendor records checked for completeness at entry, incomplete records flagged before they reach payment. | Deterministic. |
| 08 | Income-recognition file generation | F6 | The income-recognition and accrual file is generated for human review and posting. No write path into the accounting system. | File generation for review; nothing posts on its own, per your governance principles. |
| 09 | End-of-tour marketing rollup | Mk6 | Post-tour reconciliation rollup produced automatically across roughly 1,000 shows per year. | The zero-baseline learning loop. It does not replace campaign reporting. |
| 10 | Offer-sheet templating | B3 | Offer sheets generated from templates with deal terms populated. | The lowest-barrier booking win. |
| 11 | Post-event survey automation | EO1 slice | Post-event surveys issued, results collected and summarized. | The survey slice only. The full advancing repository is a later engagement. |
Both structures were offered, and both run against the same milestones and the same acceptance criteria.
| Released by | Option A · 50/50 | Option B · on proof |
|---|---|---|
| The agreement is executed | Half | First quarter |
| First users live on your own instance, and the designated owner has verified the first connector against its source system - Day 30 | - | Second quarter |
| Milestone 1 accepted: the Platform delivered and accepted against all six criteria - Day 60 | Half | Third quarter |
| Milestone 2 accepted: the engagement complete and accepted against all four criteria - Day 120 | - | Final quarter |
Option B carries a modest premium and buys you something real for it: the money moves only when delivery is proven, four separate times, and the final installment is not released until every build is accepted. Option A settles the engagement on two events, most of it early, at the lower total. One is priced risk transfer, the other is a discount for paying ahead - and you pick.
It is deliberately unattached. A checkpoint that releases money stops being a checkpoint and becomes a negotiation.