VSAT value chains
The VSAT platform and its extensions — VSATLAS for interpretive linking, VSATLATARIUM for spatial exploration, VSATELIER for deliberation and action — form a progression from individual story creation to collective sense-making. Each layer adds capability; each also creates a corresponding need for skilled support. The core thesis of this page is that the scarce resource in this ecosystem is not the software but the capacity to help groups produce shared meaning from stories. The most coherent value chain is therefore: open platform, paid capability-building. The software remains freely accessible infrastructure; the revenue comes from helping organisations use it well. Two alternative models exist — a software-first enterprise chain and a hybrid — and a quantitative comparison follows below. This document argues for the services-first chain and explains why.
There are many ways to host media and collect narratives. What is rarer is the ability to help a group connect those narratives, interpret the resulting patterns, decide what they mean, and organise action around them. This is the interpretive and facilitative work that VSATLAS and VSATELIER are designed to support. If VSAT competes as software, it competes with generic publishing and content-management tools. If it is offered as a platform for collective interpretation and coordination, it occupies a distinctive space — one where the software is necessary but not sufficient.
Openness strengthens rather than undermines the service layer. Open infrastructure reduces fear of lock-in, makes pilots easier to start, and gives partners confidence that the work can outlast any one contract. A closed platform asks clients to trust both the technology and the vendor at once; an open platform lets the team sell expertise on top of an asset that is easier to inspect, adopt, and extend. The free layer should be genuinely usable on its own. The paid layer solves the problems that only appear once a group tries to use the system seriously.
The difficult work is not installation. It is framing the right pilot, designing link taxonomies, facilitating interpretation, training stewards, building governance, and evaluating what changed. These services correspond directly to the platform's layered architecture: VSAT generates story elicitation and pedagogic design work; VSATLAS generates taxonomy design and interpretive facilitation; VSATLATARIUM generates exhibition design and guided spatial analysis; VSATELIER generates governance, commitment design, and evaluation. The service layer deepens as the platform supports more demanding forms of collective practice.
Revenue should track organisational maturity, not platform usage. A group exploring the idea for the first time does not need the same thing as a university embedding VSAT in teaching, or a network of organisations comparing story worlds across sites. The offer should therefore be structured as a maturity ladder — from exploration through pilot, institutionalisation, and federation — with the paid component growing in scope as the organisation's practice grows in ambition. The likely buyers are not users in the consumer-software sense; they are universities, NGOs, museums, cultural programmes, public-sector teams, and research consortia — organisations buying from budgets for teaching innovation, programme delivery, evaluation, and funded research.
What is hardest to replicate in this model is not the code but the practice. Competitors can copy features faster than they can copy a credible approach to eliciting stories, linking them responsibly, facilitating deliberation, and helping organisations learn from the results. The team's advantage is not merely that it can write the software but that it can combine software, narrative practice, facilitation, organisational development, and research into a coherent offering. This is also why the model is not threatened by the platform being open: the harder the practice is to learn from documentation alone, the more valuable the support becomes.
If the core codebase, the linking infrastructure, and the documentation are not genuinely open at every stage, the model collapses back into ordinary software licensing while still carrying the costs of openness. The platform should be documented well enough to be trusted; the service offer should be packaged clearly enough that partners can see why they would still want help.
| Stage | Open / free | Paid | Typical buyer |
|---|---|---|---|
| Exploration | Platform access, examples, docs | Discovery conversations, pilot framing | Educators, small project leads |
| Pilot | Core platform for a bounded collection | Facilitation, interpretation, onboarding | NGO programmes, courses, cultural projects |
| Institutionalisation | Reusable practice, steward roles, governance | Training, governance design, evaluation | Universities, public bodies |
| Federation | Multiple installations working together | Network convening, shared standards, cross-site synthesis | Consortia, alliances, funders |
The progression matters because it turns "services" from a vague add-on into a path. Each stage names a recognisable moment in an organisation's relationship with the platform, and each names a kind of work that the organisation is unlikely to do well on its own without support.
| Service line | What the client gets |
|---|---|
| Pilot design | A scoped first use case: anthology, question set, workflow |
| Interpretation and facilitation | Workshops, guided analysis, discussion design, synthesis |
| Stewardship and governance | Review workflows, moderation rules, decision records |
| Capacity building | Training for contributors, curators, facilitators, stewards |
| Research and evaluation | Outcome documentation, case studies, impact narratives |
| Federation and network support | Cross-site protocols, shared standards, network convening |
Each line exists because the software does not by itself produce the corresponding outcome. A platform can host stories; it cannot connect them responsibly, facilitate deliberation about them, or build partner capacity to sustain the practice.
The argument above is qualitative. To make it inspectable in quantitative terms, the same structure can be expressed as a value-flow network: a directed graph of ten nodes representing where value is created, captured, distributed, and allowed to spill over. Three scenarios parameterise this graph differently. They are not separate models; they are different weightings of the same network, distinguished by which edges are strong, weak, or dormant.
In the services-first scenario, value percolates broadly through the network. The dominant flows run from the open platform through paid services into partner stewards, facilitators, and sustained installations, with strong downstream effects on community benefit and ecosystem spillover. The enterprise-offer node is present but dormant (dashed edges). In the software-first scenario, a few edges carry most of the flow: the dominant path runs from open platform through the enterprise offer directly to team revenue. Downstream edges to partner capability and public benefit thin out. The hybrid falls between these extremes, activating both channels at moderate strength.
Each edge in this graph is also an implicit warrant — a claim that value flows along that path under the given assumptions. A Bayesian prior predictive model tests whether those warrants hold under plausible uncertainty: Poisson priors on client volumes (how many engagements materialise), Gamma priors on flow weights (how strongly each link carries value). When propagated through the network, the three scenarios occupy distinct regions of the revenue-capability plane.
The model tracks four dimensions of value: central capture (revenue retained by the core team), partner capability formation (stewards, facilitators, and sustained installations at the client organisation — the capacity that remains when the engagement ends), network growth (federated links between installations), and public spillover (community benefit and broader ecosystem effects). The tradeoff is structural: no parameterisation in this model achieves both high central capture and high partner capability. The services-first model produces less revenue but distributes more value into the communities it serves. The software-first model reverses these priorities. The separation between the clouds is robust to the uncertainty in the priors — the structural difference is not an artefact of particular assumptions.
Four risks attend the services-first chain. First, consultancy without accumulation: if every engagement is bespoke, the team is trapped in labour-intensive delivery; the response is to standardise the service ladder and let each engagement improve the common infrastructure. Second, adoption without support: organisations self-host but never learn stewardship, and the platform appears weak when the failure is organisational; the response is to make the stewardship pathway explicit from the start. Third, open source without evidence: the claim of better collective sense-making is never documented, making renewal difficult; the response is to treat evaluation as part of the value chain, not decoration. Fourth, over-reliance on one team: if all expertise remains centralised, the platform does not become resilient; the response is to sell capability transfer as part of the offer.
The software-product value chain has not yet been written with equal explicitness. Until it has, the services-first chain is the only fully stated option. The prior predictive model is structured so that pilot observations can be conditioned on via posterior inference when real data arrives. The four derived dimensions — central capture, partner capability formation, network growth, public spillover — need testing with stakeholders to confirm they capture the distinctions that matter. The node and link semantics should converge with the pattern library, which already describes many of the same structures.