Sókrates Canonical Master Document

0. How to use this document

This document is the spine.

It is not a brainstorm pad, not a historical archive, and not a dumping ground for parallel narratives. It exists to keep the company from telling three different stories at once.

Anything customer-facing, investor-facing, partner-facing, or internal that describes Sókrates should either:

1. quote this document directly,
2. derive from it without contradiction, or
3. be marked explicitly as exploratory.

If a branch stops being real, it does not linger as “another option.” It moves to the deprecated appendix.

1. Executive summary

Sókrates is a sovereign AI department delivered as a physical on-prem appliance for Icelandic companies. The official product is box-first and sovereign-by-default: a DGX Spark deployed in the customer’s office, running local intelligence against the customer’s own systems and context. The box is not a prop or packaging layer. It is the trust artifact, the deployment boundary, and the main commercial differentiator.

The service is sold as an ongoing AI department on retainer, not as a chatbot, a Copilot deployment, a plugin marketplace, or a consulting project. Customers buy continuous operational intelligence: workflow discovery, integration, automation, governance, and ongoing improvement. The system lives inside their trust boundary, connects only to the systems they authorize, and keeps getting sharper over time.

The product stack combines five ideas into one operating model:

• a physical on-prem appliance,
• a local operational memory and knowledge graph,
• a proactive agent that maps and improves workflows,
• a schema and ontology layer that lets customer systems become legible quickly,
• and a cross-customer basis that compounds learning without exporting customer data.

The default deployment is the NVIDIA DGX Spark. That is the official product. For budget-sensitive or non-sovereign customers, a lighter coordination box with frontier-model routing may be offered as an exception path, but it is not the headline offer and must not define the company narrative.

The go-to-market motion is cluster-led. Sókrates enters through trusted institutional channels, especially industry clusters where members share operational patterns and trust propagates socially. The current beachhead logic is not “all SMEs” and not “all FinTech.” It is trusted clusters first, beginning with the founder’s strongest channels.

The commercial model is simple: one company-level retainer, full stack from day one, with usage passthrough where applicable and no plugin-count pricing. Feature-gated tiers are out. Plugin pricing is out. The customer is buying a department, not a menu.

The official pilot path is EDIH-IS / GBER Article 28. If that path is available, Sókrates uses it. If it is not, the business does not rely on a generic “free trial” motion. The product needs to be strong enough to sell as a real commitment, with the exit architecture serving as the primary risk reducer.

In one sentence: Sókrates installs an AI department inside the customer’s building, inside their trust boundary, and keeps making it more useful over time.

2. Product

2.1 Product definition

Sókrates is an on-prem AI department for organisations that have real operational complexity but do not have the internal expertise, time, or appetite to build one themselves.

It is not sold as software alone. It is not sold as a project. It is not sold as generic AI access. It is sold as a continuing operational capability.

2.2 What the customer buys

Every paying customer buys the same fundamental thing:

• a customer-owned on-prem appliance,
• a deployed Sókrates runtime inside that appliance,
• a configured trust boundary over people, systems, and channels,
• continuous workflow discovery and automation,
• governance and security posture around enterprise AI use,
• ongoing maintenance and improvement under a retainer.

The customer is not paying for a certain number of automations. They are paying for a system that keeps finding and improving work.

2.3 Official product shape

The official product is:

A DGX Spark sitting in the customer’s office, running a sovereign Sókrates stack locally.

That stack includes:

• Sókrates Agent as the intelligence layer
• Eidos as the customer’s operational memory and semantic graph
• Hyle as the schema/ontology ingestion substrate
• Hermes as the communication periphery
• Fleet management for updates, health, backups, and controlled cross-fleet improvement
• Cowork bundle as the launch bundle for knowledge-worker augmentation and workflow automation

2.4 Core product components

The box

The box is the product surface the customer can point at.

It sits on-prem, behind the firewall, inside the customer’s network. It is customer-owned. It anchors the pitch around sovereignty, privacy, control, and trust. It also changes the sales psychology: the customer is not renting access to a dashboard somewhere. They are installing a capacity inside the organisation.

The Sókrates Agent

The Sókrates Agent is the product’s active intelligence layer.

It does not wait passively for prompts. It observes authorised operational signals, initiates structured follow-up, maps workflows, identifies friction, proposes or builds automations, and monitors whether those automations continue to match reality. Its value is cumulative: each mapped workflow makes the next one easier to understand.

Eidos

Eidos is the customer’s operational memory.

It stores the structure of the business: entities, processes, constraints, observations, and the relationships between them. It is the substrate that lets the Sókrates Agent remember, compare, query, and reason over operational context instead of starting fresh every time.

Hyle

Hyle is the ingestion and ontology substrate.

It turns customer schemas into typed concepts the system can reason over. That makes onboarding faster and reduces the amount of brittle manual integration logic required up front.

Hermes

Hermes is the communication periphery, not the brain.

It handles channel I/O and user interaction surfaces. It must remain constrained to that role. Operational system credentials and deep customer access do not live there.

Fleet management

Fleet management exists so every customer box is reproducible, supportable, observable, and recoverable.

This matters because the product is an appliance business, not just a software business. Backup, rollback, heartbeat, update discipline, and hardware replacement are product features, not back-office details.

2.5 Default and exception deployment paths

Default path

Default means:

• DGX Spark
• local inference
• sovereign-by-default posture
• local Eidos instance
• on-prem MCP connections
• customer data and core reasoning kept inside the customer boundary

This is the official story, the official website story, the official investor story, and the official sales story.

Exception path

An exception path may be offered where:

• the customer is budget-constrained,
• the customer is not meaningfully regulated,
• the organisation is small enough that full topology mapping is overkill,
• or the deployment is effectively a stepping-stone account.

That exception path may use a lighter coordination box and frontier APIs. It is real, but it is not the main product. It should be treated as an exception policy, not a second equal narrative.

2.6 Product boundary

The following are inside the official product boundary:

• the appliance
• on-prem deployment
• trust-boundary co-design
• connector activation and scoping
• Eidos seeding and ongoing operational memory
• proactive workflow discovery
• bespoke workflow automation
• ongoing monitoring and maintenance
• AI governance posture
• exit architecture

The following are not the product in their own right:

• managed Claude environment by itself
• hosted Eidos as a standalone SKU
• plugin marketplace as a standalone business
• generic AI consulting
• one-off workflow automation projects

2.7 Trust and exit architecture

Trust is part of the product, not an afterthought.

The customer chooses which employees the system may interact with, which systems it may connect to, and which channels it may use. Connectors are individually legible and individually revocable.

If the customer leaves, they keep the box and everything that is properly theirs: deployed infrastructure, local context, connectors, and existing plumbing. What they lose is the continuing intelligence layer that kept making the system better. This is not only an exit design. It is a trust design and a sales design.

2.8 Product positioning language

Use language like:

• “AI department in a box”
• “sovereign by default”
• “installed inside your trust boundary”
• “continuous operational intelligence”
• “customer-owned appliance”
• “your data and operational context stay on-prem”

Do not lead with language like:

• “AI consulting”
• “Claude setup service”
• “hosted knowledge graph”
• “plugin marketplace”
• “chatbot deployment”

2.9 Product sequencing

Launch product: Cowork.

Cowork is the correct starting bundle because it captures the highest-density operational pain with the smallest initial implementation surface. It lets Sókrates prove the core thesis before branching into developer workflows or deeper autonomous domain operations.

Code and Compound are expansions, not the definition of the initial product.

3. Target customer and ICP

3.1 Canonical ICP definition

The official ICP is Icelandic companies with 25–75 employees.

That is the public range and the strategic range. It captures the segment where operational complexity is real, internal AI capacity is missing, decision velocity is still high, and incumbent providers are structurally misaligned or overpriced for the engagement size.

Within that public range, the practical sell-first band is 35–75 employees.

That narrower band is where the current economics, deployment overhead, and trust-based founder-led sales motion are strongest when DGX Spark is the default appliance. Companies in the 25–35 range are not excluded, but they are more selective cases: unusually dense operational complexity, strong trust-channel entry, subsidy support, or exceptionally sharp ROI.

3.2 Buyer profile

The canonical buyer is usually one of:

• CEO
• managing director
• COO
• occasionally a senior operations leader with real budget authority

The buyer is not typically an IT director or formal head of AI, because the target company usually does not have one.

The buyer profile is defined less by title than by five conditions:

1. They know AI matters.
2. They do not have a credible internal plan.
3. Their employees are already using AI informally.
4. They do not fully trust or govern that usage.
5. They would rather buy an ongoing capability than assemble one from tools and vendors.

Psychologically, this buyer wants to make one decision: “we now have an AI department.” They do not want to run a beauty contest between copilots, model vendors, workflow tools, and security wrappers.

3.3 Organisational profile

The target customer is an Icelandic company with:

• meaningful operational topology
• multiple recurring workflows crossing systems or teams
• expensive knowledge work or coordination work
• no serious internal AI leadership
• some existing M365 or Google Workspace footprint
• at least some ungoverned or lightly governed AI usage already in the company

The best-fit organisations have workflow friction that is chronic rather than dramatic. The pain is often not “everything is broken.” It is “too many valuable people are still doing glue work by hand.”

3.4 Structural fit criteria

A company fits the ICP when most of the following are true:

• approvals or handoffs cross multiple people or departments
• work moves across more than one core system
• reporting, compliance, documentation, quoting, reconciliation, or coordination consumes expensive human time
• process knowledge lives in people rather than in clean operational systems
• AI usage already exists, but automation and governance do not
• the organisation is too complex for self-serve tools and too small to hire a serious internal AI team

The wedge is therefore not “companies that like AI.” It is companies with enough operational topology to map, enough trust sensitivity to care, and not enough internal capability to solve it themselves.

3.5 Sector and channel logic

The true beachhead is cluster-led, not sector-led in the abstract.

The launch channel is Reykjavík FinTech Cluster.

That is the first channel because it combines all the right ingredients at once:

• immediate warm introductions
• explicit trust transfer
• compliance and governance sensitivity
• knowledge-dense operations
• cluster leadership aligned strongly enough to actively help sell the service

This means FinTech is the first visible market, but it should be understood primarily as the launch channel and reference market, not the total long-run definition of the business.

Underneath that channel, the repeatable operational wedge still points toward sectors with dense coordination and workflow friction, especially:

• transport and logistics
• rental and specialised services
• manufacturing

Those sectors remain strategically important because the structural gap is obvious there and the basis can compound quickly across similar operational shapes.

The Biomedical cluster is the next serious institutional channel once it is actually live. It is not the launch motion.

3.6 Inclusion and exclusion rules

Strong fit:

• 35–75 employees
• CEO- or COO-led buying process
• operational complexity visible across 3–5+ recurring workflows
• trust, compliance, or sovereignty sensitivity
• willingness to buy an ongoing department rather than a one-off project

Selective fit:

• 25–35 employees with unusually dense operational topology
• cluster-backed opportunities with strong trust transfer
• subsidized engagements where economics improve materially
• flagship warm-intro accounts that create disproportionate market signal

Weak fit or non-fit:

• very small firms with little real organisational topology
• customers that only want generic AI seat rollout
• customers shopping for the cheapest chatbot or Copilot administration service
• large enterprises with long procurement cycles and existing internal AI or IT ownership
• customers who fundamentally want hosted cloud intelligence as the main product form

3.7 Canonical ICP statement

Use this as the short-form internal truth:

Sókrates serves Icelandic companies with 25–75 employees, sells most naturally to 35–75 employee firms, enters first through trusted clusters led by FinTech, and wins where operational complexity, trust sensitivity, and lack of internal AI capacity all coexist.

4. Go-to-market and sales

4.1 Canonical GTM thesis

Sókrates is a cluster-led, founder-led, box-first field sales motion.

It is not a broad inbound SaaS funnel. It is not a self-serve motion. It is not generic AI consulting. It is not managed-Claude administration as the lead story.

The GTM engine works because trust, topology, and physical deployment all matter at once.

The cluster supplies trust. The founder supplies judgment. The box supplies differentiation. The retainer supplies economic alignment.

4.2 Launch channel sequence

Launch channel: Reykjavík FinTech Cluster

FinTech goes first.

That is not because FinTech is the only possible sector. It is because the launch conditions are strongest there:

• the founder has direct structural access
• warm intros are effectively guaranteed
• cluster leadership is commercially aligned
• members feel real pressure around governance, compliance, and operational maturity
• the box story resonates strongly in that environment

The goal of the first wave is not merely revenue. It is to create visible, high-trust reference deployments in a cluster where peer observation matters.

Follow-on institutional channel: Biomedical cluster

Biomedical is the next serious channel once the cluster is actually live and capable of moving opportunities.

It should be prepared in parallel but not treated as the initial launch motion.

Operational expansion after channel proof

Once the first cluster references exist, GTM can widen into adjacent companies and sectors where the operational wedge is strongest, especially:

• transport and logistics
• rental and specialised services
• manufacturing

That sequence matters. The first proof comes from cluster trust. The first scale comes from repeated operational shapes.

4.3 Positioning

The box is the pitch.

The strongest opening line is not “we help you use AI better.” It is closer to:

“We install your AI department in your office, inside your trust boundary.”

The positioning hierarchy is:

1. sovereign AI department in a box
2. ongoing operational intelligence on retainer
3. customer-owned appliance and exit-safe trust model
4. workflow discovery, integration, automation, and governance as one service

Do not lead with:

• hosted intelligence
• managed Claude workspace
• plugin catalogues
• knowledge graph terminology
• consulting language

Those may all be true components. They are not the top-line story.

4.4 Acquisition motion

The canonical acquisition path is:

1. Warm introduction via cluster leadership, founder network, or trusted referral.
2. Founder-led discovery conversation with CEO / COO / managing director around real workflow friction.
3. Live box-centered demonstration on an actual workflow or operational pattern, not a canned generic demo.
4. Trust-boundary co-design where the buyer helps define which people, systems, and channels are in scope.
5. Commercial fork:
   • if EDIH / GBER is available and appropriate, submit a subsidized pilot proposal;
   • if not, move directly to a paid deployment proposal.
6. On-prem deployment and seeding with the box, Eidos, authorised connectors, and Cowork live.
7. Early proof-of-value period where Sókrates maps workflows, builds automation, and makes the ROI visible quickly.
8. Continuation on retainer as the default steady-state relationship.

The key principle is that the first proof phase is not a generic free trial. It is either a subsidized pilot or the first phase of a paid engagement.

4.5 Sales mechanics

The sales motion remains founder-led through the Iceland beachhead.

This is appropriate because:

• ACV is too high for self-serve and too relationship-driven for cheap outbound motion
• the buyer is making a trust-based decision
• the founder is part of the product evaluation
• early GTM is as much pattern collection as customer acquisition

The sales conversation should revolve around:

• what the box is
• what it can and cannot see
• how the trust boundary is defined
• which workflows are currently wasting expensive human time
• what happens if the customer later leaves

The exit architecture is part of the sale. It reduces fear without reducing price.

4.6 Iceland channel mix

For the Iceland beachhead, the channel mix is:

1. Cluster-led entry, with FinTech first
2. Warm referral cascade from early customers and trusted operators
3. Founder network and Wise-adjacent relationships
4. Selective business association events and case-study speaking
5. EDIH and similar institutional paths where they reduce friction or open doors

Paid media, SDR-heavy outbound, and generic content marketing are non-priorities in this phase.

The Iceland market is too small and too relationship-dense for a normal startup funnel fantasy. The GTM system should behave more like a tight network of trust transfers and reference propagation.

4.7 Sales cycle and conversion logic

The expected cycle from first conversation to paid engagement is still short by enterprise standards, generally measured in weeks, not quarters.

Where EDIH is involved, the administrative path may extend timing. Where it is not involved, the path is simpler: trust transfer, live workflow diagnosis, paid deployment.

The strongest conversion driver is not generic “AI excitement.” It is the combination of:

• tangible sovereignty and trust from the box
• a narrow early proof-of-value period
• visible workflow automation on real operations
• the buyer understanding that they are purchasing a department, not a tool rollout

4.8 GTM rules

What to do:

• sell through trusted institutions first
• keep the founder close to the first customers
• use cluster proof to create peer-observed legitimacy
• keep the official story box-first and sovereign-first
• treat FinTech as the launch channel and reference market
• use operationally similar sectors for repetition once proof exists

What not to do:

• do not reintroduce a cloud-first public ladder
• do not lead with managed Claude as the entry product
• do not sell hosted Eidos as an official SKU
• do not fall into generic free-trial culture
• do not use plugin pricing or plugin-count sales language
• do not confuse the market by telling different sectors different product stories

4.9 Canonical GTM statement

Use this as the short-form internal truth:

Sókrates launches through the Reykjavík FinTech Cluster, sells the sovereign box first, uses founder-led field sales and trust-boundary co-design, deploys via subsidized pilot when available or direct paid engagement when not, and expands from cluster proof into operationally similar sectors and later clusters.

5. Commercial model and financial plan

5.1 Pricing philosophy

Sókrates is sold as an ongoing AI department, not as a metered software product.

The commercial model is designed around four principles:

1. the invoice must be understandable in one breath;
2. incentives must stay aligned between customer and company;
3. hardware economics must be explicit rather than hidden inside onboarding;
4. recurring revenue must be tied to continuing operational intelligence, not usage spikes.

There is no plugin-count pricing, no token metering, and no feature-gated public tier ladder. Customers buy a continuing capability inside their trust boundary.

5.2 Commercial structure

The official commercial structure has four parts:

1. Appliance procurement — the customer buys the DGX Spark appliance upfront.
2. Deployment and onboarding — one-time implementation fee for installation, trust-boundary design, connector activation, Eidos seeding, initial workflow mapping, governance baseline, and employee enablement.
3. Monthly retainer — the ongoing fee for the AI department itself: workflow discovery, automation, governance, maintenance, fleet oversight, and human stewardship.
4. Optional passthroughs — only where needed, such as frontier seats, third-party licenses, or exceptional external compute.

5.3 Official pricing schedule

Unless otherwise specified, all quoted prices are business prices before VAT.

Appliance procurement

• DGX Spark appliance: ISK 680,000 upfront

This line item is paid before hardware order. The customer owns the appliance from day one.

Deployment and onboarding

Public pricing is banded by company size, with internal complexity uplifts applied where integration burden or organisational topology materially exceed the norm.

• 25–35 employees: ISK 400,000
• 35–55 employees: ISK 600,000
• 55–75 employees: ISK 800,000

Internal complexity uplifts may be applied for factors such as multi-site operations, unusually high connector count, regulated data environments, messy source systems, or complex identity/authentication requirements.

Monthly retainer

• 25–35 employees: ISK 400,000 / month
• 35–55 employees: ISK 600,000 / month
• 55–75 employees: ISK 800,000 / month

Retainers are month-to-month after onboarding, with annual CPI-linked adjustment.

Optional passthroughs

Optional passthroughs are not part of the default product story. They exist for edge cases and customer preference.

Examples include:

• frontier model seats or enterprise workspaces;
• third-party SaaS or connector licenses;
• exceptional external model usage where local inference is not the chosen path;
• customer-specific software dependencies not included in the standard stack.

Passthroughs are billed transparently and are not the core revenue engine.

5.4 Invoice structure and cash timing

The default cash timing is:

On signature

• DGX Spark appliance procurement invoice (100% due before hardware order)

On deployment start

• deployment and onboarding fee

On operational acceptance

• monthly retainer begins
• then billed monthly in advance

This structure keeps working capital sane, keeps the customer-facing model simple, and preserves the exit-safe narrative by avoiding financing tricks.

5.5 First-phase proof of value

Proof of value is delivered inside the paid engagement rather than through a generic free trial.

There are two review points in the initial phase.

Week 2: operational acceptance

The following should be true by the operational acceptance checkpoint:

• the DGX Spark is installed and live on-prem;
• the Sókrates runtime is operational locally;
• Eidos is seeded;
• core authorised connectors are active;
• the trust boundary is documented and approved.

Week 6: value review

The following should be true by the value review checkpoint:

• at least one recurring workflow is live in production;
• at least one additional workflow has been mapped and approved for deployment;
• a governance baseline has been delivered;
• real employee usage is visible;
• a written value memo documents at least one quantified operational delta.

The early-phase question is not “did the demo look clever?” It is “did the appliance enter the company’s operational reality and start producing measurable improvement?”

5.6 Why the retainer remains unchanged under DGX-default

The monthly retainer does not need to rise merely because DGX Spark is now the official default.

That is the entire point of making hardware explicit.

The retainer is paying for the continuing AI department: operational discovery, human stewardship, governance, plugin maintenance, Eidos curation, and cross-fleet learning translated into customer value. The hardware line item pays for the box.

The old commercial error was not that the retainer bands were too low. The old error was pretending hardware could disappear inside onboarding arithmetic.

5.7 Revenue composition

The financial model should be read in two layers.

Recurring revenue

Recurring revenue is the real company.

It consists primarily of the monthly retainer. Optional passthroughs may exist, but they should not be treated as the core economic engine.

Upfront revenue

Upfront revenue has two components:

• modest margin on hardware procurement;
• materially better margin on deployment and onboarding.

Upfront revenue matters for cash timing and implementation capacity, but it is not the long-term thesis. The long-term thesis is durable recurring retainers with high retention driven by compounding value.

5.8 Planning assumptions for the financial model

The following assumptions are used for the working model below.

Blended planning customer

For planning purposes, the blended Iceland beachhead customer is modeled as:

• ISK 620,000 monthly retainer
• ISK 620,000 deployment/onboarding fee
• ISK 680,000 hardware line item

This reflects a customer mix tilted toward the practical sell-first band of 35–75 employees.

Working direct recurring cost assumptions

For steady-state recurring operations, the model uses conservative per-customer direct cost assumptions of:

• 25–35 employees: ISK 100,000 / month
• 35–55 employees: ISK 130,000 / month
• 55–75 employees: ISK 170,000 / month

These direct costs are meant to cover the real service burden of the account, including:

• human service allocation,
• fleet/backup/observability overhead,
• warranty and replacement coordination overhead,
• residual external model or service calls where they still occur.

Deployment direct cost assumptions

For one-time deployment work, the working model assumes direct delivery cost of roughly:

• 25–35 employees: ISK 120,000
• 35–55 employees: ISK 180,000
• 55–75 employees: ISK 260,000

These are internal planning figures, not public pricing disclosures.

5.9 Customer-level economics

Recurring contribution by public band

Segment	Monthly retainer	Direct recurring cost	Monthly gross contribution	Recurring gross margin
25–35 employees	ISK 400,000	ISK 100,000	ISK 300,000	75.0%
35–55 employees	ISK 600,000	ISK 130,000	ISK 470,000	78.3%
55–75 employees	ISK 800,000	ISK 170,000	ISK 630,000	78.8%

This is the recurring engine of the business.

Upfront contribution by public band

Segment	Hardware gross contribution	Deployment gross contribution	Total upfront gross contribution
25–35 employees	ISK 60,000	ISK 280,000	ISK 340,000
35–55 employees	ISK 60,000	ISK 420,000	ISK 480,000
55–75 employees	ISK 60,000	ISK 540,000	ISK 600,000

The hardware line item is not where margin lives. It is where honesty lives. Deployment and the monthly retainer are where contribution is actually created.

5.10 First-sale economics

A newly signed customer at each public band produces the following billings before optional passthroughs:

Segment	Hardware	Deployment	First month retainer	Initial billed value
25–35 employees	ISK 680,000	ISK 400,000	ISK 400,000	ISK 1,480,000
35–55 employees	ISK 680,000	ISK 600,000	ISK 600,000	ISK 1,880,000
55–75 employees	ISK 680,000	ISK 800,000	ISK 800,000	ISK 2,280,000

This matters for cashflow and founder runway even more than it matters for accounting optics.

5.11 Gross margin and operating model

The business should be modeled as a managed-services business with appliance characteristics, not as pure SaaS.

That means:

• recurring gross margin is primarily driven by human service efficiency, not raw inference cost;
• deployment quality and onboarding compression matter a lot;
• cross-customer basis depth improves contribution over time;
• hardware margin stays modest and should not be used to mask operational weakness.

A sensible planning target for recurring gross margin at steady state is roughly 75–79%, not because the software is magically free, but because local inference, explicit hardware treatment, and relationship-led acquisition all push the model away from cloud-AI margin compression.

5.12 Cash breakeven

The old “customer 2 breakeven” claim should not be canonised in its old form.

That number came from a cheaper-hardware, trial-heavier, founder-time-is-free framing.

The more honest framing is:

• cash breakeven in the solo-founder phase: around 2–3 active customers, depending on the exact founder draw and base overhead;
• sustainable operating breakeven with one support/ops hire: around 4–5 active customers.

That is still a very good business. It is just less theatre.

5.13 Iceland phase overhead model

For planning, the business should continue to assume a lean Iceland-phase overhead structure in roughly the following range:

• founder draw / salary;
• cloud and observability services;
• software and tooling;
• legal/accounting/admin;
• insurance and misc.

A working monthly overhead range of approximately ISK 1.0M–1.3M remains directionally reasonable for the solo-founder phase, with overhead increasing once the first support/ops hire is added.

This is a planning range, not a polished investor slide.

5.14 Year 1 revenue scenarios

The old 30–40 customer Year 1 framing is too aggressive for a founder-led appliance business and should be treated as stale.

The cleaner Year 1 model is:

Downside case

• 6 customers signed in Year 1
• recognized revenue: ~ISK 32M
• interpretation: the product sells, but deployment capacity and channel conversion are slower than hoped

Base case

• 12 customers signed in Year 1
• recognized revenue: ~ISK 64M
• interpretation: cluster-led launch works, paid deployments convert, and founder capacity is the real bottleneck

Upside case

• 18 customers signed in Year 1
• recognized revenue: ~ISK 96M
• interpretation: cluster references propagate quickly, referrals start compounding, and delivery discipline keeps pace

These figures assume a blended planning customer, customer acquisition spread across the year, and include hardware plus deployment revenue in addition to recurring retainers. They exclude optional passthroughs as a core planning driver.

5.15 Year 2 directional model

A reasonable directional Year 2 planning frame is:

• 18–30 active recurring customers by year end in the base-to-upside range;
• ~ISK 120M–220M recognized revenue depending on new bookings, activation timing, and hiring pace;
• a small team, not a large one;
• continued Iceland concentration with selective external expansion only once delivery quality is stable.

The key point is that Year 2 should be modeled as operational deepening plus careful scaling, not as a rush to maximize headline customer count.

5.16 Retention economics

The retention story remains one of the strongest parts of the business.

Customers keep the appliance and the installed infrastructure if they leave. What disappears is the continuing intelligence layer, governance, workflow evolution, and stewardship.

That means retention is earned, not coerced.

It also means retention should improve with tenure, because:

• Eidos gets richer;
• the operational map gets denser;
• more workflows are embedded;
• the customer increasingly experiences the absence of Sókrates as operational loss rather than software churn.

5.17 What should not be canonised yet

The following should remain explicitly provisional until real operating data exists:

• precise CAC and LTV ratios;
• exact steady-state team-to-customer ratios;
• exact multi-year margin curves;
• exact expansion revenue assumptions;
• any flashy “customer 2 breakeven” or “78:1 LTV:CAC” storytelling.

Those are the kinds of numbers that become embarrassing when they are inherited from stale assumptions.

5.18 Canonical short-form commercial statement

Use this as the short-form internal truth:

Sókrates sells a customer-owned DGX appliance upfront, charges a separate deployment fee, then runs the AI department on a company-level monthly retainer. Hardware is explicit, recurring revenue is the real business, passthroughs stay secondary, and the economics should be modeled as a lean managed-services appliance business rather than as pure SaaS.

5.19 Hardware lifecycle and replacement

Hardware replacement is treated as a future capex event, not a reserve hidden inside the monthly retainer. Sókrates coordinates diagnosis and warranty handling during the engagement. Where local spare stock exists, temporary replacement can be provided next business day; otherwise replacement follows the fastest commercially reasonable path.

5.20 Why the retainer compounds

The monthly retainer is not paying for idle subscription access. It is paying for three compounding loops that only exist because the appliance lives inside the customer’s trust boundary. These loops are the commercial substance behind the “gets sharper over time” language in §1 and the retention economics in §5.16.

The operational graph gets denser. Eidos accumulates entities, workflow topology, process constraints, and observations with every week of operation. The substrate the system reasons against is materially richer at month six than at month one, and materially richer again at month twelve. A self-improving harness pointed at thin context is a fast way to be wrong; dense operational signal is where the real value lives.

The model gets specialized. The local Gemma 4 31B base is sharpened with per-task QLoRA adapters — workflow mapping, schema extraction, reconciliation, governance review, and so on. Base weights stay sovereign and local; specialist adapters are swapped in per task. The library of specialist modes deepens over tenure, and each mode sharpens against the specific operational signal the customer actually produces.

The harness refines in context. Procedural memory, skill generation, and prompt lineage adapt to this customer’s workflows, connectors, approvals, and language. Self-improving harnesses are table stakes as a mechanism; what makes them valuable here is that the refinement substrate is the customer’s real trust-boundary signal, not a generic cloud trace shared across unrelated tenants.

These axes are not independent. Denser graph produces better fine-tune data for the adapters. Sharper adapters produce cleaner operational output. Cleaner operational output produces a denser graph. The retainer pays for the human stewardship that keeps all three loops clean — curating what enters Eidos, deciding which task modes deserve adapter training, and approving which harness refinements are worth keeping.

This is the substantive answer to “why does this get better over time, and why is that worth a monthly fee.” A department compounds. A software subscription does not.

6. Pilot and subsidy model

6.1 Canonical position

Sókrates does not run a generic free-trial GTM model.

There are two valid entry modes:

1. Subsidized pilot, when EDIH-IS / GBER Article 28 is available and appropriate.
2. Direct paid deployment, when subsidy is unavailable, unnecessary, or too slow.

The subsidy path is useful. It is not the foundation of the business.

6.2 Role of EDIH-IS / GBER Article 28

EDIH-IS is the preferred institutional pilot path because it can reduce customer risk, improve early conversion conditions, and align Sókrates with a live public funding mechanism built for “Test Before Invest” engagements.

When it works, Sókrates should use it.

But it should be understood as a financing and access accelerator, not as the product itself and not as a precondition for selling.

6.3 Default fallback when subsidy is unavailable

If subsidy is unavailable, Sókrates proceeds directly to a paid deployment.

Not a free trial. Not a watered-down teaser engagement. Not a separate fake entry product.

The risk reducer in that case is:

• the trust boundary
• the physical appliance
• the clarity of the retainer model
• the early proof-of-value period inside the paid engagement
• the exit architecture

This is commercially healthier and keeps the company from drifting into unpaid or underpriced services work.

6.4 First-phase delivery under both paths

Whether the customer enters through subsidy or direct paid deployment, the first operating phase follows the two-checkpoint structure defined in §5.5 (Week 2 operational acceptance, Week 6 value review). The difference between the two entry modes is financing and procurement friction, not product shape.

6.5 Why direct paid deployment is viable

Direct paid deployment is viable because the ROI case in Iceland is structurally strong.

Labour costs are high, expensive knowledge work is being burned on glue tasks, and the buyer’s real constraint is expertise and trust rather than the last marginal krona of software spend.

Sókrates does not need subsidy to be economically rational. Subsidy simply makes the first step easier.

6.6 Canonical subsidy statement

Use this as the short-form internal truth:

When EDIH-IS / GBER Article 28 is available, Sókrates can use it for subsidized pilots. When it is not, Sókrates sells direct paid deployment. There is no generic free-trial fallback.

7. Delivery and deployment

7.1 Official deployment shape

• appliance provisioned
• NixOS image deployed
• trust boundary defined
• local Eidos seeded
• authorised connectors activated
• Cowork live
• Sókrates Agent begins proactive discovery

7.2 Operational invariants

• reproducible builds
• pull-based updates
• rollback on failure
• encrypted backups
• strict separation between periphery and intelligence
• customer-system credentials never exposed to Hermes

8. Technical architecture

8.1 Architecture principle

The architecture is meant to reduce inference-time chaos by imposing structure first.

The system should reason over typed, pre-computed, semantically organised topology, not over raw sprawl.

8.2 Canonical components

• Hyle: schema and ontology substrate
• Eidos: semantic control plane and operational memory
• Metalayer / hyperedges: computed organisational topology
• Gemma 4 31B on DGX Spark: local continuous reasoning substrate
• Basis: cross-deployment intelligence that compounds without exporting customer data

8.3 Product/architecture alignment

The architecture should be described as serving the box-first sovereign product, not as supporting a three-tier public ladder. The ladder can survive as historical context or an internal design lineage, but not as the customer-facing master narrative.

8.4 Compounding substrate

The sovereign deployment exists to enable three compounding loops that cannot run outside the customer’s trust boundary. This is the architectural basis for the retention thesis in §5.20.

Axis 1: Operational graph (Eidos)

Eidos continuously accumulates entities, workflow topology, constraints, and observations. It provides dense, legible context for every downstream reasoning call and, critically, serves as the retrieval and training substrate for the specialist adapters described below. The graph is the single most important asset the customer builds inside the appliance, and its density is the primary signal-quality determinant for the rest of the stack.

Axis 2: Per-task QLoRA specialist modes

The local Gemma 4 31B base is kept pristine. Specialist QLoRA adapters are trained per operational task type — workflow mapping, schema extraction, reconciliation, governance review, and similar — against the customer’s own operational signal curated through Eidos.

Adapters are hot-swappable at inference time. The library of specialist modes deepens over tenure. Training runs happen on the appliance or on a customer-scoped training environment; base weights never leave the trust boundary, and adapters remain customer-scoped by default.

This is the official model-specialization path. Full-parameter fine-tuning is not the path. Prompt-only specialization is not the path. QLoRA specialist modes are the canonical mechanism.

Axis 3: Local harness refinement

Procedural memory, skill generation, prompt lineage, and tool orchestration refine against the specific customer’s workflows, connectors, and language. A self-improving harness is table stakes as a mechanism. What makes it valuable here is that the refinement substrate is the customer’s real trust-boundary signal, shaped by real approvals, real edge cases, and real operational vocabulary, not a generic cloud trace.

Harness refinement lives inside the periphery/intelligence separation defined in §7.2 and §9.1. Skill generation that touches operational credentials or deep customer systems belongs to the intelligence layer, not to Hermes.

How the three axes compound

The loops feed each other:

• denser graph → better retrieval and better fine-tune data for adapters;
• sharper adapters → cleaner task-specific reasoning and cleaner operational output;
• cleaner operational output → higher-signal updates flowing back into the graph;
• refined harness skills → tighter orchestration of all of the above against this customer’s real workflows.

Sovereignty is the structural precondition. A cloud agent can do harness self-improvement on shared traces. It cannot accumulate this specific customer’s operational graph inside a revocable trust boundary, train adapters against signal it is structurally forbidden to collect, or refine a harness against context it is not allowed to see. The three axes are only coherent together, and they are only coherent on-prem.

9. Security and trust

9.1 Security posture

Security is not “enterprise-ready later.” It is part of the wedge.

The product promise rests on:

• on-prem deployment
• network and credential isolation
• periphery/intelligence separation
• constrained egress
• customer-controlled connectors
• inspectable trust boundaries

9.2 Sovereign-by-default language

Be precise. “Sovereign by default” is stronger and more honest than making absolute promises that only hold under certain inference paths.

When DGX Spark is deployed, local inference is the default story. When exception deployments use frontier APIs, language must reflect that explicitly.

10. Roadmap skeleton

10.1 Phase 1

• Launch canonical box-first offering
• Sell through cluster channels
• Deliver Cowork well
• Tighten deployment, backup, and fleet routines
• Establish real customer proof points

10.2 Phase 2

• Deepen basis in repeated vertical patterns
• Improve onboarding speed from accumulated knowledge
• Refine sovereign deployment and adapter strategy
• Expand selectively into adjacent cluster ecosystems

10.3 Phase 3

• Add Code and then Compound where justified by real demand
• Expand geographically only once the Icelandic model is genuinely repeatable

11. Risks and unresolved questions

11.1 Live risks

• derived commercial docs in the repo still reflect cheaper-hardware assumptions and need to be reconciled to v1 §5
• working-capital exposure on concurrent DGX procurements is real under upfront-payment model and constrains deal-close parallelism until customer cash clears
• sovereign default increases hardware and deployment discipline requirements
• cluster-led GTM is strong but channel-concentrated
• EDIH acceptance materially affects pilot structure
• actual first-phase founder hours per deployment are unvalidated; if the baseline case runs hot, the onboarding bands in §5.2 may be below cost and the complexity uplift will become the rule rather than the exception

11.2 Open questions to resolve later

• whether any public materials should mention the exception path at all
• when to formally introduce Biomedical-specific positioning
• how explicitly to describe local vs external inference in customer copy by segment
• exact hardware handling margin percentage and whether it is disclosed or embedded
• VAT treatment on appliance line item: seller-of-record vs partner-procurement

12. Decision log

2026-04-11

• Financial plan integrated into §5: pricing philosophy, invoice cash timing, revenue composition, planning cost assumptions, customer-level contribution tables, first-sale economics, cash breakeven framing, Iceland overhead range, Year 1 downside/base/upside scenarios (6/12/18 customers, ~ISK 32M/64M/96M), Year 2 directional model (18–30 customers, ~ISK 120M–220M), retention economics, and what remains provisional
• Recurring gross margin planning target set at ~75–79% with explicit managed-services-with-appliance framing, not pure SaaS
• Blended planning customer fixed at ISK 620k retainer / ISK 620k deployment / ISK 680k hardware, reflecting tilt toward the 35–75 employee practical sell-first band
• Old “customer 2 breakeven” claim formally retired; replaced with solo-founder 2–3 customer cash breakeven and 4–5 customer operating breakeven with one support/ops hire
• Old 30–40 customer Year 1 framing formally retired as stale
• §5 title changed from “Commercial model” to “Commercial model and financial plan”; hardware lifecycle section preserved as §5.19
• Compounding substrate formalized as three axes: dense operational graph (Eidos), per-task QLoRA specialist modes on local Gemma 4 31B, and local harness refinement. Added as architectural §8.4 and commercial §5.20 “Why the retainer compounds”
• QLoRA specialist-mode architecture adopted as the official model-specialization path. Base Gemma 4 31B weights stay pristine and local; specialist adapters are trained per operational task type (workflow mapping, schema extraction, reconciliation, governance review, etc.) against customer signal; adapters hot-swapped at inference time. Library of modes deepens with tenure. Full-parameter fine-tuning and prompt-only specialization are explicitly not the path.
• Self-improving harness reframed as table stakes; the actual differentiation is the signal quality it refines against — dense customer graph plus specialist adapters plus local workflow context — which is only possible inside the trust boundary
• Sovereignty reframed as the structural precondition for the compounding substrate, not a compliance checkbox. A cloud agent can do harness self-improvement on shared traces but cannot run any of the three compounding loops together against a single customer’s signal.
• First Gemma QLoRA training environment being stood up in a non-Sókrates context as hands-on experience with the specific base model; not yet a Sókrates deployment run, but de-risks the adapter training path for Axis 2.

2026-04-10

• Commercial model v2 adopted: four components (appliance procurement, deployment and onboarding, monthly retainer, optional passthroughs)
• DGX Spark set as a separate ISK 680,000 upfront line item, paid before hardware order; modest handling margin embedded
• Onboarding fees publicly banded at ISK 400/600/800k by employee tier (25–35 / 35–55 / 55–75); complexity uplifts applied internally during trust-boundary co-design
• Monthly retainer publicly banded at ISK 400/600/800k by employee tier; symmetric with onboarding for commercial legibility
• Retainer commitment set as month-to-month after onboarding with annual CPI-linked adjustment; commercially honest because hardware is paid upfront and customer is never locked in
• First-phase proof of value formalized with Week 2 operational acceptance checkpoint and Week 6 value review checkpoint, inside the paid engagement
• Hardware lifecycle replacement set as a new capex event, not a retainer-embedded reserve
• Warranty and replacement posture: Sókrates coordinates diagnosis and warranty, next-business-day temporary replacement where local spare stock exists, otherwise fastest commercially reasonable path
• Old unit economics from cheaper-hardware era (customer-2 breakeven, 76% gross margin, per-seat onboarding fee, Claude Teams seat passthrough as default COGS) formally retired from canonical status pending DGX-baseline rerun

2026-04-09

• Entry product set to box-first
• One-retainer model confirmed
• Plugin-count pricing confirmed dead
• Subsidized pilot path clarified as EDIH-IS / GBER Article 28 when available
• Hosted Eidos removed from official product set
• DGX Spark set as default deployment target
• CWWK/frontier route demoted to exception path
• Cluster-led GTM set as primary beachhead logic
• FinTech cluster set as launch channel; Biomedical cluster set as follow-on channel
• Public ICP kept at 25–75; practical sell-first band clarified as 35–75
• No-subsidy fallback clarified as direct paid deployment rather than generic trial

Appendix A. Deprecated or non-canonical branches

The following may continue to exist in old docs, but are not canonical:

• “The entry product is not the box”
• managed-Claude-first public ladder
• hosted-Eidos-as-official-product
• feature-gated tier narratives
• plugin-count pricing
• generic free-trial-first GTM
• CWWK-as-default public positioning
• hardware-hidden-in-onboarding fee structures
• per-seat onboarding pricing
• Claude Teams seat passthrough as the default COGS baseline
• Beelink EQ14 / CWWK-era unit economics: customer-2 breakeven, 76% gross margin, cheap-hardware-amortized-into-onboarding math
• cluster-led trials treated as the central conversion mechanism rather than an optional accelerant

These branches may still contain useful thinking, but they no longer define the company.