The Grid — Asset Valuation & USP Licensing Proposal Establishing fair value for a personally-built AI platform, and a licensing structure that gives USP the capability it needs on terms that are fair to all three owners.

01 What the Grid actually is

Before valuing it, it's worth being precise about the thing — because "an AI project" and "a governed multi-agent operations platform with productized verticals" are two very different assets.

02 What went into it — the cost basis

Valuation isn't one number from one factor. It's the convergence of several independent lenses. Start with what's already spent — the floor no counterparty can argue away.

A. Direct out-of-pocket cash — Henry's personal spend

This $28K–45K is a useful floor for the conversation: documented, personal capital already spent — entirely separate from the platform's actual value. Any fair arrangement should at least recognize this direct outlay before accounting for what the Grid is worth as a working system.

B. Cost to recreate (replacement value)

The more relevant number for a buyer or licensee is: what would it cost USP to build this instead of using GridFleet's platform? Estimating the engineering effort to rebuild the platform from scratch with a competent hired team:

At a loaded senior full-stack/AI engineer cost of ~$12K–18K/month, that's $250K–450K to rebuild in-house. An agency or consultancy quoting this at $150–250/hr would land materially higher — comfortably $500K–900K. Replacement cost is the single strongest lens because it answers the buyer's real alternative.

C. Founder labor — Henry's own time

Distinct from the AI agents' output: Henry's own directed hours. Roughly 4 months at 30–50 hrs/week of design, direction, and debugging is ~500–850 hours. Even at a modest $75–125/hr operator rate that's $40K–100K of founder time. It overlaps conceptually with replacement cost, so it doesn't stack onto the headline — but it's the answer to "why should this be cheap?" It was not cheap to build.

D. Hardware — the HIVE rig (separately reimbursable)

Henry personally purchased the GPUs, PSUs, and connectors for the HIVE local-inference cluster. That is not part of the software valuation — it's a distinct, tangible asset that can be sold to USP at cost. Covered in full in §07.

03 Whole-Grid valuation — three lenses

No single method is right for a pre-revenue but fully-built, proprietary platform. Triangulate.

A helpful way to frame it for everyone: the real question isn't "what's a slice of the Grid worth," it's "what would it cost USP to have this capability at all" — and the answer is a quarter-million dollars and up to build from scratch, versus a fair license to use what already exists. The license is genuinely the better deal for USP, which is a large part of why it's the recommendation.

04 GAOS / HARMONIC — valued on its own

The governance system is worth valuing on its own — it is the most differentiated IP in the whole platform.

For USP specifically, GAOS/HARMONIC is the reason client-facing agent work is defensible — it's what lets USP sell "agents that can't go rogue on a client's data." Priced into the license as a premium capability, not a throw-in.

05 Every module, individually valued

USP floated "bringing in only a portion." So here is every module priced on its own — what's actually inside it (each one is more intensive than its name suggests), its maturity, and a standalone rebuild value. The point: no meaningful slice of the Grid is worth a token amount.

Two things this table proves. One: the raw sum-of-parts ($340K–650K) actually exceeds the blended whole-platform figure — because the modules share governance, credentials, and multi-agent check-and-balance logic that would each have to be partially rebuilt to stand alone. Two — and this is the practical crux: most modules don't cleanly detach. GAOS/HARMONIC and the multi-agent runtime are load-bearing under everything. The one module that does detach cleanly, is client-ready, and is what USP is after is the Voice Communication System — which is why it makes sense as the defined "USP Grid v1" (§08), rather than an arbitrary carve-out of the entangled core.

Every agent, individually valued — knowledge banks, credentials excluded

A different lens on the same asset, grounded in a live per-agent inventory (persona/doctrine files, accumulated knowledge and playbooks, cron and script footprint, operating memory) taken 2026-07-07 — credentials excluded. Two things drive an agent's value: embodied work (how much accumulated doctrine, iteration, and memory it holds) and strategic role (how central or productizable it is). The figures blend both; the "basis" column shows the main evidence.

How to read this. "Knowledge bank" = each agent's persona, accumulated doctrine / playbooks, memory, and workflows as they stand on 2026-07-07 — not its credentials, which are excluded. This is a component lens that overlaps with the runtime and module figures above (the agents are much of what those are built from), so it is not added on top of the $300K–500K whole-Grid figure. Two honest calibration notes: the highest embodied work sits with TRON, YORI, DUMONT, ABLE, NEON DAVE, BECK, LORA, and MADDIE; while CLU and VERA are genuinely important but carry strategic / forward value (orchestration IP; SaaS template) rather than large accumulated knowledge, and ARES / SARK are valuable but specialized and thin in mass. VERA and PALOMA are the Comms-module agents tied to USP Grid v1.

06 Forward revenue — the value that isn't sunk cost

This belongs in any serious valuation. Replacement cost values the past; a complete picture also prices what the asset can earn. Revenue to date is $0 — stated plainly — so this is option value, presented as scenarios, not a promise.

What this does to the valuation

If the Grid reaches even a modest $15K–40K MRR within 12–18 months across Vera + consulting + one vertical — plausible given the funnels are already built and test-verified — that's $180K–480K ARR. A bootstrapped, owner-operated AI-services asset with proprietary governance IP typically trades at 2–4× ARR, implying $360K–1.9M enterprise value at that maturity. Discounted hard for pre-revenue execution risk, the present income contribution is the $150K–600K option-value lens in §03 — and it is the entire reason a strategic buyer would pay the top of the range rather than the replacement-cost floor.

The framing that helps everyone: this is a revenue engine to share, not a cost to offload. USP wants the Grid precisely because it can earn — so the fair structure lets USP earn with it (owning the client relationships and revenue) while the platform is compensated only as that revenue is realized. Built around the upside, it's a win for all three owners.

07 The HIVE mandate & hardware reimbursement

Two hard requirements that must be conditions of any USP deal — one operational, one financial.

The HIVE cluster

HIVE is the answer: a 5–8× NVIDIA RTX 3080 local-inference cluster where local models do the client production work, in line with the platform's own "Fable thinks, local models work" thesis. Standing it up is a precondition of client-facing deployment, not a nice-to-have. It also protects margins — near-$0 marginal inference cost is what makes the consulting economics work.

Hardware Henry personally bought — USP reimburses or buys

Henry purchased the GPUs, PSUs, and connectors for HIVE out of pocket. This is a tangible asset, separate from the software, and it can be sold to USP at cost:

Keep this line separate and clean: USP buys the HIVE hardware from Henry at documented cost, and funds ongoing client-workload compute. This is not part of the software valuation and shouldn't be bundled into it — it's a simple asset sale with receipts, easy for the other owners to say yes to.

08 The USP deal — real positions & recommended structure

Based on the actual 92-message discussion, not a guess. All three owners are aligned on the goal and stuck on one hinge: own vs. license. Here's where each position stands, what's already agreed, and a structure that works for all three.

Where each position stands

What's already agreed (build on this)

• USP buys the HIVE hardware outright — Longshot proposed this himself ("I'd like USP to buy all your GPUs to be owned by USP"). Settled common ground; see §07.
• USP needs a real, durable, sellable client capability — all three owners agree on this; the only open question is the legal wrapper.
• Local inference (HIVE) is the intended compute base — the owners want client work off personal subscriptions and onto the cluster.
• There's a live client — Andrew — and a contract they want to sign this Friday, focused on the communications layer. That's the real deadline forcing this decision.

Three questions to settle before price

Structure options

Read across the "Owned instance (done right)" column: it is identical to the License column in every row that affects GridFleet. That's the whole point — it's a name, not a different set of economics. The moment any row starts to look like the third column, it has stopped being Option 2 and become Option 3, and should be priced accordingly.

09 How the license works in practice

The questions that actually decide whether this is a good deal for USP: what it costs, who owns what, who fixes it, where data lives, and how compliance works. Concrete, recommended answers below — to be finalized in a short term sheet reviewed by counsel before signing.

9.1 · What USP pays — concrete model

Since USP has no cash today, the recommended model is $0 upfront, pay-as-you-earn. Three components:

• Revenue share: 25% of net revenue on engagements delivered through the platform, paid monthly. GridFleet earns only when USP earns.
• Per-active-client platform fee: $149/mo per live client instance — covers core updates, platform support, and the GAOS/HARMONIC runtime. A floor so GridFleet is compensated even on low-revenue clients.
• Annual minimum (creditable): once USP is operating commercially, a floor of ~$6K/yr, credited against rev-share (USP pays the greater of the two, never both). This keeps compensation sustainable even when a client’s revenue is modest.

Benefit to USP, stated plainly: no capital outlay, no engineering team to hire, a working+maintained product on day one, predictable per-client cost it can build into client pricing, and it keeps the client relationship and ~two-thirds of the revenue. It only ever pays out of money a client is already paying it.

Worked example, so it's 100% clear how the cap plays out. Say USP runs 5 clients at $1,200/mo ($72K/yr of USP revenue):

At this pace USP recovers the low end of the cap (~$80K) in about 3 years; a bigger client book gets there sooner, and the top of the range (~$150K) would take roughly 5–6 years. Either way, once the build value is paid off the 25% revenue share stops for good — USP keeps running v1 and pays only for the maintenance and updates it continues to receive. (Under the more-generous option above, even that maintenance fee ends and USP's use of v1 is fully paid off.)

9.2 · Is it USP's own software? Can USP modify it?

Yes — USP Grid v1 is a deployed instance USP controls: it configures, customizes per client, brands it, and builds workflows and integrations on top. Those customizations belong to USP. The license draws one clear line:

Practically, keep a customization layer (USP's) separate from the core (GridFleet's) — see 9.3. That's what lets USP modify freely while GridFleet still ships updates without overwriting USP's work.

9.3 · Who maintains it, and how do updates flow?

GridFleet maintains the core (voice engine, agents, GAOS/HARMONIC) on a compensated basis — funded by the platform fee — with a defined support SLA (e.g. an emergency-response window). USP handles first-line client support (onboarding, client config); GridFleet handles platform-level bugs and improvements. Updates follow a core + customization model:

• Bug fixes, maintenance, minor improvements to the voice system → pushed to USP's instance, included in the platform fee. USP always runs a current, working product (a real benefit — it doesn't fall behind).
• USP's own customizations sit in a layer updates don't overwrite.
• Major net-new modules / capabilities beyond the v1 scope → optional paid upgrade, not automatic. This is how GridFleet is compensated for future R&D, and how USP avoids paying for things it doesn't want.

9.4 · Data, hosting & compliance — who's responsible for what

USP client data lives on the HIVE cluster (USP's hardware). GridFleet's own clients live on GridFleet hardware — fully separate. That separation is deliberate: it keeps data ownership, liability, and audit exposure cleanly divided. Because USP data sits on USP's own HIVE, there is no storage fee to GridFleet.

Compliance (HIPAA, PCI, etc.): the platform provides the technical capability — encryption, access controls, and immutable audit logging via GAOS/HARMONIC. Operating a compliant environment for a given client is USP's responsibility as the entity holding the client relationship and running HIVE; the client provides its requirements and signs the necessary agreements (e.g. a HIPAA BAA) with USP. Specialized compliance setup or a federal-audit-ready configuration is available from GridFleet as scoped paid professional services — GridFleet supplies the capability and expertise, but is not the compliance guarantor for USP's clients. This is what keeps GridFleet out of USP's clients' regulatory exposure. Legal/FOIA: GAOS/HARMONIC's receipt-and-audit architecture is an asset here — it gives verifiable retention, export, and legal-hold capability; USP, as operator, responds to requests for its clients' records.

9.5 · Does GAOS/HARMONIC have to be included? (and what that means for a purchase)

Yes — as a runtime instance, not as transferred ownership. GAOS/HARMONIC is the governance + memory + audit layer the agents depend on; without it the voice system isn't safe, auditable, or compliant-capable (see 9.4). So USP Grid v1 ships with a licensed GAOS/HARMONIC runtime under its hood, while GridFleet keeps the IP, the control plane, and ongoing development. This is also a reason a license is the correct structure rather than a source sale: the voice module can't cleanly be handed over in isolation — it runs on the shared memory/governance core. Its value is part of what the platform fee and rev-share compensate.

9.6 · What can interact with it?

The platform is built on open, standard interfaces, so USP's instance can integrate broadly: MCP-compatible tools and servers, standard REST APIs / webhooks (CRMs, calendars, ticketing), the built-in connector suite (Google Workspace, Microsoft Outlook/Graph, Telegram), Stripe and the voice stack (ElevenLabs / Deepgram), and both local models on HIVE (Ollama / GGUF — Qwen, GLM, etc.) and cloud models via routing. Longshot's own local-model systems can interoperate over the same API / A2A layer. Integrations USP builds are USP's; the underlying connector framework remains part of the licensed core.

9.7 · Naming — "The Hive — Powered by GridFleet.ai"

This is a good idea, and it serves both sides. For USP, "The Hive" is a real product name it can market and feel ownership of (it runs on the Hive hardware) — which directly answers the "own a version" concern. For GridFleet LLC, the attribution is permanent brand exposure on every USP client deployment and it publicly anchors the licensing relationship. Both names are clean of Disney/TRON IP. One caution: keep the product name ("The Hive") clearly distinct from the HIVE hardware cluster in documentation to avoid confusion.

9.8 · How the module’s value is realized over time

The $50K–95K is the module's asset value (what it would cost to build), not a lump sum USP pays. Under this structure GridFleet recovers and exceeds that value over time while keeping the asset. The safeguards:

• Ownership retained: a license, not a sale — the module stays GridFleet's asset, non-exclusive, and can be licensed to others too. USP never owns the core.
• Recurring recovery: at 25% rev-share + platform fees, a modest book of business returns the module's value within roughly 2–3 years, at which point the revenue share reaches its cap and ends (§9.1), leaving only ongoing maintenance. Example: 5 clients averaging $1,200/mo → USP ≈ $72K/yr; GridFleet ≈ $27K/yr (rev-share + fees) — recovered in ~2–3 years, asset still owned.
• Floors: the per-client fee and creditable annual minimum keep compensation proportional even when a client’s revenue is modest.
• Source escrow, not transfer: if USP needs continuity assurance, source goes into escrow released only on defined events (e.g. GridFleet ceasing operations) — never handed over.
• Perpetual ≠ one-and-done: "perpetual" is the non-expiring right to use v1. The revenue share runs until cumulative payments reach the v1 asset value, then ends (see the cap/endpoint in §9.1) — after which only ongoing maintenance/support applies. The license is version-locked to v1 as delivered (future major versions are separate).
• Valuation on record: the module value and its required GAOS/HARMONIC runtime are memorialized in the agreement (a buyout is priced as both — roughly $80K–150K combined, see 9.5), so if USP ever wants to purchase outright or the relationship winds down, there is an agreed basis.

Net: the module’s value is realized over time through recurring, floored, version-locked license economics, with the asset staying with GridFleet and available to license elsewhere. It is earned back on a schedule that matches how USP can actually pay — as a share of real revenue — rather than as a lump sum USP doesn’t have.

9.9 · Service levels (SLAs) — who's responsible when something breaks

Short answer: the structure does not put the burden of repair solely on GridFleet — and in fairness to both sides, it shouldn't. Responsibility is split by cause and sits in two back-to-back layers, so neither party carries risk it didn't choose and price.

What GridFleet is not on the hook for — because these aren't the core's fault: HIVE hardware (USP-owned, so power/network/disk/GPU failures are USP's), USP's own configuration or client customizations, third-party providers (Twilio/PSTN, ElevenLabs, Deepgram, model APIs, ISPs — no one guarantees these), and force majeure.

The 48-hour example, applied: if a client SLA says "reimburse if downtime > 48 hrs" and the cause is a GridFleet core defect, GridFleet owes USP a capped service credit and restores within its window; USP honors its client reimbursement (partly funded by that credit, bearing any gap it chose to promise). If the cause is HIVE, USP config, or a third party, it's USP's to handle and GridFleet owes nothing. In practice, target restoration is far faster than 48 hours — that threshold is a rare backstop, not the norm.

If USP wants to offer aggressive client SLAs, it can carry that risk itself (having priced it in) or buy an optional premium support tier from GridFleet — tighter restoration targets and a larger (still capped) credit. That's a paid upgrade, so GridFleet is compensated for carrying more, rather than absorbing it by default. GridFleet's aggregate liability to USP is capped at fees paid over a trailing period (e.g. 3–6 months), with no indirect/consequential damages. Net: USP isn't exposed to platform faults it can't fix, and GridFleet isn't exposed to client penalties it never agreed to.

9.10 · Beyond v1 — à la carte parts and agents (scope note)

Beyond USP Grid v1, USP may license individual Grid parts — specific modules or specific agents (see §05) — à la carte. The selection, scope, and pricing of any à la carte arrangement are not covered in this document and would be handled as a separate discussion. One term applies up front: if USP selects an à la carte module or agent, the development and client-side setup of those pieces is USP's responsibility — GridFleet LLC licenses the part; USP integrates, configures, and deploys it for its client. This differs from USP Grid v1, whose Comms module is delivered ready to run.

9.11 · Comms quality depends heavily on the LLM behind the voice agents

This must be clear to everyone up front: the Comms module's results depend heavily on which LLM powers the voice agents (Vera / Paloma). The platform provides the voice pipeline, personas, tools, and governance — but the conversational quality, reasoning, latency, and reliability a client actually experiences are driven by the model chosen to run behind it. Different LLMs produce materially different results.

• Cloud frontier models (e.g. Anthropic or OpenAI top tiers) generally give the best conversational quality and reliability — at a per-conversation API cost.
• Local models on HIVE (Qwen, GLM, etc.) give near-$0 marginal cost and full data locality, but typically trade off some quality, nuance, or latency versus frontier cloud models.
• The right choice is a per-client, per-use-case decision balancing quality, latency, cost, and data-sensitivity — and it can differ from one client to the next.

Why this matters for the deal: the module's value and the client experience both assume a capable model behind it. Model selection is USP's operational choice (USP funds the compute — §9.4), so USP should test model options against each client's needs before committing. GridFleet LLC can advise on model selection as part of support, but the results a client sees are a function of the model USP runs, not the platform alone.

These are recommended commercial positions, not legal advice. IP ownership, service levels and liability, HIPAA/PCI, data-ownership, and records-law terms should be papered in a license agreement and reviewed by an attorney before signing.

10 USP Grid v1 — the complete build-out & what it's worth

The single-page, definitive answer to: what exactly is USP Grid v1, which agents and components are in it, what USP must supply, and what the whole build-out is worth. Everything here must be present for v1 to function appropriately for client use.

Agents included in v1

To be 100% clear on which agents are part of the package:

No other Grid agents are required for v1's core function. CLU orchestration and the rest of the roster (§05) are à la carte (§9.10) — if USP wants them, USP sets them up for the client. GAOS/HARMONIC is included as a runtime system (memory, governance, audit), not as an "agent."

Components & requirements — everything v1 needs to function

So there is zero ambiguity: v1 is the licensed software, governance, wiring capability, and booking connector. On its own it cannot make a call, speak, listen, book, or bill — it needs infrastructure, a model, and third-party service accounts, most of which USP or the client provides. That's not a gap; it's the normal split — the platform is licensed, while the accounts and infrastructure belong to the operator. The full dependency list:

The one-line version: GridFleet LLC delivers the software, the GAOS/HARMONIC runtime, the agent-execution runtime, the comms-wiring capability (via setup + maintenance), and the booking connector. USP / client must supply the LLM, the HIVE infrastructure and compute, and the third-party accounts — Twilio number, ElevenLabs, Deepgram, Stripe, and the client's calendar. Every one of those accounts is provisioned by USP per client (or by the client); none of the main Grid's or GridFleet's own credentials are ever used for USP client work. Without those accounts, v1 is inert. Note also that full multi-agent orchestration (CLU) and the other Grid agents are not required for v1's core function — they're available à la carte (§9.10).

Total value of the v1 build-out

So USP is 100% clear on what this build-out is worth — the value GridFleet LLC delivers (USP/client-supplied infrastructure and accounts are operating costs USP funds, not part of the build-out's value):

The comms-wiring engineering (TESLER) is delivered as an ongoing setup + maintenance service under a license, so it is not a separate asset line; if USP wants to own that engineering capability outright, add ~$5K–11K, for a fully-owned build-out of ~$85K–161K. Under the recommended license, USP pays $0 up front and this value is realized over time via rev-share (§09) — see the options below.

11 Summary & recommendation

With the asset and its value now on the table, here is the bottom line and the recommended path — offered as the fairest structure for all three owners, not a foregone conclusion.

The core recommendation is a license from GridFleet LLC to USP — the structure that gives USP the capability it needs while fairly recognizing the investment that built the platform. The Grid was built with personal money, subscriptions, hardware, and daily labor, entirely after USP was formed. Housed in GridFleet LLC (Henry and Kaley's company), it grants USP a perpetual commercial license — weighted to revenue-share, since USP has no cash to put up front — plus infrastructure reimbursement. USP gets a durable, sellable client system at no upfront cost; the platform is fairly compensated only as it earns. This memo works through the numbers behind that recommendation.

12 One-page term sheet

A plain-language summary the three owners can review and initial to signal agreement in principle. It condenses §08–§09 onto a single page — non-binding, with a definitive agreement to follow.

Initialing this signals agreement in principle so the team can move on the Andrew engagement; it is not the binding contract. The definitive license — drafted from these terms and reviewed by counsel — is what everyone actually signs.

13 Open items, carve-outs & caveats