Service Builder

The platform already runs chains. That mechanism is entirely general: any sequence of platform services can be declared the same way. What is missing is a way for anyone outside the platform team to declare one.

The builder presents the available services as steps, each showing what it needs and what it produces, and lets the author connect them so that the output of one becomes the input or a parameter of the next. Because the orchestrator already validates these definitions, a chain that could not work cannot be drawn in the first place. Each parameter is either fixed by the author or left open to be supplied at launch, which is precisely the difference between a recipe that runs once and a service other people can use.

A finished chain is given a name, a description and an input form, and from that point it behaves like any other service: it appears in the catalogue, it runs through the orchestrator, it is subject to the same authorisation, and its results land in the same place. The author decides whether it stays private, is shared inside their organisation, or is offered to everyone.

The commercial consequence is worth stating plainly, because it is larger than the feature: this changes who is able to create supply. Today a new service means platform work. With a builder, a domain expert who knows their use case is “super-resolve, then detect burnt area, then publish” can assemble it, name it and offer it themselves. It also turns every existing service into a component, which makes the catalogue worth more than the sum of its entries.