thalabus thalabus

Hack Apertus submission

Track 2B · Apertus-powered prototype Luca Strozzi t2b

Welcome

This guide walks through the submission in the order its parts depend on each other: the model endpoint, this app's own graph store, the retrieval models, then the Docker Engine address you configured in .env — the same pair of variables the platform itself dials, and an unreachable address here explains more about a stuck deployment than any log line. Operations come last, and say plainly that they do not exist yet. Each step records what it observed, and a step cannot be marked done while its own test is still failing.

Plan Local

Plan Local deployment diagram: inside the hackathon environment the submission GUI calls thalabus, which holds this submission's own configuration, data and documents and reaches an embeddings service and a reranking service on the same machine; the AI models sit outside that environment and are called over the network.

"make run" might take up to one hour to configure and validate, in an untested and unconfigured host environment.

The app, the official platform images, an embeddings server and a reranker run on this machine, together with a graph store of this submission's own.

Plan SaaS

Plan SaaS deployment diagram: the hackathon environment holds only the submission GUI and this submission's local configuration in neo4j; thalabus, its data and documents, embeddings, reranking and the AI models all run in thalabus's own environment in the t2b private data center.

The app runs here against a thalabus platform instance you were given access to. The platform runs its own graph store, embeddings and reranking; this submission keeps its own store so the track's deliverable stays independent.