NewSpace pace, space-grade proof: shortening a launcher or smallsat programme without skipping verification

NewSpace companies compete on schedule. A smallsat operator that reaches orbit a year earlier wins customers; a launcher that flies sooner books more missions. At the same time, nothing about the physics or the oversight has become more forgiving. Launch authorities, insurers and customers still expect evidence that the hardware meets its requirements.

The usual answer is to tailor the standards. ECSS standards are designed to be tailored to each project, and NewSpace programmes use that freedom. But tailoring decides how much verification is done. It does not make the remaining verification faster. This article looks at where the time actually goes in a launcher or smallsat programme, and how to win it back without removing proof.

Where the time goes

When engineering teams look back at a programme, the calendar rarely went into the design work itself. It went into three kinds of waiting.

Waiting for information. An engineer needs the current mass of an assembly, the latest revision of an interface, or the status of a test. The answer exists, but in someone else's spreadsheet or inbox.

Waiting for consistency. Before a review, documents that drifted apart have to be reconciled: the requirements, the interface control documents, the bill of materials, the verification matrix. This is rework on work already done.

Waiting for late discoveries. A change made months earlier turns out to affect an interface or a test nobody re-checked. The cost of that discovery grows with every month it stays hidden.

None of these are verification steps. They are the gaps between steps, and they are where a programme can recover months.

Interfaces are where programmes slip

A launcher or a satellite is a set of subsystems built by different teams and suppliers, held together by interfaces: mechanical, electrical, thermal, data. ECSS-E-ST-10-24C, the ECSS standard for interface management, describes how interfaces should be identified, specified in interface requirement and control documents, and controlled through changes.

In many programmes, the interface control documents are files exchanged between teams. When one side changes a connector, a mounting pattern or a power budget, the other side learns about it at the next document release, or at integration.

When interfaces are items in a shared model, with each side's requirements linked to them, a change to an interface immediately shows the subsystems, requirements and tests it affects on both sides. The discovery moves from integration to the day of the change. That is the single largest source of schedule recovery in most hardware programmes.

Supplier scopes without file exchange

NewSpace programmes buy a large share of their hardware. Every exchange with a supplier through email and spreadsheets adds a delay and a chance of mismatch. In Koddex, each supplier works in its own scope of the shared model: it sees the interfaces and requirements for its equipment, updates its own data, and the prime sees the result without a re-entry step. Access rights are set per partner, and every change is recorded with its author.

Keeping verification continuous

Verification is often treated as a phase that starts once design is mostly done. Programmes that move fast treat it as a continuous activity:

• —Each requirement gets its verification method when it is written.
• —Each test and analysis is linked to the requirements it verifies.
• —The verification status is a live view of the model, not a document prepared for each review.

When verification is continuous, reviews become checkpoints instead of milestones that stop the work for weeks. The V-model is still there, with its definition branch and its proof branch; it simply runs in shorter loops.

What AI agents take off the team

The waiting described above is largely made of repetitive work: cross-checking, updating, listing, reconciling. This is the work Koddex agents take on, as teammates rather than tools. A few typical tasks:

• —"A supplier changed the mounting interface of the star tracker. List every requirement and test it affects and draft the change request."
• —"Before the CDR data package, check that every requirement of the propulsion subsystem has a verification method and a linked activity."
• —"Compare the mass budget of the current baseline with the previous one and explain the difference."

The engineer assigns the task, the agent works on a branch, comments on what it found and prepares the update, and the engineer reviews and merges it, the same way a development team reviews a pull request. Agents act within the rights of their account, and every action is recorded. The engineering decisions stay with the engineers.

What the gain looks like

On guided deployments, teams working this way have brought new products to market up to 30% faster, and spent up to half as much time on repetitive engineering tasks. These are observations from deployments, not guarantees: the gain depends on how much of the programme's time is lost today in the gaps between steps. The way to know for your programme is to measure one scope.

Getting started

Pick the place where your programme loses the most time today. For many NewSpace teams, it is one interface between two subsystems, or the verification matrix of one subsystem before a review.

• —Model that interface or that subsystem in Koddex, with its requirements and its verification.
• —Connect the supplier or the other team to the same scope.
• —Run one real change through it and measure how long the impact took to establish.

Learn more about Koddex for space programmes, about requirements management, or about impact analysis on shared data.