Open technical documentation

Revision 0.3 · 7 October 2026 · Architecture and implementation boundaries.

1. Start here

Vantemio connects software orchestration, AI components, production tools and result validation. Station is the canonical core. Studio is the video-production application. Vantemio Market develops the connection between digital services, orders and delivery.

This document describes responsibilities and integration rules. It is not a reference for a live public API, which remains planned. Examples are conceptual rather than actual endpoints or internal database fields.

2. Responsibilities

The sequence is request → Station → admission → executor → result → review → accepted version. Memory and graph connect these stages; they do not replace execution. The next integration under investigation is accepted version → test commerce workflow.

3. Task identity

Integrations must preserve stable request identity, source version, execution authority, executor and result linkage. A routing change does not rewrite the original source owner or erase history.

Conceptually, request A refers to input version B; admission C permits executor D to perform bounded work; result E links to A–D and review F. Repeating request A requires reconciling existing execution and results, not automatically creating another operation.

Existing memory versions small control files and their hashes. This does not attest to all media or transitive dependencies. Each integration scenario needs explicit coverage.

4. Admission and state

Execution requires an acceptable schema, valid input version, authority, executor readiness, resource budget and reconciliation of outstanding assignments. Installed models, registered nodes and ready executors are distinct states.

Reader-facing states may be described as received, checking, admitted, running, result received, quality review, accepted, repair required and outcome unknown. These are explanatory labels, not a claim about an existing enum.

Outcome unknown matters: a timeout does not prove failure. Until the actual outcome is established, the side effect must not be repeated.

5. Recovery without replay

After an interruption, reconcile the process, assignment, resource claim, saved response and actual artifact. Reuse completed results after validation. Transfer unfinished work through a recorded authority handoff while retaining original identity.

An expired heartbeat does not automatically release a claim. Restarting a client does not authorize republication, rendering again or another transaction. Uncertain outcomes must remain explicitly uncertain.

These are required architectural rules. Their complete implementation is verified separately for each chain; this document does not assert coverage of every possible failure.

6. Memory and technical graph

Existing memory stores observations protected against modification, versions and dependency relationships. Repeating an identical snapshot should not invent history, while an A-to-B-to-A change remains visible.

The graph links materials, stages and results. Candidate lessons link to supporting observations and require review before becoming release rules. Reusing context is not model-weight training.

A snapshot does not prove every execution. Missing history cannot be inferred into existence. Technical readiness does not establish artistic acceptance.

7. AI and tools

Station coordinates local and cloud requests. Models must return results that meet task contracts. Response structure, media references and permitted actions are checked before execution. A plausible response with an invalid schema remains an error.

Qwen-class 27B planning has recorded usage examples. Book Coder 7B is a bounded helper. Other specialists need separate labels for configuration, verified readiness and a recorded task result; these must not collapse into one blanket “working” status.

Remotion/JavaScript and Blender serve graphics and composition roles; the editing path includes Vidra/MLT. Naming a tool establishes its architectural role, not universal support or quality. Each supported scenario needs evidence. Development tools are not the production core.

8. Compute expansion

The fleet is not architecturally limited to the three currently known machines. New nodes enter the existing Station registry after stable identity, capability and resource checks. Identity collisions are rejected and registration revisions retained.

Assignments consider current readiness and outstanding claims. Large registry views need pagination. Observing a node does not start a worker or activate a queue. Synthetic scale tests establish mechanism behaviour, not the existence of equivalent connected hardware.

9. Results and quality

Technical validation concerns integrity, version, timing and suitability for the next stage. Content review concerns scene meaning, continuity and task fit. Artistic judgment remains a separate dimension.

Repairs must reference a defect and a new version. Updating a status cannot substitute for correcting a failed output. Integration evidence must cover the actual caller, admission, executor, result consumer, recovery, failure path and peer compatibility.

10. Base/Boson and data boundaries

Test commerce uses Base Sepolia. An accepted version, its identifiers and applicable terms must remain consistent between production and commerce. Repeated events, uncertain transaction outcomes and network-state changes require reconciliation before further operations.

A hash supports version comparison but does not establish rights. Public chain data must not contain private media, secrets or internal logs. Commercial release requires separate access, delivery and review conditions.

11. Public materials and feedback

Start with the Vantemio repository. It publishes bounded modules and infrastructure excerpts rather than the private engine. Use the README of the specific published module for setup instructions and record its revision.

Useful reports include the version, scenario, expected behaviour and a sanitized result. Do not post secrets or private materials in public discussions. Contact: support@vantemio.com.

12. Expansion beyond Studio

Studio is the first module of a general automation engine. Capability registration, invocation contracts, memory and result accounting can support other domains. This is an architectural opportunity; each concrete adapter still needs implementation and verification.

New-module contract

A module declares versioned inputs and outputs, permissions, resource budget, permitted side effects and success criteria. Calls preserve original task identity and prior-result references. Before repeating publication, payment or a CRM update, the system reconciles the external service's actual state.

A generic model call is not an integration module. Each connector needs checks for revoked access, expired credentials, partial responses, duplicate events and cancellation. Autonomy is defined by permitted actions and accountable results.

Example future workflow

Brand brief → campaign plan → Studio assets → review → approved publication → metrics → next-variant recommendation → CRM task. Each transition carries data versions and an accountable executor. This is an expansion target, not a claimed operational end-to-end integration.