ECSS-Q-ST-80C evidence pilot
Five days, one review, your own evidence: a clause-by-clause draft compliance matrix against ECSS-Q-ST-80C Rev.2, traced to your files, handed over with a record you can check without us.
Pricing on request: talk to us.
What it is
ECSS-Q-ST-80C is the software product assurance standard of the European Cooperation for Space Standardization (ECSS). Its current edition is Revision 2 (Rev.2), dated 30 April 2025.
The pilot is a service delivered by Ashforde OÜ. We run our open role, the Software Product Assurance Engineer (software-product-assurance-engineer, published in the aero-agent-roles package), with the ECSS-Q-ST-80C skills it binds from the aero-agent-skills package, over the evidence you send. The role's engine is plain, deterministic code: the same inputs give the same matrix. We run it in our own environment, which records the run and seals the result in a signed record.
Who it is for
The product assurance (PA) manager, or the software PA engineer, at a European space supplier who has to show where the software stands against ECSS-Q-ST-80C before a milestone review, and who wants a second, fully traced pass over the evidence before it goes to the customer.
What you send
- Your software criticality category: A, B, C or D.
- Your evidence table: one row per piece of evidence, giving the clause, the document, the section, the status you claim and the justification. A spreadsheet saved as CSV (comma-separated values) is enough, and loose column names are accepted.
- The folder of documents your evidence cites.
- The review you are preparing for, for example the Preliminary Design Review (PDR), the Critical Design Review (CDR) or the Qualification Review (QR). The System Requirements Review (SRR), Test Readiness Review (TRR), Acceptance Review (AR) and Operational Readiness Review (ORR) are supported too.
- If you have them: the review pack you plan to submit, your product quality measurements, and your customer's own clause list where it differs from the full standard.
Before you send anything, we agree in writing how your documents are handled and kept confidential.
What you get
- A clause-by-clause compliance matrix, as Markdown and as CSV. By default it has one row for every requirement of the standard (264 clauses in
aero-agent-roles1.2.3), or one row per clause of your own list. Each row carries the tailoring for your category, a status (compliant, partially compliant, not compliant, not applicable), the justification, the evidence references and the gaps. - A gap list, each gap named against the area of work that closes it: the plan, the process or the product metrics.
- A per-clause trace to your own files. Every document your evidence cites is resolved to a file in your folder. A citation that resolves to no file becomes a gap, and a compliant claim resting on it is downgraded. Files that no evidence row cites are listed as well.
- A check of what your review owes: the documents due at that review, the clauses that drive each one, and the state of their evidence.
- A signed record of the run, which you can verify offline without us (see below).
Every output is marked DRAFT and ends at the line STOP: human sign-off required before submission.
The five days
- Day 1Intake. We confirm the category, the review and the clause list, and check that your evidence table and folder read cleanly. Anything we cannot read comes back to you as a question.
- Day 2Tailoring and matrix. The role applies the tailoring for your category and builds the matrix, one row per clause. A clause without evidence is never counted as compliant.
- Day 3Trace and review check. Every citation is traced to a file, and the documents your review owes are checked against your evidence and your pack.
- Day 4Walk-through. We go through the gaps with you. You correct or add inputs, and we run again on the corrected set.
- Day 5Handover. The final draft matrix, gap list, trace, review check and signed record, with the steps to verify the record yourself.
An indicative plan. The exact days are agreed with you before we start.
What it does not do
- It does not sign. Everything we hand over is a draft that stops at your own human sign-off. Ashforde never signs compliance on your behalf and never issues a statement of compliance.
- It checks that each cited document exists in your folder. It does not judge whether a document's content is adequate: that judgement stays with your engineers.
- It does not accept a "not applicable" claim on a clause your tailoring keeps. That is a deviation which needs your customer's agreement, so it stays on the gap list.
- It is not an approval, an acceptance or a certification by the European Space Agency (ESA), by a prime contractor or by anyone else.
- It does not reproduce the text of ECSS-Q-ST-80C. Clauses are cited by their identifiers, and topic labels are our own wording.
Check the result without us
The record we hand over is signed and timestamped. Our verifier kit is public: release verifier-2026-09-26 in the repository github.com/ashfordeOU/aero-harness-records. It is a folder you copy and run with Python 3 and nothing else: no network, no account, nothing to install. It checks the record's signature under a key you choose to trust, checks its timestamp, and checks that the files you hold are the ones the record names by their cryptographic fingerprint (hash). Each check answers agree or disagree, or says why it did not run.
The kit checks that the record is intact and says what it says. It does not tell you whether any engineering conclusion is correct.
Try the open layer first
The role and the skills behind the pilot are open source under the Apache License 2.0, published on npm (the JavaScript package registry) as aero-agent-roles and aero-agent-skills. With Node.js and Python 3 installed, you can run the role yourself on its bundled worked example, an invented category B project at PDR:
npx -y aero-agent-roles install software-product-assurance-engineer --dest ./pa
cd pa/software-product-assurance-engineer
python3 cli.py build --out matrix.mdThe pilot is for when you want us to run it on your real evidence, go through the gaps with you and hand over a signed record. More on the open layer: Aero Agent Roles and Aero Agent Skills.
Pricing
Pricing on request: talk to us. Write to us or use the contact page, and we will scope the pilot with you before anything is agreed.
Cinq jours, une revue, vos propres preuves : une matrice de conformité provisoire, exigence par exigence, au regard de l'ECSS-Q-ST-80C Rev.2, tracée jusqu'à vos fichiers et remise avec un enregistrement que vous pouvez vérifier sans nous.
Tarifs sur demande : parlons-en.
De quoi s'agit-il
L'ECSS-Q-ST-80C est la norme d'assurance produit logiciel de la Coopération européenne pour la normalisation spatiale (European Cooperation for Space Standardization, ECSS). Son édition en vigueur est la révision 2 (Rev.2), datée du 30 avril 2025.
Le pilote est un service fourni par Ashforde OÜ. Nous exécutons notre rôle ouvert, le Software Product Assurance Engineer (software-product-assurance-engineer, publié dans le paquet aero-agent-roles), avec les compétences ECSS-Q-ST-80C qu'il mobilise dans le paquet aero-agent-skills, sur les preuves que vous nous transmettez. Le moteur du rôle est un code simple et déterministe : les mêmes entrées produisent la même matrice. Nous l'exécutons dans notre propre environnement, qui enregistre l'exécution et scelle le résultat dans un enregistrement signé.
À qui il s'adresse
Au responsable assurance produit (product assurance, PA), ou à l'ingénieur PA logiciel, d'un fournisseur spatial européen qui doit montrer où en est le logiciel au regard de l'ECSS-Q-ST-80C avant une revue d'étape, et qui souhaite un second passage, entièrement tracé, sur les preuves avant qu'elles ne partent chez le client.
Ce que vous nous transmettez
- La catégorie de criticité de votre logiciel : A, B, C ou D.
- Votre tableau de preuves : une ligne par élément de preuve, indiquant l'exigence, le document, la section, le statut revendiqué et la justification. Un tableur enregistré au format CSV (valeurs séparées par des virgules) suffit, et les intitulés de colonnes approximatifs sont acceptés.
- Le dossier des documents cités par vos preuves.
- La revue que vous préparez, par exemple la revue de conception préliminaire (Preliminary Design Review, PDR), la revue critique de conception (Critical Design Review, CDR) ou la revue de qualification (Qualification Review, QR). La revue des exigences système (System Requirements Review, SRR), la revue d'aptitude aux essais (Test Readiness Review, TRR), la revue de recette (Acceptance Review, AR) et la revue d'aptitude opérationnelle (Operational Readiness Review, ORR) sont également prises en charge.
- Si vous en disposez : le dossier de revue que vous prévoyez de soumettre, vos mesures de qualité produit et la liste d'exigences propre à votre client lorsqu'elle diffère de la norme complète.
Avant tout envoi, nous convenons par écrit de la manière dont vos documents sont traités et tenus confidentiels.
Ce que vous recevez
- Une matrice de conformité exigence par exigence, au format Markdown et CSV. Par défaut, elle comporte une ligne pour chaque exigence de la norme (264 exigences dans
aero-agent-roles1.2.3), ou une ligne par exigence de votre propre liste. Chaque ligne indique l'adaptation (tailoring) applicable à votre catégorie, un statut (conforme, partiellement conforme, non conforme, non applicable), la justification, les références de preuve et les écarts. - Une liste des écarts, chaque écart étant rattaché au domaine de travail qui permet de le combler : le plan, le processus ou les métriques produit.
- Une traçabilité, exigence par exigence, jusqu'à vos propres fichiers. Chaque document cité par vos preuves est rapproché d'un fichier de votre dossier. Une citation qui ne correspond à aucun fichier devient un écart, et une déclaration de conformité qui s'y appuie est déclassée. Les fichiers qu'aucune ligne de preuve ne cite sont également listés.
- Une vérification de ce que doit contenir votre revue : les documents attendus à cette revue, les exigences qui motivent chacun d'eux et l'état de leurs preuves.
- Un enregistrement signé de l'exécution, que vous pouvez vérifier hors ligne, sans nous (voir ci-dessous).
Chaque livrable porte la mention DRAFT (provisoire) et se termine par la ligne STOP: human sign-off required before submission.
Les cinq jours
- Jour 1Prise en charge. Nous confirmons la catégorie, la revue et la liste d'exigences, et vérifions que votre tableau de preuves et votre dossier se lisent correctement. Tout ce que nous ne pouvons pas lire vous revient sous forme de question.
- Jour 2Adaptation et matrice. Le rôle applique l'adaptation propre à votre catégorie et construit la matrice, une ligne par exigence. Une exigence sans preuve n'est jamais comptée comme conforme.
- Jour 3Traçabilité et contrôle de la revue. Chaque citation est tracée jusqu'à un fichier, et les documents dus à votre revue sont confrontés à vos preuves et à votre dossier.
- Jour 4Revue commentée. Nous passons les écarts en revue avec vous. Vous corrigez ou complétez les entrées, et nous relançons l'exécution sur le jeu corrigé.
- Jour 5Remise. La matrice provisoire finale, la liste des écarts, la traçabilité, le contrôle de la revue et l'enregistrement signé, avec la marche à suivre pour vérifier vous-même l'enregistrement.
Un plan indicatif. Le déroulé exact est convenu avec vous avant le démarrage.
Ce qu'il ne fait pas
- Il ne signe pas. Tout ce que nous remettons est un document provisoire qui s'arrête à la validation signée par une personne de votre organisation. Ashforde ne signe jamais la conformité à votre place et n'émet jamais de déclaration de conformité.
- Il vérifie que chaque document cité existe dans votre dossier. Il ne juge pas si le contenu d'un document est suffisant : ce jugement reste celui de vos ingénieurs.
- Il n'accepte pas une déclaration « non applicable » sur une exigence que votre adaptation conserve. Il s'agit d'une dérogation qui requiert l'accord de votre client ; elle reste donc sur la liste des écarts.
- Ce n'est ni une approbation, ni une acceptation, ni une certification de l'Agence spatiale européenne (ESA), d'un maître d'œuvre ou de quiconque.
- Il ne reproduit pas le texte de l'ECSS-Q-ST-80C. Les exigences sont citées par leur identifiant, et les intitulés thématiques sont formulés par nos soins.
Vérifier le résultat sans nous
L'enregistrement que nous remettons est signé et horodaté. Notre kit de vérification est public : version verifier-2026-09-26 dans le dépôt github.com/ashfordeOU/aero-harness-records. Il s'agit d'un dossier que vous copiez et exécutez avec Python 3, sans rien d'autre : ni réseau, ni compte, ni installation. Il vérifie la signature de l'enregistrement au moyen d'une clé à laquelle vous choisissez de faire confiance, contrôle son horodatage et vérifie que les fichiers en votre possession sont bien ceux que l'enregistrement désigne par leur empreinte cryptographique (hash). Chaque contrôle répond « concorde » ou « ne concorde pas », ou indique pourquoi il n'a pas été exécuté.
Le kit vérifie que l'enregistrement est intact et qu'il dit ce qu'il affirme. Il ne vous dit pas si une conclusion d'ingénierie est juste.
Essayez d'abord la couche ouverte
Le rôle et les compétences qui sous-tendent le pilote sont open source sous licence Apache 2.0, publiés sur npm (le registre de paquets JavaScript) sous les noms aero-agent-roles et aero-agent-skills. Avec Node.js et Python 3 installés, vous pouvez exécuter vous-même le rôle sur l'exemple fourni, un projet fictif de catégorie B en PDR :
npx -y aero-agent-roles install software-product-assurance-engineer --dest ./pa
cd pa/software-product-assurance-engineer
python3 cli.py build --out matrix.mdLe pilote s'adresse à ceux qui veulent que nous l'exécutions sur leurs preuves réelles, que nous passions les écarts en revue avec eux et que nous leur remettions un enregistrement signé. Pour en savoir plus sur la couche ouverte : Aero Agent Roles et Aero Agent Skills.
Tarifs
Tarifs sur demande : parlons-en. Écrivez-nous ou passez par la page de contact, et nous définirons avec vous le périmètre du pilote avant tout engagement.
Fünf Tage, ein Review, Ihre eigenen Nachweise: eine Konformitätsmatrix im Entwurf, Anforderung für Anforderung gegen ECSS-Q-ST-80C Rev.2, bis zu Ihren Dateien rückverfolgt und übergeben mit einem Nachweisprotokoll, das Sie ohne uns prüfen können.
Preise auf Anfrage: sprechen Sie uns an.
Worum es geht
ECSS-Q-ST-80C ist die Norm für Software-Produktsicherung der European Cooperation for Space Standardization (ECSS), der Europäischen Kooperation für Raumfahrtnormung. Die aktuelle Ausgabe ist Revision 2 (Rev.2) vom 30. April 2025.
Der Pilot ist eine Dienstleistung der Ashforde OÜ. Wir führen unsere offene Rolle, den Software Product Assurance Engineer (software-product-assurance-engineer, veröffentlicht im Paket aero-agent-roles), zusammen mit den ECSS-Q-ST-80C-Skills, die sie aus dem Paket aero-agent-skills einbindet, auf den Nachweisen aus, die Sie uns senden. Der Kern der Rolle ist schlichter, deterministischer Code: Gleiche Eingaben ergeben die gleiche Matrix. Wir führen ihn in unserer eigenen Umgebung aus, die den Lauf aufzeichnet und das Ergebnis in einem signierten Protokoll versiegelt.
Für wen er gedacht ist
Für die Leitung der Produktsicherung (Product Assurance, PA) oder den Software-PA-Ingenieur bei einem europäischen Raumfahrtzulieferer, der vor einem Meilenstein-Review zeigen muss, wo die Software gegenüber ECSS-Q-ST-80C steht, und der einen zweiten, vollständig rückverfolgten Durchgang über die Nachweise wünscht, bevor sie an den Kunden gehen.
Was Sie uns senden
- Die Kritikalitätskategorie Ihrer Software: A, B, C oder D.
- Ihre Nachweistabelle: eine Zeile je Nachweis mit Anforderung, Dokument, Abschnitt, beanspruchtem Status und Begründung. Eine als CSV (durch Kommas getrennte Werte) gespeicherte Tabelle genügt; ungenaue Spaltennamen werden akzeptiert.
- Den Ordner mit den Dokumenten, auf die Ihre Nachweise verweisen.
- Das Review, auf das Sie sich vorbereiten, zum Beispiel das Preliminary Design Review (PDR, vorläufige Entwurfsprüfung), das Critical Design Review (CDR, kritische Entwurfsprüfung) oder das Qualification Review (QR, Qualifikationsprüfung). Das System Requirements Review (SRR, Prüfung der Systemanforderungen), das Test Readiness Review (TRR, Prüfung der Testbereitschaft), das Acceptance Review (AR, Abnahmeprüfung) und das Operational Readiness Review (ORR, Prüfung der Betriebsbereitschaft) werden ebenfalls unterstützt.
- Falls vorhanden: das Review-Paket, das Sie einreichen wollen, Ihre Produktqualitätsmessungen und die eigene Anforderungsliste Ihres Kunden, sofern sie von der vollständigen Norm abweicht.
Bevor Sie etwas senden, vereinbaren wir schriftlich, wie Ihre Dokumente behandelt und vertraulich gehalten werden.
Was Sie erhalten
- Eine Konformitätsmatrix, Anforderung für Anforderung, als Markdown und als CSV. Standardmäßig enthält sie eine Zeile für jede Anforderung der Norm (264 Anforderungen in
aero-agent-roles1.2.3) oder eine Zeile je Anforderung Ihrer eigenen Liste. Jede Zeile enthält das Tailoring für Ihre Kategorie, einen Status (konform, teilweise konform, nicht konform, nicht anwendbar), die Begründung, die Nachweisverweise und die Lücken. - Eine Lückenliste, in der jede Lücke dem Arbeitsbereich zugeordnet ist, der sie schließt: dem Plan, dem Prozess oder den Produktmetriken.
- Eine Rückverfolgung je Anforderung bis zu Ihren eigenen Dateien. Jedes Dokument, auf das Ihre Nachweise verweisen, wird einer Datei in Ihrem Ordner zugeordnet. Ein Verweis ohne passende Datei wird zur Lücke, und eine darauf gestützte Konformitätsaussage wird herabgestuft. Dateien, auf die keine Nachweiszeile verweist, werden ebenfalls aufgeführt.
- Eine Prüfung dessen, was Ihr Review verlangt: die zu diesem Review fälligen Dokumente, die Anforderungen, die jedes davon begründen, und der Stand ihrer Nachweise.
- Ein signiertes Protokoll des Laufs, das Sie offline und ohne uns prüfen können (siehe unten).
Jedes Ergebnis ist als DRAFT (Entwurf) gekennzeichnet und endet mit der Zeile STOP: human sign-off required before submission.
Die fünf Tage
- Tag 1Aufnahme. Wir bestätigen Kategorie, Review und Anforderungsliste und prüfen, ob sich Ihre Nachweistabelle und Ihr Ordner sauber einlesen lassen. Was wir nicht lesen können, geht als Frage an Sie zurück.
- Tag 2Tailoring und Matrix. Die Rolle wendet das Tailoring für Ihre Kategorie an und erstellt die Matrix, eine Zeile je Anforderung. Eine Anforderung ohne Nachweis gilt nie als konform.
- Tag 3Rückverfolgung und Review-Prüfung. Jeder Verweis wird bis zu einer Datei verfolgt, und die für Ihr Review fälligen Dokumente werden mit Ihren Nachweisen und Ihrem Paket abgeglichen.
- Tag 4Durchsprache. Wir gehen die Lücken mit Ihnen durch. Sie korrigieren oder ergänzen Eingaben, und wir führen den Lauf mit dem korrigierten Stand erneut aus.
- Tag 5Übergabe. Die endgültige Entwurfsmatrix, Lückenliste, Rückverfolgung, Review-Prüfung und das signierte Protokoll, mit den Schritten, um das Protokoll selbst zu prüfen.
Ein Richtplan. Die genauen Tage vereinbaren wir mit Ihnen vor dem Start.
Was er nicht leistet
- Er unterschreibt nicht. Alles, was wir übergeben, ist ein Entwurf, der bei der Freigabe durch eine verantwortliche Person Ihres Hauses endet. Ashforde bestätigt niemals Konformität in Ihrem Namen und stellt niemals eine Konformitätserklärung aus.
- Er prüft, ob jedes zitierte Dokument in Ihrem Ordner vorhanden ist. Er beurteilt nicht, ob der Inhalt eines Dokuments ausreicht: Dieses Urteil bleibt bei Ihren Ingenieuren.
- Er akzeptiert keine Angabe „nicht anwendbar“ für eine Anforderung, die Ihr Tailoring beibehält. Das ist eine Abweichung, die der Zustimmung Ihres Kunden bedarf, und bleibt daher auf der Lückenliste.
- Er ist keine Genehmigung, keine Abnahme und keine Zertifizierung durch die Europäische Weltraumorganisation (European Space Agency, ESA), einen Hauptauftragnehmer oder sonst jemanden.
- Er gibt den Text von ECSS-Q-ST-80C nicht wieder. Anforderungen werden über ihre Kennungen zitiert, die Themenbezeichnungen sind unsere eigene Formulierung.
Das Ergebnis ohne uns prüfen
Das übergebene Protokoll ist signiert und mit einem Zeitstempel versehen. Unser Prüfwerkzeug ist öffentlich: Release verifier-2026-09-26 im Repository github.com/ashfordeOU/aero-harness-records. Es ist ein Ordner, den Sie kopieren und allein mit Python 3 ausführen: kein Netzwerk, kein Konto, keine Installation. Es prüft die Signatur des Protokolls mit einem Schlüssel, dem Sie selbst vertrauen, prüft den Zeitstempel und prüft, ob die Dateien in Ihrer Hand diejenigen sind, die das Protokoll über ihren kryptografischen Fingerabdruck (Hash) benennt. Jede Prüfung antwortet mit Übereinstimmung oder Abweichung oder nennt den Grund, warum sie nicht lief.
Das Werkzeug prüft, dass das Protokoll unverändert ist und aussagt, was es aussagt. Ob eine technische Schlussfolgerung richtig ist, sagt es Ihnen nicht.
Zuerst die offene Ebene ausprobieren
Die Rolle und die Skills hinter dem Pilot sind quelloffen unter der Apache License 2.0 und auf npm (dem JavaScript-Paketregister) als aero-agent-roles und aero-agent-skills veröffentlicht. Mit Node.js und Python 3 können Sie die Rolle selbst auf ihrem mitgelieferten Beispiel ausführen, einem erfundenen Projekt der Kategorie B beim PDR:
npx -y aero-agent-roles install software-product-assurance-engineer --dest ./pa
cd pa/software-product-assurance-engineer
python3 cli.py build --out matrix.mdDer Pilot ist für den Fall gedacht, dass wir die Rolle auf Ihren echten Nachweisen ausführen, die Lücken mit Ihnen durchgehen und ein signiertes Protokoll übergeben sollen. Mehr zur offenen Ebene: Aero Agent Roles und Aero Agent Skills.
Preise
Preise auf Anfrage: sprechen Sie uns an. Schreiben Sie uns oder nutzen Sie die Kontaktseite; wir legen den Umfang des Pilots mit Ihnen fest, bevor irgendetwas vereinbart wird.
Cinque giorni, una revisione, le vostre evidenze: una matrice di conformità in bozza, requisito per requisito, rispetto alla ECSS-Q-ST-80C Rev.2, tracciata fino ai vostri file e consegnata con un registro che potete verificare senza di noi.
Prezzi su richiesta: parliamone.
Di che cosa si tratta
La ECSS-Q-ST-80C è la norma sull'assicurazione del prodotto software della Cooperazione europea per la normazione spaziale (European Cooperation for Space Standardization, ECSS). L'edizione in vigore è la revisione 2 (Rev.2), del 30 aprile 2025.
Il pilota è un servizio erogato da Ashforde OÜ. Eseguiamo il nostro ruolo aperto, il Software Product Assurance Engineer (software-product-assurance-engineer, pubblicato nel pacchetto aero-agent-roles), insieme alle skill ECSS-Q-ST-80C che esso collega dal pacchetto aero-agent-skills, sulle evidenze che ci inviate. Il motore del ruolo è codice semplice e deterministico: a parità di input, la stessa matrice. Lo eseguiamo nel nostro ambiente, che registra l'esecuzione e sigilla il risultato in un registro firmato.
A chi è rivolto
Al responsabile dell'assicurazione del prodotto (product assurance, PA), o all'ingegnere PA del software, di un fornitore spaziale europeo che deve mostrare a che punto è il software rispetto alla ECSS-Q-ST-80C prima di una revisione di milestone, e che desidera un secondo passaggio, interamente tracciato, sulle evidenze prima che arrivino al cliente.
Che cosa ci inviate
- La categoria di criticità del vostro software: A, B, C o D.
- La vostra tabella delle evidenze: una riga per ogni evidenza, con il requisito, il documento, la sezione, lo stato dichiarato e la giustificazione. Basta un foglio di calcolo salvato in CSV (valori separati da virgole); sono accettati anche nomi di colonna non esatti.
- La cartella dei documenti citati dalle vostre evidenze.
- La revisione che state preparando, per esempio la revisione preliminare di progetto (Preliminary Design Review, PDR), la revisione critica di progetto (Critical Design Review, CDR) o la revisione di qualifica (Qualification Review, QR). Sono supportate anche la revisione dei requisiti di sistema (System Requirements Review, SRR), la revisione di prontezza ai test (Test Readiness Review, TRR), la revisione di accettazione (Acceptance Review, AR) e la revisione di prontezza operativa (Operational Readiness Review, ORR).
- Se disponibili: il pacchetto di revisione che intendete presentare, le vostre misure di qualità del prodotto e l'elenco dei requisiti del vostro cliente, se diverso dalla norma completa.
Prima di qualsiasi invio, concordiamo per iscritto come i vostri documenti vengono trattati e mantenuti riservati.
Che cosa ricevete
- Una matrice di conformità requisito per requisito, in Markdown e in CSV. Di default contiene una riga per ogni requisito della norma (264 requisiti in
aero-agent-roles1.2.3), oppure una riga per ogni requisito del vostro elenco. Ogni riga riporta il tailoring per la vostra categoria, uno stato (conforme, parzialmente conforme, non conforme, non applicabile), la giustificazione, i riferimenti alle evidenze e le lacune. - Un elenco delle lacune, ciascuna associata all'area di lavoro che la chiude: il piano, il processo o le metriche di prodotto.
- Una tracciabilità, requisito per requisito, fino ai vostri file. Ogni documento citato dalle vostre evidenze viene ricondotto a un file della vostra cartella. Una citazione che non corrisponde ad alcun file diventa una lacuna, e una dichiarazione di conformità che vi si appoggia viene declassata. Sono elencati anche i file che nessuna riga di evidenza cita.
- Una verifica di ciò che la vostra revisione richiede: i documenti dovuti a quella revisione, i requisiti che motivano ciascuno di essi e lo stato delle relative evidenze.
- Un registro firmato dell'esecuzione, che potete verificare offline, senza di noi (vedi sotto).
Ogni risultato è contrassegnato come DRAFT (bozza) e termina con la riga STOP: human sign-off required before submission.
I cinque giorni
- Giorno 1Presa in carico. Confermiamo la categoria, la revisione e l'elenco dei requisiti, e verifichiamo che la tabella delle evidenze e la cartella si leggano correttamente. Ciò che non riusciamo a leggere vi torna sotto forma di domanda.
- Giorno 2Tailoring e matrice. Il ruolo applica il tailoring per la vostra categoria e costruisce la matrice, una riga per requisito. Un requisito senza evidenze non viene mai considerato conforme.
- Giorno 3Tracciabilità e verifica della revisione. Ogni citazione viene tracciata fino a un file, e i documenti dovuti alla vostra revisione vengono confrontati con le vostre evidenze e con il vostro pacchetto.
- Giorno 4Analisi congiunta. Esaminiamo le lacune insieme a voi. Correggete o integrate gli input, e rieseguiamo sul set corretto.
- Giorno 5Consegna. La matrice in bozza definitiva, l'elenco delle lacune, la tracciabilità, la verifica della revisione e il registro firmato, con i passaggi per verificare voi stessi il registro.
Un piano indicativo. I giorni esatti vengono concordati con voi prima dell'avvio.
Che cosa non fa
- Non firma. Tutto ciò che consegniamo è una bozza che si ferma all'approvazione firmata da una persona della vostra organizzazione. Ashforde non firma mai la conformità per vostro conto e non rilascia mai una dichiarazione di conformità.
- Verifica che ogni documento citato esista nella vostra cartella. Non giudica se il contenuto di un documento sia adeguato: quel giudizio resta ai vostri ingegneri.
- Non accetta una dichiarazione di "non applicabile" su un requisito che il vostro tailoring mantiene. Si tratta di una deviazione che richiede l'accordo del vostro cliente, e resta quindi nell'elenco delle lacune.
- Non è un'approvazione, un'accettazione o una certificazione dell'Agenzia spaziale europea (ESA), di un prime contractor o di chiunque altro.
- Non riproduce il testo della ECSS-Q-ST-80C. I requisiti sono citati tramite i loro identificativi e le etichette tematiche sono formulate da noi.
Verificare il risultato senza di noi
Il registro che consegniamo è firmato e marcato temporalmente. Il nostro kit di verifica è pubblico: release verifier-2026-09-26 nel repository github.com/ashfordeOU/aero-harness-records. È una cartella che copiate ed eseguite con Python 3 e nient'altro: nessuna rete, nessun account, nessuna installazione. Verifica la firma del registro con una chiave di cui scegliete voi di fidarvi, ne controlla la marca temporale e verifica che i file in vostro possesso siano quelli che il registro indica tramite la loro impronta crittografica (hash). Ogni controllo risponde concorda o non concorda, oppure indica perché non è stato eseguito.
Il kit verifica che il registro sia integro e dica ciò che afferma. Non vi dice se una conclusione ingegneristica sia corretta.
Provate prima il livello aperto
Il ruolo e le skill alla base del pilota sono open source con licenza Apache 2.0 e pubblicati su npm (il registro dei pacchetti JavaScript) come aero-agent-roles e aero-agent-skills. Con Node.js e Python 3 installati, potete eseguire voi stessi il ruolo sull'esempio incluso, un progetto fittizio di categoria B alla PDR:
npx -y aero-agent-roles install software-product-assurance-engineer --dest ./pa
cd pa/software-product-assurance-engineer
python3 cli.py build --out matrix.mdIl pilota è pensato per quando volete che lo eseguiamo noi sulle vostre evidenze reali, che esaminiamo le lacune con voi e che vi consegniamo un registro firmato. Per saperne di più sul livello aperto: Aero Agent Roles e Aero Agent Skills.
Prezzi
Prezzi su richiesta: parliamone. Scriveteci o usate la pagina dei contatti, e definiremo con voi il perimetro del pilota prima di qualsiasi accordo.
Cinco días, una revisión, sus propias evidencias: una matriz de cumplimiento en borrador, requisito por requisito, frente a la ECSS-Q-ST-80C Rev.2, trazada hasta sus archivos y entregada con un registro que puede verificar sin nosotros.
Precios a consultar: hable con nosotros.
Qué es
La ECSS-Q-ST-80C es la norma de aseguramiento de producto software de la Cooperación Europea para la Normalización Espacial (European Cooperation for Space Standardization, ECSS). Su edición vigente es la revisión 2 (Rev.2), de 30 de abril de 2025.
El piloto es un servicio prestado por Ashforde OÜ. Ejecutamos nuestro rol abierto, el Software Product Assurance Engineer (software-product-assurance-engineer, publicado en el paquete aero-agent-roles), junto con las skills de ECSS-Q-ST-80C que vincula del paquete aero-agent-skills, sobre las evidencias que usted nos envía. El motor del rol es código sencillo y determinista: las mismas entradas dan la misma matriz. Lo ejecutamos en nuestro propio entorno, que registra la ejecución y sella el resultado en un registro firmado.
Para quién es
Para el responsable de aseguramiento de producto (product assurance, PA), o el ingeniero de PA de software, de un proveedor espacial europeo que debe mostrar en qué punto está el software frente a la ECSS-Q-ST-80C antes de una revisión de hito, y que quiere una segunda pasada, totalmente trazada, sobre las evidencias antes de que lleguen al cliente.
Qué nos envía
- La categoría de criticidad de su software: A, B, C o D.
- Su tabla de evidencias: una fila por evidencia, con el requisito, el documento, la sección, el estado que declara y la justificación. Basta con una hoja de cálculo guardada como CSV (valores separados por comas), y se aceptan nombres de columna aproximados.
- La carpeta de documentos que citan sus evidencias.
- La revisión que está preparando, por ejemplo la revisión preliminar de diseño (Preliminary Design Review, PDR), la revisión crítica de diseño (Critical Design Review, CDR) o la revisión de cualificación (Qualification Review, QR). También se admiten la revisión de requisitos del sistema (System Requirements Review, SRR), la revisión de preparación para pruebas (Test Readiness Review, TRR), la revisión de aceptación (Acceptance Review, AR) y la revisión de preparación operacional (Operational Readiness Review, ORR).
- Si los tiene: el paquete de revisión que piensa presentar, sus mediciones de calidad del producto y la lista de requisitos propia de su cliente cuando difiera de la norma completa.
Antes de que envíe nada, acordamos por escrito cómo se tratan sus documentos y cómo se mantiene su confidencialidad.
Qué recibe
- Una matriz de cumplimiento requisito por requisito, en Markdown y en CSV. Por defecto tiene una fila por cada requisito de la norma (264 requisitos en
aero-agent-roles1.2.3), o una fila por cada requisito de su propia lista. Cada fila recoge la adaptación (tailoring) para su categoría, un estado (conforme, parcialmente conforme, no conforme, no aplicable), la justificación, las referencias de evidencia y las carencias. - Una lista de carencias, cada una asignada al área de trabajo que la resuelve: el plan, el proceso o las métricas de producto.
- Una trazabilidad, requisito por requisito, hasta sus propios archivos. Cada documento que citan sus evidencias se asocia a un archivo de su carpeta. Una cita que no corresponde a ningún archivo se convierte en carencia, y una declaración de conformidad que se apoye en ella se rebaja. También se enumeran los archivos que ninguna fila de evidencia cita.
- Una comprobación de lo que exige su revisión: los documentos que se deben presentar en esa revisión, los requisitos que motivan cada uno y el estado de sus evidencias.
- Un registro firmado de la ejecución, que puede verificar sin conexión y sin nosotros (véase más abajo).
Cada resultado lleva la marca DRAFT (borrador) y termina con la línea STOP: human sign-off required before submission.
Los cinco días
- Día 1Recepción. Confirmamos la categoría, la revisión y la lista de requisitos, y comprobamos que su tabla de evidencias y su carpeta se leen correctamente. Lo que no podamos leer le vuelve en forma de pregunta.
- Día 2Adaptación y matriz. El rol aplica la adaptación para su categoría y construye la matriz, una fila por requisito. Un requisito sin evidencia nunca se cuenta como conforme.
- Día 3Trazabilidad y comprobación de la revisión. Cada cita se traza hasta un archivo, y los documentos que exige su revisión se contrastan con sus evidencias y su paquete.
- Día 4Repaso conjunto. Repasamos las carencias con usted. Usted corrige o completa las entradas, y volvemos a ejecutar sobre el conjunto corregido.
- Día 5Entrega. La matriz en borrador definitiva, la lista de carencias, la trazabilidad, la comprobación de la revisión y el registro firmado, con los pasos para verificar usted mismo el registro.
Un plan orientativo. Los días exactos se acuerdan con usted antes de empezar.
Qué no hace
- No firma. Todo lo que entregamos es un borrador que se detiene en la aprobación firmada por una persona de su organización. Ashforde nunca firma el cumplimiento en su nombre y nunca emite una declaración de conformidad.
- Comprueba que cada documento citado existe en su carpeta. No juzga si el contenido de un documento es adecuado: ese juicio corresponde a sus ingenieros.
- No acepta una declaración de «no aplicable» sobre un requisito que su adaptación mantiene. Se trata de una desviación que requiere el acuerdo de su cliente, por lo que permanece en la lista de carencias.
- No es una aprobación, una aceptación ni una certificación de la Agencia Espacial Europea (ESA), de un contratista principal ni de nadie más.
- No reproduce el texto de la ECSS-Q-ST-80C. Los requisitos se citan por sus identificadores, y las etiquetas temáticas son redacción nuestra.
Verifique el resultado sin nosotros
El registro que entregamos está firmado y lleva sello de tiempo. Nuestro kit de verificación es público: versión verifier-2026-09-26 en el repositorio github.com/ashfordeOU/aero-harness-records. Es una carpeta que usted copia y ejecuta con Python 3 y nada más: sin red, sin cuenta, sin instalación. Comprueba la firma del registro con una clave en la que usted decide confiar, comprueba su sello de tiempo y comprueba que los archivos que usted conserva son los que el registro identifica por su huella criptográfica (hash). Cada comprobación responde coincide o no coincide, o indica por qué no se ejecutó.
El kit comprueba que el registro está íntegro y dice lo que afirma. No le dice si una conclusión de ingeniería es correcta.
Pruebe primero la capa abierta
El rol y las skills en los que se basa el piloto son de código abierto con licencia Apache 2.0 y están publicados en npm (el registro de paquetes de JavaScript) como aero-agent-roles y aero-agent-skills. Con Node.js y Python 3 instalados, puede ejecutar usted mismo el rol sobre su ejemplo incluido, un proyecto ficticio de categoría B en la PDR:
npx -y aero-agent-roles install software-product-assurance-engineer --dest ./pa
cd pa/software-product-assurance-engineer
python3 cli.py build --out matrix.mdEl piloto es para cuando quiera que lo ejecutemos nosotros sobre sus evidencias reales, repasemos las carencias con usted y le entreguemos un registro firmado. Más sobre la capa abierta: Aero Agent Roles y Aero Agent Skills.
Precios
Precios a consultar: hable con nosotros. Escríbanos o utilice la página de contacto, y definiremos con usted el alcance del piloto antes de acordar nada.
Viis päeva, üks ülevaatus, teie enda tõendid: nõuete kaupa koostatud vastavusmaatriksi kavand standardi ECSS-Q-ST-80C Rev.2 alusel, jälgitav kuni teie failideni ja üle antud koos kirjega, mida saate kontrollida ilma meieta.
Hind kokkuleppel: võtke meiega ühendust.
Mis see on
ECSS-Q-ST-80C on Euroopa Kosmosestandardimise Koostööorganisatsiooni (European Cooperation for Space Standardization, ECSS) tarkvara tootekvaliteedi tagamise standard. Kehtiv väljaanne on 2. redaktsioon (Rev.2), dateeritud 30. aprillil 2025.
Pilootprojekt on Ashforde OÜ osutatav teenus. Käivitame teie saadetud tõenditel oma avatud rolli Software Product Assurance Engineer (software-product-assurance-engineer, avaldatud paketis aero-agent-roles) koos ECSS-Q-ST-80C oskustega, mida see seob paketist aero-agent-skills. Rolli mootor on lihtne ja deterministlik kood: samad sisendid annavad sama maatriksi. Käitame seda oma keskkonnas, mis salvestab käituse ja pitseerib tulemuse allkirjastatud kirjes.
Kellele see on mõeldud
Euroopa kosmosetarnija tootekvaliteedi tagamise (product assurance, PA) juhile või tarkvara PA-insenerile, kes peab enne etapiülevaatust näitama, kus tarkvara ECSS-Q-ST-80C suhtes seisab, ja soovib enne tõendite kliendile saatmist nende teist, täielikult jälgitavat läbivaatust.
Mida te saadate
- Teie tarkvara kriitilisuskategooria: A, B, C või D.
- Teie tõendite tabel: üks rida iga tõendi kohta, kus on nõue, dokument, jaotis, väidetav olek ja põhjendus. Piisab CSV-vormingus (komaga eraldatud väärtused) salvestatud tabelist; veergude nimed ei pea olema täpsed.
- Kaust dokumentidega, millele teie tõendid viitavad.
- Ülevaatus, milleks valmistute, näiteks eelprojekti ülevaatus (Preliminary Design Review, PDR), kriitiline projektiülevaatus (Critical Design Review, CDR) või kvalifitseerimisülevaatus (Qualification Review, QR). Toetatud on ka süsteeminõuete ülevaatus (System Requirements Review, SRR), katsevalmiduse ülevaatus (Test Readiness Review, TRR), vastuvõtuülevaatus (Acceptance Review, AR) ja käitusvalmiduse ülevaatus (Operational Readiness Review, ORR).
- Kui need on olemas: ülevaatuspakett, mille kavatsete esitada, teie toote kvaliteedimõõtmised ja teie kliendi oma nõuete loend, kui see erineb täielikust standardist.
Enne kui midagi saadate, lepime kirjalikult kokku, kuidas teie dokumente käsitletakse ja konfidentsiaalsena hoitakse.
Mida te saate
- Nõuete kaupa koostatud vastavusmaatriks Markdowni- ja CSV-vormingus. Vaikimisi on selles üks rida iga standardi nõude kohta (264 nõuet paketis
aero-agent-roles1.2.3) või üks rida iga teie oma loendi nõude kohta. Igas reas on teie kategooria kohandamine (tailoring), olek (vastab, vastab osaliselt, ei vasta, ei kohaldu), põhjendus, viited tõenditele ja puudujäägid. - Puudujääkide loend, kus iga puudujääk on seotud töövaldkonnaga, mis selle kõrvaldab: kava, protsessi või toote mõõdikutega.
- Nõuete kaupa jälgitavus kuni teie enda failideni. Iga dokument, millele teie tõendid viitavad, seotakse teie kaustas oleva failiga. Viide, millele ei vasta ükski fail, muutub puudujäägiks ja sellele toetuv vastavusväide alandatakse. Loetletakse ka failid, millele ükski tõendirida ei viita.
- Kontroll selle kohta, mida teie ülevaatus nõuab: sellel ülevaatusel esitatavad dokumendid, nõuded, millest igaüks tuleneb, ja nende tõendite seis.
- Allkirjastatud kirje käitusest, mida saate kontrollida võrguühenduseta ja ilma meieta (vt allpool).
Iga väljund on märgitud kui DRAFT (kavand) ja lõpeb reaga STOP: human sign-off required before submission.
Viis päeva
- 1. päevVastuvõtt. Kinnitame kategooria, ülevaatuse ja nõuete loendi ning kontrollime, et teie tõendite tabel ja kaust on korrektselt loetavad. Mida me lugeda ei saa, jõuab teieni küsimusena tagasi.
- 2. päevKohandamine ja maatriks. Roll rakendab teie kategooria kohandamise ja koostab maatriksi, üks rida iga nõude kohta. Tõenditeta nõuet ei loeta kunagi vastavaks.
- 3. päevJälgitavus ja ülevaatuse kontroll. Iga viide jälgitakse failini ning teie ülevaatusel nõutavaid dokumente võrreldakse teie tõendite ja paketiga.
- 4. päevÜhine läbivaatus. Käime puudujäägid koos teiega läbi. Te parandate või täiendate sisendeid ja me käivitame parandatud komplekti uuesti.
- 5. päevÜleandmine. Lõplik maatriksi kavand, puudujääkide loend, jälgitavus, ülevaatuse kontroll ja allkirjastatud kirje koos juhistega, kuidas kirjet ise kontrollida.
Suunav kava. Täpsed päevad lepime teiega kokku enne alustamist.
Mida see ei tee
- See ei allkirjasta. Kõik, mida üle anname, on kavand, mis peatub teie organisatsiooni vastutava inimese allkirja juures. Ashforde ei allkirjasta kunagi vastavust teie eest ega väljasta kunagi vastavusavaldust.
- See kontrollib, et iga viidatud dokument on teie kaustas olemas. See ei hinda, kas dokumendi sisu on piisav: see otsus jääb teie inseneridele.
- See ei aktsepteeri väidet „ei kohaldu“ nõude kohta, mille teie kohandamine alles jätab. See on kõrvalekalle, mis vajab teie kliendi nõusolekut, ja jääb seetõttu puudujääkide loendisse.
- See ei ole Euroopa Kosmoseagentuuri (European Space Agency, ESA), peatöövõtja ega kellegi teise heakskiit, vastuvõtt ega sertifitseerimine.
- See ei esita standardi ECSS-Q-ST-80C teksti. Nõuetele viidatakse nende tunnuste järgi ja teemasildid on meie enda sõnastuses.
Kontrollige tulemust ilma meieta
Kirje, mille üle anname, on allkirjastatud ja ajatempliga. Meie kontrollikomplekt on avalik: väljalase verifier-2026-09-26 hoidlas github.com/ashfordeOU/aero-harness-records. See on kaust, mille kopeerite ja käivitate ainult Python 3-ga: ilma võrguta, ilma kontota, ilma paigalduseta. See kontrollib kirje allkirja teie enda valitud usaldusväärse võtmega, kontrollib ajatemplit ning kontrollib, et teie käes olevad failid on needsamad, mida kirje nende krüptograafilise sõrmejälje (räsi) järgi nimetab. Iga kontroll vastab „ühtib“ või „ei ühti“ või ütleb, miks see ei käivitunud.
Komplekt kontrollib, et kirje on muutmata ja ütleb seda, mida väidab. See ei ütle teile, kas mõni insenerijäreldus on õige.
Proovige kõigepealt avatud kihti
Pilootprojekti aluseks olev roll ja oskused on avatud lähtekoodiga Apache License 2.0 litsentsi all ning avaldatud npm-is (JavaScripti pakettide registris) nimede aero-agent-roles ja aero-agent-skills all. Kui Node.js ja Python 3 on paigaldatud, saate rolli ise käivitada kaasasoleval näitel, väljamõeldud B-kategooria projektil PDR-i etapis:
npx -y aero-agent-roles install software-product-assurance-engineer --dest ./pa
cd pa/software-product-assurance-engineer
python3 cli.py build --out matrix.mdPilootprojekt on mõeldud juhuks, kui soovite, et käivitaksime selle teie päris tõenditel, käiksime puudujäägid teiega läbi ja annaksime üle allkirjastatud kirje. Avatud kihi kohta lähemalt: Aero Agent Roles ja Aero Agent Skills.
Hind
Hind kokkuleppel: võtke meiega ühendust. Kirjutage meile või kasutage kontaktilehte ning paneme koos teiega paika pilootprojekti ulatuse, enne kui midagi kokku lepime.
Vijf dagen, één review, uw eigen bewijs: een conceptconformiteitsmatrix, eis voor eis, tegen ECSS-Q-ST-80C Rev.2, herleidbaar tot uw eigen bestanden en overgedragen met een vastlegging die u zonder ons kunt controleren.
Prijs op aanvraag: neem contact met ons op.
Wat het is
ECSS-Q-ST-80C is de norm voor softwareproductborging van de European Cooperation for Space Standardization (ECSS), de Europese samenwerking voor ruimtevaartnormalisatie. De huidige uitgave is revisie 2 (Rev.2) van 30 april 2025.
De pilot is een dienst van Ashforde OÜ. Wij voeren onze open rol, de Software Product Assurance Engineer (software-product-assurance-engineer, gepubliceerd in het pakket aero-agent-roles), samen met de ECSS-Q-ST-80C-skills die deze uit het pakket aero-agent-skills koppelt, uit op het bewijs dat u ons stuurt. De kern van de rol is eenvoudige, deterministische code: dezelfde invoer geeft dezelfde matrix. Wij voeren die uit in onze eigen omgeving, die de uitvoering vastlegt en het resultaat verzegelt in een ondertekende vastlegging.
Voor wie het is
Voor de productborgingsmanager (product assurance, PA), of de software-PA-engineer, bij een Europese ruimtevaartleverancier die vóór een mijlpaalreview moet laten zien waar de software staat ten opzichte van ECSS-Q-ST-80C, en die een tweede, volledig herleidbare controle van het bewijs wil voordat het naar de klant gaat.
Wat u ons stuurt
- De kriticiteitscategorie van uw software: A, B, C of D.
- Uw bewijstabel: één regel per bewijsstuk, met de eis, het document, de sectie, de status die u claimt en de onderbouwing. Een spreadsheet opgeslagen als CSV (door komma's gescheiden waarden) volstaat, en onnauwkeurige kolomnamen worden geaccepteerd.
- De map met de documenten waarnaar uw bewijs verwijst.
- De review waarop u zich voorbereidt, bijvoorbeeld de Preliminary Design Review (PDR, voorlopige ontwerpreview), de Critical Design Review (CDR, kritische ontwerpreview) of de Qualification Review (QR, kwalificatiereview). De System Requirements Review (SRR, review van de systeemeisen), de Test Readiness Review (TRR, review van de testgereedheid), de Acceptance Review (AR, acceptatiereview) en de Operational Readiness Review (ORR, review van de operationele gereedheid) worden ook ondersteund.
- Indien beschikbaar: het reviewpakket dat u wilt indienen, uw productkwaliteitsmetingen en de eigen eisenlijst van uw klant als die afwijkt van de volledige norm.
Voordat u iets stuurt, leggen wij schriftelijk vast hoe uw documenten worden behandeld en vertrouwelijk worden gehouden.
Wat u krijgt
- Een conformiteitsmatrix, eis voor eis, als Markdown en als CSV. Standaard bevat die één regel voor elke eis van de norm (264 eisen in
aero-agent-roles1.2.3), of één regel per eis van uw eigen lijst. Elke regel bevat de tailoring voor uw categorie, een status (conform, gedeeltelijk conform, niet conform, niet van toepassing), de onderbouwing, de bewijsverwijzingen en de tekortkomingen. - Een lijst van tekortkomingen, elk gekoppeld aan het werkgebied dat haar oplost: het plan, het proces of de productmetrieken.
- Een herleiding per eis tot uw eigen bestanden. Elk document waarnaar uw bewijs verwijst, wordt gekoppeld aan een bestand in uw map. Een verwijzing zonder bijbehorend bestand wordt een tekortkoming, en een conformiteitsclaim die daarop steunt, wordt afgewaardeerd. Bestanden waarnaar geen enkele bewijsregel verwijst, worden ook vermeld.
- Een controle van wat uw review vraagt: de documenten die bij die review verschuldigd zijn, de eisen die elk daarvan bepalen en de stand van hun bewijs.
- Een ondertekende vastlegging van de uitvoering, die u offline en zonder ons kunt controleren (zie hieronder).
Elk resultaat is gemarkeerd als DRAFT (concept) en eindigt met de regel STOP: human sign-off required before submission.
De vijf dagen
- Dag 1Intake. Wij bevestigen de categorie, de review en de eisenlijst, en controleren of uw bewijstabel en map correct in te lezen zijn. Wat wij niet kunnen lezen, komt als vraag bij u terug.
- Dag 2Tailoring en matrix. De rol past de tailoring voor uw categorie toe en bouwt de matrix, één regel per eis. Een eis zonder bewijs telt nooit als conform.
- Dag 3Herleiding en reviewcontrole. Elke verwijzing wordt herleid tot een bestand, en de documenten die uw review vraagt, worden getoetst aan uw bewijs en uw pakket.
- Dag 4Doorloop. Wij lopen de tekortkomingen met u door. U corrigeert of vult de invoer aan, en wij voeren opnieuw uit op de gecorrigeerde set.
- Dag 5Overdracht. De definitieve conceptmatrix, de lijst van tekortkomingen, de herleiding, de reviewcontrole en de ondertekende vastlegging, met de stappen om de vastlegging zelf te controleren.
Een indicatieve planning. De precieze dagen spreken wij met u af voordat we beginnen.
Wat het niet doet
- Het ondertekent niet. Alles wat wij overdragen is een concept dat stopt bij de aftekening door een verantwoordelijke persoon binnen uw organisatie. Ashforde tekent nooit namens u voor conformiteit en geeft nooit een conformiteitsverklaring af.
- Het controleert of elk aangehaald document in uw map aanwezig is. Het beoordeelt niet of de inhoud van een document toereikend is: dat oordeel blijft bij uw engineers.
- Het accepteert geen claim "niet van toepassing" voor een eis die uw tailoring handhaaft. Dat is een afwijking die de instemming van uw klant vereist, en blijft dus op de lijst van tekortkomingen staan.
- Het is geen goedkeuring, acceptatie of certificering door het Europees Ruimteagentschap (European Space Agency, ESA), een hoofdaannemer of wie dan ook.
- Het geeft de tekst van ECSS-Q-ST-80C niet weer. Eisen worden aangehaald met hun kenmerk, en de onderwerplabels zijn onze eigen formulering.
Controleer het resultaat zonder ons
De vastlegging die wij overdragen is ondertekend en voorzien van een tijdstempel. Onze verificatiekit is openbaar: release verifier-2026-09-26 in de repository github.com/ashfordeOU/aero-harness-records. Het is een map die u kopieert en uitvoert met alleen Python 3: geen netwerk, geen account, niets te installeren. De kit controleert de handtekening van de vastlegging met een sleutel die u zelf kiest te vertrouwen, controleert de tijdstempel en controleert of de bestanden die u in handen hebt dezelfde zijn die de vastlegging aan de hand van hun cryptografische vingerafdruk (hash) noemt. Elke controle antwoordt met overeenstemming of afwijking, of zegt waarom zij niet is uitgevoerd.
De kit controleert dat de vastlegging ongewijzigd is en zegt wat zij beweert. Hij zegt u niet of een technische conclusie juist is.
Probeer eerst de open laag
De rol en de skills achter de pilot zijn open source onder de Apache License 2.0 en gepubliceerd op npm (het JavaScript-pakketregister) als aero-agent-roles en aero-agent-skills. Met Node.js en Python 3 geïnstalleerd kunt u de rol zelf uitvoeren op het meegeleverde voorbeeld, een verzonnen project van categorie B bij de PDR:
npx -y aero-agent-roles install software-product-assurance-engineer --dest ./pa
cd pa/software-product-assurance-engineer
python3 cli.py build --out matrix.mdDe pilot is bedoeld voor wanneer u wilt dat wij de rol op uw echte bewijs uitvoeren, de tekortkomingen met u doorlopen en een ondertekende vastlegging overdragen. Meer over de open laag: Aero Agent Roles en Aero Agent Skills.
Prijs
Prijs op aanvraag: neem contact met ons op. Schrijf ons of gebruik de contactpagina, en wij bepalen samen met u de omvang van de pilot voordat er iets wordt afgesproken.