Project update - 13 October 2026
The current five-page report and a new prototype walkthrough document progress through 13 October. The public Apertus prototype continues to separate model proposals, deterministic control checks and human approval; this update adds evidence and documentation without changing its runtime.
- New prototype walkthrough (90 seconds): five real UI result views captured on 13 October demonstrate complete sources, missing facts, source conflicts, untrusted instructions and a protected-action gate. Model responses are explicitly labelled MOCK. This is an edited walkthrough of genuine UI screenshots, not a new live inference benchmark. Watch the prototype demo.
- New project overview (2 minutes 59 seconds): the main video above is the SPINNENNETZ-DNA overview created on 13 October. It explains the wider project and complements the separate prototype demonstration. Watch the new overview.
- Current report: Technical report, 13 October 2026 (PDF, five pages), covering architecture, measured results, reproduction steps, recent engineering progress and limitations.
Wider SPINNENNETZ-DNA engineering progress: a bounded worker recovery test resumed from a checkpoint without repeating the completed step (10-11 October). Selected tasks and notes were synchronized between HP and Samsung, with cross-device readback and file-hash checks (12 October). The documented task workflow now includes routine execution decisions, saved-result verification and continuity checkpoints. GitHub Desktop authentication and a repository fetch were independently verified on 13 October; a separate older diagnostic worker's timeout remains recorded as a failure.
These are scoped, maintainer-verified results from the separate private integration environment. They do not add Office, email, printer or desktop execution tools to the public Apertus prototype. The five published live CSCS Apertus cases remain the historical evaluation from 3 October. Production reliability, unrestricted autonomy, 24/7 availability, remote wake, an independently deployed customer installation and measured business savings remain unproven.
Submission status: the official Hack Apertus website confirmed “Submission received” on 13 October. That entry includes the five-page report, 90-second prototype demo, repository and interactive demo. This public project update is not a new competition submission or a jury decision.
Open the interactive prototype | Browse the public source
Inspiration
Businesses increasingly use generative AI for emails, documents and decisions, but fluent output is not the same as trustworthy execution. Real workflows contain missing information, conflicting sources, embedded instructions and actions that should never be authorized by the model itself.
We wanted to show a practical pattern for using an open Swiss model while keeping control, evidence and human responsibility outside the model.
What it does
The prototype follows this chain:
Request → Apertus → structured facts → deterministic control checks → human gate → readback → VERIFIED / HUMAN_REVIEW / BLOCKED
Apertus handles semantic analysis and response preparation. A separate deterministic layer checks for:
- conflicting facts;
- missing required information;
- untrusted instructions embedded in source documents;
- protected external actions such as sending email, payments, purchases, contracts, permission changes or destructive operations.
The model can propose an action but cannot authorize it.
How we built it
- standalone Python 3.11 service;
- OpenAI-compatible Apertus client;
- structured model-output schema with source IDs;
- deterministic post-model control layer;
- browser demo and CLI;
- Dockerfile;
- automated unit tests;
- SHA-256 evidence for workflow inputs;
- clean-room boundary that excludes private SPINNENNETZ-DNA code and data;
- live-request evidence runner that never records the API key.
Evaluation
Five deterministic scenarios are implemented and passing:
- complete sources → VERIFIED
- missing fact → HUMAN_REVIEW
- conflicting sources → HUMAN_REVIEW
- embedded untrusted instruction → BLOCKED
- protected external action → HUMAN_REVIEW
These tests validate the control layer independently of the language model.
Why Apertus
Apertus gives the project an open Swiss model foundation and a credible path to sovereign deployment. The application logic and safety boundary remain inspectable instead of relying on a closed provider or a hidden prompt to enforce business policy.
Track 2B fit
Purposeful AI use: language understanding is used where it adds value; authorization is kept deterministic.
Technical rigour: structured schema, source attribution, explicit states, automated tests, input hashes and independent controls.
Value, cost & scalability: the pattern targets repetitive document/office workflows and can use Apertus 8B for a lower-resource path.
Sovereign deployability: open-source code, open model path, synthetic public demo data and no dependency on private internal infrastructure.
Implementation feasibility: public repository, hosted browser demo, CLI, Dockerfile and prepared live inference integration.
Current public evidence
Repository: https://github.com/ambrosinistefan8-stack/apertus-sovereign-operations-bridge
Demo: https://apertus-sovereign-operations-bridge.onrender.com
Control tests: PASS
Historical live Apertus evaluation (3 October 2026): VERIFIED
Authorized hosted inference was verified against the CSCS OpenAI-compatible endpoint with swiss-ai/Apertus-v1.5-70B. On 3 October 2026, the project completed the full HP → public demo → CSCS → deterministic control readback path. Five out of five expected control outcomes passed with HTTP 200 responses:
- complete sources → VERIFIED
- missing fact → HUMAN_REVIEW
- conflicting sources → HUMAN_REVIEW
- embedded untrusted instruction → BLOCKED
- protected external action → HUMAN_REVIEW
No protected external action was executed. The model proposes; the control layer decides whether the result may proceed, requires human review, or must be blocked.
Public live evidence: https://github.com/ambrosinistefan8-stack/apertus-sovereign-operations-bridge/blob/587522e1da34e5de17d40cde80dcb30cdf4ec72e/evidence/live-cscs-20261003.json
What we learned
The hardest problem is not getting an LLM to write a plausible answer. The harder problem is defining what must happen between a model answer and a real-world action. Separating semantic generation from authorization makes failures visible and testable.
Engineering update - 8 October 2026
The wider SPINNENNETZ-DNA development environment now provides additional, bounded execution evidence:
- Phone-to-PC communication: a phone ChatGPT request reached the HP worker and its result was read back; communication was checked again after the phone session restarted.
- Physical output: one PC-initiated and one phone-initiated single-page print completed. The owner confirmed receiving both pages. Rechecking the second job did not submit another print.
- Native Office workflows: five phone-initiated jobs passed: create a Word document, append text into a new Word copy, create an Excel workbook, change cells in a new Excel copy, and create a PowerPoint presentation. Each output was saved, reopened in its native application, and checked. The two source documents remained unchanged.
- Bounded execution: these five Office jobs used existing direct worker actions without invoking a coding agent. Receipts, content readback and file hashes were checked; the actions do not provide unrestricted desktop control.
These are maintainer-verified results from a separate private integration environment. They support the engineering pattern of explicit user intent, bounded execution and target-state verification. They are not evidence that Apertus or the public demo controls Microsoft Office or a printer. The public clean-room prototype and its five published live Apertus scenarios remain independently reproducible and separate from this integration work.
General mission recovery, automatic cross-system handoff, closed-lid operation and remote wake remain unverified. The public prototype does not execute protected external actions. Cost/scaling benchmarks, the 8B/70B comparison and a fully self-hosted Swiss deployment remain future work.
Engineering update - 9 October 2026: Business Platform work packages 1–5
The separate SPINNENNETZ-DNA integration environment has completed a bounded local pilot covering business output, packaging and a standards-based tool interface. The existing HP bridge and Office execution core were reused.
- Business document workflow: a confirmed text/business brief can produce native Word, Excel and PowerPoint files, PDFs and an unsent Outlook draft. Files were saved, reopened and checked. This is an execution path from an approved brief; Samsung microphone capture, speech recognition and an unrestricted voice agent were not verified.
- Measured business pilot: the synthetic training case produced all seven requested outputs. Elapsed time to the first checked cloud completion was 548.396 seconds. This is one bounded automated run; setup and later independent review are outside that interval. No manual comparison run was measured, so no time saving, cost saving or ROI is claimed. A separate editable business presentation and PDF were also completed.
- Adaptive Connect and Deploy Bridge: local capability checks, installation planning, versioned installation, configuration, rollback and uninstallation were exercised in an isolated directory on the existing computer. A further native Office workflow passed, and customer/test output files were preserved during removal. No second computer was available, so independent customer operation without the original HP remains unproven.
- Customer Agent 0.2.1: the local prototype adds pinned action grants, package/source hashes, persistent replay protection, audit records, stop/revocation and controlled lifecycle operations. Its original transport is encrypted local loopback. Native Office execution evidence belongs to the earlier 0.2.0 run; the Office core remained unchanged in 0.2.1. This is not a verified remote, multi-tenant or unattended Windows-service deployment.
- OpenAI integration preparation: a minimal adapter 0.1.0 exposes five fixed MCP tools through the official MCP project's Python SDK while retaining the existing DNA authorization core. The combined suite passed 55/55 tests. A real SDK client and separate stdio server process exercised initialization, tool discovery, status/probe/plan, authorized package verification, installation, uninstallation, data preservation and rejection of invalid requests, replay after restart and calls after stop. The new MCP run did not generate Office files; its Office catalog dispatch was tested with a unit-test fixture. Local stdio relies on operating-system/process boundaries and does not itself add remote authentication or transport encryption.
A separate read-only package/code review confirmed the delivered archive and manifest hashes, checked that the existing core files were unchanged, and found no critical authorization issue in that limited review. One minor audit-write error-handling robustness finding is recorded for later hardening. These are maintainer-reported results from the private integration environment, not a security certification or new publicly reproducible Apertus benchmarks. Test enrollments were revoked and test keys removed after the run.
Architecture and next steps: use existing OpenAI interfaces where suitable rather than building a new remote-control system. MCP is the chosen interface for tightly scoped business tools. The documented Secure MCP Tunnel is a candidate for later authorized private access; Agents API with codex exec-server is a separate candidate for approved development sandboxes. Their account eligibility, operating-system support, customer permissions, data scope and budget still require verification. No tunnel, remote executor session or additional paid model-API request was started, and no new subscription was purchased for these tests.
Scope of this update: the public clean-room Apertus prototype and its published five-case live evidence remain separate. Apertus was not used in today's business/MCP runs, and this update does not claim that the public demo now operates Office or installs customer software. Overall platform status remains PARTIAL / NOT_PRODUCTION. Voice capture, remote customer access, operation independent of the HP, general recovery/wake behaviour and measured economic benefit remain open. The earlier public report, repository and demo links below retain their original scope; private code, credentials and internal documents are not published by this update.
What's next for Apertus Sovereign Operations Bridge
Next steps are to benchmark Apertus 8B and 70B for different workload/cost profiles, add more synthetic SME workflows, strengthen source-level evaluation, and test a fully self-hosted Swiss deployment path.
The goal is not unrestricted autonomy. The goal is a reusable pattern for controlled autonomy with evidence and human responsibility.
Technical report and judge package
Technical report (13 October 2026, PDF, five pages)
Track 2B source and Docker/Make instructions
The judge package accepts the official LLM_NAME, LLM_BASE_URL and LLM_API_KEY settings. The Docker build, launch through make run, and five explicit mock/control HTTP scenarios passed on 8 October: verification run. This packaging check is separate from the published live Apertus evidence.
Additional explainer: SPINNENNETZ-DNA
So funktioniert SPINNENNETZ-DNA – Architektur und geprüfter Ablauf
German narrated, animated explanation (2 minutes 26 seconds) of the broader SPINNENNETZ-DNA architecture, the documented phone-to-HP test workflow, user approval and result verification. This is an explanatory animation, not a live screen recording or an additional execution test. It distinguishes demonstrated workflows from open capabilities. The new 2-minute-59-second overview from 13 October is the main video above; the separate 90-second prototype walkthrough is linked in the current update.
Log in or sign up for Devpost to join the conversation.