In development — strength platform

A training platform for coaches and professional athletes.

This is what Veliard is building: a strength-progression platform for coaches running a roster and for athletes whose season depends on what the log says. Beside it we run one consulting practice, deliberately narrow — classification and qualification of software tools and toolchains for automotive teams working to ISO 26262.

See what we are building Talk to an engineer

Mobile, tablet, web · no release date announced · consulting: ISO 26262-8 clause 11, tools and toolchains

Platform — nobody is watchingTool qualification — read by an assessor

Illustrative trace — shape only. The same discipline under two enforcement regimes.

01Platform

One append-only log, everything else derived.

In active development · built in-house · no release date announced

Three surfaces on one data model: a phone app for logging sessions under the bar, a tablet interface for coaching on the gym floor, and a web console where a coach manages programmes across a roster.

The hard part is not the interface. Training data arrives incomplete and inconsistent — substituted exercises, partial sets, deloads, weeks that never happened — and a progression model is only as good as the structure underneath it. The effort goes into an exercise ontology that survives renaming and equipment variance, and an append-only session log that lets us recompute an athlete’s history when a model changes instead of migrating it destructively.

For a coach that means volume, intensity and progression are derived from the log rather than typed into a spreadsheet — and a change to how a metric is defined applies to four years of history the day it ships.

Surfaces

Mobile

Session logging under the bar. Offline-first, sub-second entry.

Tablet

Coaching view for the gym floor: today’s roster, live adjustments.

Web

Programme design and roster management across an athlete base.

Fig. 01.1 — Derived progression · one athlete · 104 weeksSweeping

Peak e1RM

—

Gain, 104 weeks

—

Sessions counted

—

Weeks excluded

—

e1RM formula

Partial sets

Planned deloads

Synthetic log, not athlete data — but the recomputation is real. Every control above is a definition change, and the whole history is derived again from the same append-only sessions. That is the point of the data model: nothing above was migrated to make it move.

02Tool qualification

Confidence in the tools your safety case rests on.

We support with ISO 26262-8:11 — tool classification, tool qualification, and toolchain analysis for automotive software tooling.

That is the whole scope. We do not run process assessments, audits or SPICE work, and we say so before you ask.

02.1

Toolchain analysis

Automotive software gets built through long, multi-stage toolchains — compilers, generators, analysers, test and build tools chained together — and it is usually the chain that matters, not any single tool or step in it. We help teams build a structured view of that chain: what each tool does, where it sits, what it hands to the next step. That view is what makes classification and qualification, where either is actually needed, tractable rather than guesswork.

Chain mapping
Toolchain view

02.2

Tool classification

We help teams classify a tool from where it actually sits in the chain — its use cases, and how it interacts with the tools around it — rather than from the tool taken on its own. Argued that way, the classification asks for fewer additional measures than an isolated assessment would: understanding the surrounding picture does some of the work that extra qualification would otherwise have to cover.

TCL determination
Use-case scope

02.3

Tool qualification

The size of the qualification a tool needs depends heavily on its use case, and on where it sits and interacts with the other tools around it. That is what lets us help teams narrow it down significantly — directing the necessary qualification effort only at what is genuinely important, not the tool in isolation.

Scope narrowing
Tool validation

02.4

Qualification evidence

If a tool comes already qualified, we advise on whether that qualification fits its use case in the specific toolchain at hand, and whether it is actually sufficient — rather than taking it at face value.

Qualification report
Validation suite

03Approach

The same discipline, with and without an assessor.

Both lines sit in one company because we do not run two standards. Nobody audits the platform. A tool qualification argument is read by an assessor whose job is to find what is wrong with it. The habits are identical; only the enforcement differs.

03.1

Written down, or it does not exist

Requirements, interfaces and the reasoning behind a decision live in the repository, not in a conversation someone remembers differently.

03.2

Evidence is generated, not assembled

Traceability and test results come out of the pipeline. Anything reconstructed by hand the week before a review is not evidence.

03.3

Reviewed by someone who did not write it

No single-author merges, in either line of work. The reviewer is the first person who has to understand the code without help.

03.4

Said plainly

If the evidence does not support a claim, we say so while it can still be fixed — not after an assessor finds it.

Veliard is registered in and operates from Limassol, Cyprus. Contracting, data protection and IP arrangements sit inside the EU framework European automotive clients already work with, and our working day falls almost entirely inside theirs.

04Contact

Talk to an engineer.

Tell us what you are working on and where it currently stands. The first reply comes from someone who will do the work, not from a sales desk. If we are not the right fit, we will say so.

Or write directly
contact@veliard.com