Data Engineering
Connect data sources, version datasets, verify quality and produce reusable features.
Orthevs Engineering Lab · AMEL
AI systems as a manageable engineering product.
The AI & ML Engineering Lab brings data, models, experiments, deployments and governance together into a reproducible lifecycle. It is the domain Control Plane between an AI idea and dependable operations.
Documented target state · Concept / Architecture Baseline
AI / ML Lifecycle
Input
DataRequirementsHypotheses
Orthevs Lab
AMEL
Control Plane
Outcome
ModelsEndpointsEvidence
Monitoring, drift and controlled retraining
Domain application · target architecture
Independent engineering environment
The Lab is designed as a complete domain application with a workspace, editors, models and SDK-like interfaces. Its Factories are the specialist tools; Engines handle processing and execution. Shared Contracts connect it with other Labs.
Develop and evaluate data, algorithms, models, experiments and inference architectures.
From Engineering Contract to verifiable outcome
- 01
Contract & Foundation
Requirements and rules select the domain foundation.
- 02
Lab Workspace
Models, editors and tools address the domain problem.
- 03
Factory & Engine
Specialist tools create artifacts and use suitable execution mechanisms.
- 04
Validation & Product
Tests, evidence and approvals lead to a versioned outcome.
The workflows and capabilities shown describe the documented target model. Check availability and maturity for each release and capability.
Mission and ambition
From individual ML tools to an end-to-end engineering system.
AI and ML initiatives rarely fail for lack of an algorithm alone. The hard work lies in the transitions: data must be discoverable and permissible, experiments must remain reproducible, and models must be evaluated transparently, packaged securely, released under control and observed in operation. AMEL turns exactly these transitions into explicit, verifiable workflows.
AMEL does not replace established frameworks, training runtimes or cloud services. The Lab adds a domain control layer on top: it describes resources, coordinates jobs and workflows, manages Factory capabilities and keeps references to artifacts, states and evidence together. Providers and backends are connected through adapters so that domain processes remain portable.
The result is not a single “AI tool” but an extensible operating and development model. Teams can start with a small dataset-to-model pipeline and later extend the same contracts with serving, monitoring, generative AI, agents or governance.
Capability map
Eight domains cover the complete AI/ML lifecycle.
The domains organize responsibility, not tool names. Each capability is intended to be versioned independently and combined into workflows through standardized contracts.
Model Engineering
Design algorithms and architectures, combine and optimize model components, and register approved versions.
Training & Research
Handle training runs, experiments, search spaces, benchmarks and research questions reproducibly.
Generative AI & LLM
Treat LLMs, prompts, retrieval, agents and multimodal systems as testable engineering artifacts.
Deployment & Operations
Package models, run inference, operate endpoints, monitor behavior and govern lifecycle decisions.
Quality, Security & Governance
Bring together quality, robustness, explainability, security risks, approvals and evidence.
Automation & Integration
Turn capabilities into pipelines and approval-gated workflows, and integrate existing systems.
Advanced AI Engineering
Support reinforcement learning and federated learning with their specific runtime, simulation and data protection requirements.
Use cases
AMEL starts with the concrete engineering problem.
The following scenarios show how the Factory capabilities can be combined into domain workflows. They describe the target state, not a product feature that is already committed.
01Model Development
Reproducible model development
A team turns raw data into a versioned training foundation, documents architecture and parameters, and compares runs under the same evaluation rules. A promising experiment only becomes a model version once data provenance, runtime environment, metrics and checkpoints are traceably linked.
- Dataset and feature versions
- Training and experiment runs
- Evaluation and model registry
02Production ML
From approved model to monitored endpoint
An approved model version is packaged with its dependencies and integrity evidence, deployed as batch or online inference, and operated under defined rollout and fallback rules. Monitoring links latency, resources, quality and drift to a controlled lifecycle decision.
- Signed model packages
- Canary, rollback and traffic management
- Drift and quality feedback
03Enterprise GenAI
RAG applications with a verifiable knowledge base
Document sources are ingested, chunked, embedded and indexed under control. Prompts, retrieval strategies and reranking are tested in versioned form; evaluation separates answer quality, source grounding and undesired behavior. This keeps a RAG application comparable even after data or model changes.
- Versioned sources and indexes
- Prompt and retrieval tests
- Quality and security gates
04Agentic Systems
Controlled agents and tool use
Agents receive only explicitly permitted tools and short-lived, purpose-bound identities. Planning, tool calls, results and approvals are treated as traceable runs. Cross-lab actions are never executed directly; they go through capability discovery, policy checks and the target lab's API.
- Tool allowlisting and scopes
- Human-in-the-loop approvals
- End-to-end audit trail
05Governed AI
Evidence-backed AI for sensitive contexts
Model Cards, data provenance, test results, risk classification and approval decisions are bundled along a model version. Business and technical reviewers can see which data, tests, policies and accountable owners led to an approval, and which conditions apply to continued operation.
- Evidence and Model Cards
- Explainability and robustness
- Review and approval gates
06Private & Distributed AI
Learning across distributed or protected data spaces
Where data must not leave a site or an organization, AMEL can coordinate federated training workflows, aggregation and site-specific policies. Dedicated worker or GPU pools, separate permissions and explicit artifact flows form the technical boundary.
- Multi-site training
- Isolated compute contexts
- Controlled aggregation
End-to-end lifecycle
Every handover becomes a verifiable contract.
AMEL coordinates more than happy-path execution. States, errors, retries, approvals, artifacts and responsibilities are part of the domain workflow.
- 01Discover
Problem and context
Define the goal, users, risks, acceptance criteria and permissible data sources.
- 02Acquire
Ingest data
Connect sources, classify data and create an immutable dataset version.
- 03Design
Design the solution
Version the algorithm, architecture, features, runtime and evaluation strategy.
- 04Train
Execute runs
Launch isolated jobs with seeds, parameters, code digest, compute profile and checkpoints.
- 05Evaluate
Demonstrate quality
Assess metrics, robustness, security, explainability and domain-specific criteria.
- 06Approve
Decide on release
Bring evidence, risks, Model Card and responsibilities together in a single gate.
- 07Deliver
Package and sign
Ship model, dependencies, configuration and provenance as a verifiable bundle.
- 08Operate
Run serving
Manage batch or online inference with limits, rollout, routing, observability and rollback.
- 09Evolve
Observe and improve
Drift, quality degradation, costs or new requirements trigger controlled changes.
Closed feedback loop
Monitoring does not end the lifecycle. Operational signals are correlated with dataset, model and deployment versions and can trigger a reviewed new training or approval cycle.
Reference architecture
Autonomous in its domain. Clearly connected to the platform.
The domain application boundary lies with the Lab. Factories provide well-defined capabilities and, depending on requirements, can be implemented as a plugin, package, service or adapter.
Orthevs Platform
Identity & IAM · Lab and Capability Registry · Secrets · Policy · Audit · Event Bus · Resource Management
AMEL domain application
Workbench / BFF · versioned AMEL API · Core · Factory Manager · job and workflow coordination · metadata and artifact references
Factory capabilities
Planned providers with manifest, lifecycle, permissions, typed inputs and outputs, health and optional UI extension points
Runtime & Infrastructure
In-process plugin · isolated worker · container/Kubernetes job · distributed GPU workers · external backend adapters · object storage
API-first
Workbench, clients and other labs access AMEL exclusively through versioned APIs, events and capability contracts.
Asynchronous where needed
Training, pipelines and deployments return job resources with status, attempts, errors, retries and a correlation ID.
Adapters, not lock-in
Compute, storage, frameworks and external services remain interchangeable as long as their capabilities fulfill the contract.
No hidden coupling
Other labs never access the AMEL database, internal plugin state or file systems directly.
Factory Contract
Extensibility requires binding ground rules.
A Factory only qualifies as an integrable AMEL capability once it describes not just its functions, but also its operation, security and compatibility.
Identity & Manifest
ID, name, version, type, maintainer, license and trust origin.
Lifecycle
Install, initialize, start, stop, upgrade, uninstall, as well as health and readiness.
Capability & API
Versioned operations, error codes, timeouts, idempotency and compatibility.
Artifacts
Typed inputs and outputs, schemas, checksums, versions and provenance.
Execution
Runtime, CPU, RAM, GPU, storage, job model, scaling and resource limits.
Security
Permissions, secret scopes, network access, isolation and audit events.
Observability
Logs, metrics, traces, job status, health and shared correlation IDs.
Frontend
UI extension points, routes, permissions and supported AMEL versions.
Dependencies
Required lab, platform and backend versions, as well as other capabilities.
Data, models and Evidence
Lineage turns a model into an explainable result.
A model version is more than a weights file. AMEL links it to the dataset version used, the algorithm and architecture specification, the specific training run, code or container digests, parameters, seeds, compute profiles, metrics, evaluation reports and the approved deployment package.
Large datasets and model weights are kept outside the relational metadata store, in suitable artifact or object stores. AMEL keeps referenced, integrity-verified metadata and access rules together. This allows storage backends to change without a resource losing its domain identity.
DatasetVersionAlgorithmVersionArchitectureSpecCode / Image DigestParameters & SeedsCompute Profile
Traceable ResourceModelVersionimmutable identity
EvaluationReportModel CardPackage & SignatureDeploymentMonitoring Signals
Security, governance and operations
Trust is built across the entire system.
AI-specific risks are tied to platform controls, isolated execution and domain approvals. Governance is an executable part of the lifecycle, not a document at the end.
Data and artifacts
Classification, purpose limitation, retention, deletion and controlled exports protect sensitive or license-bound content.
- No secrets in manifests, logs or artifacts
- Checksums, signatures and provenance
- Separation of training and evaluation data
Execution and identities
Every job and every capability operates with least privilege, bounded resources and explicit network access.
- Short-lived credentials and secret injection
- Unprivileged containers and isolated workers
- Scopes per lab, Factory, project and action
Quality and AI security
Beyond domain quality, evaluation also covers robustness, supply chain and undesired system behavior.
- Prompt injection and tool abuse
- Data exfiltration and leakage
- Model, dataset and dependency risks
Decisions and Evidence
Approvals connect technical review results with ownership, risk acceptance and operating conditions.
- Model Cards and risk classification
- Auditable approval and policy outcomes
- Rollback plan and named accountable owners
Interplay within the Orthevs system
AMEL uses other labs through approved capabilities.
Cross-lab collaboration does not mean direct access. A request is discovered, authorized, handed over as a job and traceably returned via status or events.
AMEL Factory→AMEL API→Capability Registry→Identity & Policy→Target Lab API→Job & Event
Platform Engineering
Golden paths, cluster and runtime offerings can provide reproducible execution environments for AMEL workloads.
Infrastructure Engineering
Compute, storage, network and accelerator resources are connected through controlled infrastructure capabilities.
Operating System Engineering
Validated images, hardening profiles and fleet states form the system foundation for workers and appliances.
Security Engineering
Threat modeling, findings, controls, evidence and response complement AI-specific security reviews.
Blockchain Engineering
Verifiable provenance, signature or governance models can be integrated as a capability for suitable use cases.
Roadmap target state
Contracts and a Vertical Slice first. Then breadth and scale.
The phases describe the domain development sequence of the architecture concept. They are deliberately presented without binding delivery dates.
-
Phase 0Foundation
Architecture and platform foundations
Lab boundaries, Factory manifest, lifecycle, job model, API, event and artifact contracts, as well as IAM, secrets, policy, registry, threat model and foundational ADRs, become binding.
Outcome: testable contracts and a robust security foundation. -
Phase 1Engineering
First AI/ML engineering pipeline
Dataset, Algorithmic, Model Architecture, Training, Experimentation and Model Registry form an end-to-end dataset-to-model Vertical Slice.
Outcome: a reproducible Run with a registered model version and lineage. -
Phase 2Production
Production Readiness
Pipeline, Data Quality, Evaluation, Packaging, Serving and Monitoring extend the Vertical Slice with approvals, rollout, operations, recovery and quality feedback.
Outcome: a monitored endpoint with rollback and operational evidence. -
Phase 3Generative AI
LLM, RAG and agent engineering
LLM, Prompt Engineering, RAG, Agent and Multimodal are integrated with evaluation, security, tool approvals and controlled knowledge sources.
Outcome: traceable generative applications instead of unversioned prompts. -
Phase 4Enterprise
Advanced AI and organization-wide operations
Remaining specializations, federated learning, reinforcement learning, cross-lab integration, tenant isolation, scalable workers and advanced governance follow.
Outcome: an extensible AI engineering system for different operating models.
MVP scenario
Project → Dataset → Training → registered model
A user creates a project context, imports a dataset, defines a simple training configuration, launches an isolated job, follows logs and metrics, and registers the resulting model together with its lineage. The path is only considered complete once permissions, contracts, error handling, lifecycle and recovery are documented and tested.
Deliberate boundaries
What the first stage explicitly does not promise.
A credible roadmap names non-goals alongside goals. This protects AMEL from becoming a broad but unintegrated tool catalog.
- Not all 32 Factories will be implemented at once; priority goes to a small, complete end-to-end path.
- Factories deliver capabilities for AMEL and can be realized as a plugin, package, service or adapter within defined contracts.
- AMEL does not build its own alternatives to established ML frameworks, runtimes or storage systems where adapters suffice.
- The frontend does not hard-wire Factory functions; instead it loads approved extensions through versioned UI contracts.
- Research functions do not reach production-critical services without evaluation, security gates and named accountable owners.
- Concrete SLIs, SLOs, throughput, GPU, RPO/RTO and cost targets will only be set bindingly together with the respective operating profiles.
AMEL Factory Portfolio
32 capabilities across 8 domains.
Each Factory has its own detail page covering responsibility, use cases, artifacts and contract. The catalog represents the Lab's planned capability map.
Advanced AI Engineering
2 FactoriesAutomation & Integration
3 FactoriesIntegration Factory
Integration adapters across frameworks, SDKs, services, and Labs.
Open detail page ↗Pipeline Factory
Define AI and ML pipelines, DAGs, dependencies, restart behavior, and artifact flows.
Open detail page ↗Workflow Automation Factory
Schedules, event triggers, approval steps, and automation rules.
Open detail page ↗Data Engineering
4 FactoriesData Ingestion Factory
Connect databases, APIs, files, streams, and object storage as batch or streaming data sources.
Open detail page ↗Data Quality Factory
Data profiling, validation, schema checks, duplicates, missing values, and quality rules.
Open detail page ↗Dataset Factory
Create, import, clean, label, augment, and version structured, multimodal, and synthetic datasets.
Open detail page ↗Feature Engineering Factory
Feature extraction, transformation, selection, and integration with feature stores.
Open detail page ↗Deployment & Operations
5 FactoriesAI Monitoring Factory
Monitor drift, quality, latency, resources, token consumption, and costs.
Open detail page ↗Inference Factory
Batch and online inference, inference engines, hardware optimization, and batching.
Open detail page ↗Model Lifecycle Factory
Orchestrate promotion, approvals, retirement, rollback, and retraining triggers.
Open detail page ↗Model Packaging Factory
Runtime bundles, container images, dependencies, model packages, and signatures.
Open detail page ↗Model Serving Factory
API endpoints, rollouts, autoscaling, canary releases, rollback, and traffic routing.
Open detail page ↗Generative AI & LLM Engineering
5 FactoriesAgent Factory
Agents, tool use, memory, planning and execution mechanisms, and controlled agent workflows.
Open detail page ↗LLM Factory
LLM integration, configuration, adaptation, and fine-tuning recipes.
Open detail page ↗Multimodal Factory
Text, image, audio, video, and combined multimodal applications.
Open detail page ↗Prompt Engineering Factory
Prompt templates, versioning, tests, and prompt optimization.
Open detail page ↗RAG Factory
Chunking, embeddings, indexing, retrieval, reranking, and RAG evaluation.
Open detail page ↗Model Engineering
5 FactoriesAlgorithmic Factory
Develop and maintain algorithms, learning methods, loss functions, optimizers, and specialized methods.
Open detail page ↗Model Architecture Factory
Design and configure CNN, Transformer, GNN, and hybrid architectures.
Open detail page ↗Model Assembly Factory
Compose model components, layers, encoders and decoders, and pre- and post-processing.
Open detail page ↗Model Optimization Factory
Quantization, pruning, distillation, sparsity, and performance optimization.
Open detail page ↗Model Registry Factory
Manage versioned models, artifacts, provenance, metadata, and approval states.
Open detail page ↗Quality, Security & Governance
4 FactoriesAI Governance Factory
Model cards, approval processes, compliance evidence, risks, and policy controls.
Open detail page ↗AI Security Factory
Adversarial testing, prompt injection, model and artifact scanning, and AI supply-chain security.
Open detail page ↗Explainability Factory
Explainability, feature attribution, interpretability, and justification of results.
Open detail page ↗Model Evaluation Factory
Quality, robustness, benchmarks, regression, and domain-specific evaluations.
Open detail page ↗Training & Research
4 FactoriesExperimentation Factory
Track runs, parameters, metrics, outcomes, artifacts, and reproducibility.
Open detail page ↗Hyperparameter Factory
HPO, grid and random search, Bayesian optimization, and AutoML search strategies.
Open detail page ↗Research Factory
Research projects, hypotheses, benchmarks, paper reproductions, and prototyping.
Open detail page ↗Training Factory
Training, fine-tuning, distributed training, checkpoints, and hardware and runtime profiles.
Open detail page ↗Shape AMEL together
Which AI/ML lifecycle should become dependable first?
Whether dataset-to-model, RAG, model serving or governance: the most sensible starting point is a clearly scoped Vertical Slice with real artifacts, measurable gates and documented operations.