papyro

Every spacecraft is built twice.

First in documents. papyro is the documentation platform built for ECSS space engineering projects.

Invited by a colleague? The invitation link signs in directly.

With papyro,  teams author deliverables together with AI, keep every issue under Git version control, and publish them as a readable wiki and as a deliverable PDF at the press of a button, with purpose-built editing tools grounded in the industry standards.

1As engineers, we know the pain:

Dozens of documents.A review gate ahead.Colleagues to chase for their part.The real engineering work still has to go on.So the team works nights and weekends.The review passes. The team needs a holiday.
SRRPDRCDRQRAR
Phase AFeasibilityPhase BPreliminary definitionPhase CDetailed definitionPhase DQualification & productionPhase EOperations
SRR
PDR
CDR
QR
AR
Team capacity
Workload with papyro
Workload
Data package due
over capacity at every review
Feasibility
Preliminary design
Detailed design
AIT & qualification
Handover

[1]  Survey of 24 aerospace engineers at primes, SMEs and NewSpace companies, 2026

2papyro handles the paperwork.
Engineers get back to engineering.

Every document starts pre-written, sections in place.Numbering, identifiers, boilerplate, frontmatter: papyro's job.The AI assistant drafts in seconds.Engineers just correct, review and fill in the blanks.Every change under git version control.
pVerification plan (VP) · papyro×+
‹›↻app.papyro.space/sat-1/documents/vp☆L
papyro›SAT-1 solar array wing›Verification planSAT1-VP-003 · Iss 2 Rev 0
BaselinePDF
1Introduction
2Applicable and reference documents
3Terms, definitions and abbreviations
4Verification subject
4.1Verification levels
4.2Configurations
5Verification approach
6Model philosophy
7Verification strategy
8Verification control
9Verification matrix
4  Verification subject

The subject of this plan is the SAT-1 solar array wing, comprising the yoke, four deployable panels, the hold-down and release mechanism and the deployment hinges. Verification covers the wing in stowed, deploying and deployed configurations, from the qualification model through the proto-flight model.

Table 4-1. Verification subject items
ItemModelLevelReference
Yoke assemblyQM, PFMSubsystemSAT1-SAW-DDF-001
Deployable panelQMUnitSAT1-SAW-DDF-002
Hold-down and release mechanismQM, PFMUnitSAT1-HDRM-ICD-001
Deployment hingeQMUnitSAT1-SAW-DDF-004
4.1  Verification levels

Verification is performed at unit, subsystem and system level as defined in ECSS-E-ST-10-02C, clause 4.3. Table 4-1 assigns each item to its level; the verification matrix in section 9 traces every requirement to the method applied at that level.

4.2  Configurations

The deployed configuration is verified on the qualification model only. Stowed and deploying configurations are verified on both models, the proto-flight model at acceptance levels.

SAT1-VP-003 · Iss 2 Rev 014 / 38
4  Verification subject

The subject of this plan is the SAT-1 solar array wing, comprising the yoke, four deployable panels, the hold-down and release mechanism and the deployment hinges. Verification covers the wing in stowed, deploying and deployed configurations, from the qualification model through the proto-flight model.

Table 4-1. Verification subject items
ItemModelLevelReference
Yoke assemblyQM, PFMSubsystemSAT1-SAW-DDF-001
Deployable panelQMUnitSAT1-SAW-DDF-002
Hold-down and release mechanismQM, PFMUnitSAT1-HDRM-ICD-001
Deployment hingeQMUnitSAT1-SAW-DDF-004
4.1  Verification levels

Verification is performed at unit, subsystem and system level as defined in ECSS-E-ST-10-02C, clause 4.3. Table 4-1 assigns each item to its level; the verification matrix in section 9 traces every requirement to the method applied at that level.

© ACME Space · ProprietaryECSS-E-ST-10-02C DRD
2.1  Explore papyro's power
Pre-written deliverablesEngineers write the argument;
numbering, sections, frontmatter and formatting look after themselves.
AI powered tools assist the teamLISE knows the standards and knows what is expected. LISE audits before your client does.
An intuitive GUI to manage documentationDeliverable Matrix, Timeline, and a project overview help the team stay on track.
WritingDesign justification fileSAT1-DJF-004
Write.Review.Iterate.Release.Manage.Succeed.

3Start where your project stands.

A new project from scratch,or one already halfway to its next review.
01Open a company accountSign in with Microsoft or a code to the work address, and invite the team. Every document lives in the company's own repository, mirrored to its git host if it wants one.
02Set up the projectLay out the deliverable matrix and the timeline. Pick one of papyro's polished templates and customise it to the company's look. It styles every document, unless a document is set to its own.
03Bring the documents you already haveUpload the current issue as Word, PDF or Markdown. papyro converts it into the project, you check the result, and the team keeps writing from there.
DOCXPDFMD
04Enjoy the faster way to writeWrite with colleagues and the AI assistant, with every change tracked in git. Publish a polished PDF and a wiki for the customer and the team to read and reference.
PDFWIKI

4Set up your first data package.

Give the team its engineering hours back. Let papyro carry the documentation work.

Request an early access account