AERNNOVA ENGINEERING DIVISION SA

AERNNOVA ENGINEERING DIVISION SA es una sociedad mercantil constituida en 2009 con domicilio en Araba/Álava, de acuerdo con la ficha registral consultada. El corpus la clasifica dentro del epígrafe genérico "Otros", sin más concreción sectorial.

Según el registro, la sociedad tiene como accionista único a AERNNOVA AEROSPACE SA, que consta como administrador único en el acto de reelección de 4 de agosto de 2020 (BORME). Es, por tanto, una filial íntegramente participada por el grupo Aernnova.

La constitución consta en 2009. Los primeros actos registrales documentados son de 16 de diciembre de 2009 y consisten en nombramientos de apoderados: aparecen, entre otros, Pedro Fuente Arce, Javier del Molino López, Eduardo del Campo González, Francisco José Molas García de Vicuña, María Estibaliz López de Armentia Rincón, José Ignacio Ibarreche Mendia y Luis Francisco Pérez Oliva, así como apoderados mancomunados como Carlos García Hernández, el propio Pérez Oliva, Santiago González Gozalbo, Jesús Ramón Rubio Caja y Eduardo Orbezua Soto (BORME).

El corpus no contiene información sobre el capital inicial, los promotores personas físicas ni las circunstancias concretas de la creación. Estos datos no constan.

La denominación de la sociedad ("Engineering Division") y su integración como filial única de AERNNOVA AEROSPACE SA indican una actividad de ingeniería dentro del grupo, pero el corpus no detalla qué servicios prestaba ni a qué clientes. Esta información no consta en las fuentes disponibles.

Lo que sí consta es la estructura de gobierno: un administrador único (AERNNOVA AEROSPACE SA) y una red amplia de apoderados, algunos mancomunados y algunos solidarios, que el registro va renovando periódicamente. Los nombramientos de 2015, 2019, 2021, 2023, 2024, 2025 y 2026 muestran una estructura de apoderamientos estable y recurrente, propia de una sociedad operativa dentro de un grupo.

El corpus no incluye datos financieros (facturación, resultados, plantilla) de ningún ejercicio. No se puede afirmar nada sobre la evolución económica de la sociedad.

Lo que sí se puede describir es la continuidad registral: la sociedad nombra auditor año tras año —Ernst & Young SL consta como auditor en los nombramientos de 2013, 2021, 2022, 2023, 2024 y 2025 (BORME)—, lo que indica una sociedad obligada a auditar cuentas y con actividad registral sostenida. En 2020 se hace constar que se ha emitido y entregado al accionista único el título múltiple representativo de la totalidad del capital social (BORME, 27 de abril de 2020).

No consta ningún cierre. La ficha registral consultada (OpenMercantil, a partir del BORME) califica la sociedad como activa, y el acto más reciente del corpus es un nombramiento de 9 de julio de 2026. No hay ningún acto de disolución, liquidación o extinción en el corpus.

Cabe advertir, sin embargo, que el corpus mezcla esta sociedad con otra de denominación muy similar, AERNNOVA ENGINEERING SOLUTIONS, S.A, que aparece como "otra empresa con los mismos fundadores". Los datos no permiten atribuir a ENGINEERING DIVISION ningún hecho que corresponda a ENGINEERING SOLUTIONS. Cualquier afirmación sobre un posible cierre o transformación requeriría consultar el registro directamente.

Dado que no consta ningún cierre, no se puede hablar propiamente de herencia de una empresa desaparecida. Lo que consta es la pervivencia de la sociedad dentro del perímetro del grupo Aernnova, con una estructura de apoderamientos que se ha ido renovando hasta 2026.

El corpus no identifica fundadores personas físicas: la sociedad consta como filial de AERNNOVA AEROSPACE SA. Las personas que aparecen son apoderados y representantes, no fundadores en sentido estricto.

De los apoderados que constan, el registro muestra una trayectoria de nombramientos y ceses. Luis Francisco Pérez Oliva, Eduardo Orbezua Soto y María Estibaliz López de Armentia Rincón figuran como apoderados mancomunados en la ficha actual. Eduardo Orbezua Soto aparece también en un nombramiento de 9 de julio de 2026. Ricardo Chocarro Melgosa consta como representante hasta el cese de 11 de febrero de 2026, fecha en que lo sustituye Christopher Grant Skinner (BORME). No consta dónde están hoy estas personas fuera de lo que dice el registro; para saberlo habría que consultar el BORME y las memorias del grupo Aernnova.

• En sociedades de ingeniería integradas en grupos industriales, la continuidad registral (auditoría anual, renovación de apoderamientos) es un indicador más fiable de la actividad que la clasificación sectorial genérica del corpus.
• La coincidencia de denominaciones dentro de un mismo grupo (ENGINEERING DIVISION vs. ENGINEERING SOLUTIONS) obliga a verificar el número de hoja registral antes de atribuir hechos a una sociedad: el corpus las presenta como entidades diferentes.
• En filiales con accionista único, el gobierno se concentra en el administrador único y en una red de apoderados; los cambios de representante (como el de febrero de 2026) son señales de relevo interno que conviene seguir.
• No se puede evaluar el éxito o el fracaso de una sociedad sin datos financieros: cuando el corpus no los aporta, el informe debe decirlo explícitamente en lugar de inferir nada.

Reconstruir una divisió d'enginyeria aeronàutica amb seu a Àlaba, hereva de l'experiència d'Aernnova Engineering Division SA (constituïda el 2009, segons la fitxa registral d'OpenMercantil/BORME). La idea no és reobrir la societat original —que consta activa— sinó crear una estructura nova que presti serveis d'enginyeria de disseny, càlcul i suport tècnic a la cadena aeronàutica del País Basc.

Proposta (no dada verificada): una enginyeria petita i especialitzada (10-25 persones) que ofereixi serveis de disseny CAD/CAE, certificació i suport a programes aeronàutics, aprofitant el teixit industrial d'Àlaba i la proximitat al clúster aeronàutic basc.

La fitxa registral confirma que la societat original tenia estructura corporativa formal: administrador únic (AERNNOVA AEROSPACE SA, acte de 2020), apoderats mancomunats i solidaris des de 2009, i auditoria d'Ernst & Young de manera recurrent (2013, 2021, 2022, 2023, 2024, 2025). Això indica una activitat amb volum suficient per exigir auditoria.

A validar: la mida real del mercat d'enginyeria aeronàutica a Àlaba i el País Basc, els clients potencials i la competència. No tinc dades verificades de facturació, plantilla ni cartera de clients, i no les inventaré.

Proposta: model de serveis tècnics per hores-projecte i contractes marc amb integradors aeronàutics, amb tres línies:

1. Enginyeria de disseny i càlcul (CAD/CAE).
2. Suport a certificació i documentació tècnica.
3. Projectes d'enginyeria a mida per a Tier 1/Tier 2.

Estimació (a validar): marge brut objectiu del 25-35%, amb facturació per hora tècnica com a base i contractes de dedicació parcial com a palanca de recurrència.

Proposta de fases (a validar):

• Fase 0 (mesos 0-3): constitució de la nova societat, definició de l'oferta i identificació de 10-15 clients potencials.
• Fase 1 (mesos 3-9): equip fundacional de 3-5 enginyers, primers contractes pilot.
• Fase 2 (mesos 9-18): ampliació a 10-15 persones si es validen els primers contractes.
• Fase 3 (mesos 18-36): consolidació i possible especialització en un nínxol.

Estimació (rang a validar, no dada verificada):

• Constitució i estructura legal: 3.000-8.000 €.
• Equip fundacional (3-5 persones, 12 mesos): 250.000-450.000 € en costos de personal.
• Eines de programari (CAD/CAE, llicències): 15.000-40.000 €/any.
• Oficina a Àlaba: 20.000-40.000 €/any.
• Màrqueting i comercial: 10.000-20.000 €.
• Total orientatiu any 1: 300.000-550.000 €, a validar amb pressupostos reals.

• Risc de confusió registral: la fitxa diu "Hostelería" com a sector, cosa que no encaixa amb el nom ni amb l'activitat aparent. Cal aclarir-ho abans de qualsevol pla.
• Risc de marca: el nom "Aernnova" està lligat a un grup existent; una nova societat no hauria d'usar-lo sense acord.
• Risc de mercat: dependència de pocs clients aeronàutics i cicles llargs de contractació.
• Risc financer: el període de maduració pot superar els 18 mesos estimats.

Lliçons de l'informe original (no currículum): la societat original va funcionar amb una estructura de govern clara —administrador únic i una xarxa àmplia d'apoderats mancomunats i solidaris— i amb auditoria externa recurrent. La lliçó per a una reconstrucció és que cal un nucli de decisió definit, apoderats amb mandats clars i control financer extern des del primer any. El perfil idoni és un equip d'enginyers amb experiència aeronàutica i un soci amb capacitat comercial i financera, no un sol fundador.

--- Nota: totes les xifres d'aquest informe són estimacions o propostes marcades com a tals; no provenen de dades verificades de l'empresa. La font registral és OpenMercantil/BORME (fitxa i actes citats).

La ficha registral mostra una societat amb un òrgan d'administració i un conjunt gran i canviant d'apoderats (mancomunats i solidaris) que es renoven any rere any: el 2009, 2010, 2015, 2019, 2021, 2023, 2025 i 2026 hi ha nomenaments i cessions de poders [BORME / BOE via OpenMercantil, 2026-07-09]. Quan una divisió d'enginyeria es reabsorbeix o es dissol, els qui signaven els lliuraments tècnics (plànols, informes de càlcul, configuracions de peça) ja no hi són, i el client queda sense traçabilitat de qui va aprovar què i amb quina autoritat.

El producte és un registre de configuració d'enginyeria amb autoritat delegada: cada lliurament tècnic té una versió immutable, un conjunt d'aprovadors vàlids en el moment de l'aprovació (extrets dels poders vigents), i un paquet d'exportació que es pot lliurar al client o a un auditor encara que l'empresa hagi desaparegut. El motiu de fer-ho així: el risc real no és perdre els fitxers, és perdre la cadena d'autoritat que els fa vàlids contractualment.

Tres components, tots desplegables en un sol núvol europeu (requisit habitual en contractes aeronàutics):

1. Servei d'API (REST, Node/TypeScript o Go) — lògica de versions, aprovacions i exportació. Sense estat; escala horitzontalment.
2. Postgres 16 — font de veritat. Taules de documents, versions, aprovacions i poders. Les versions i aprovacions són append-only (només insercions, mai updates ni deletes), garantit amb permisos de rol i triggers.
3. Magatzem d'objectes S3-compatible — fitxers binaris (PDF, STEP, plànols) amb object lock en mode compliance per a les versions aprovades. El motiu: un cop aprovada una versió, ni l'administrador del sistema la pot esborrar.

Flux d'una aprovació: ``` client → API POST /deliverables/{id}/versions (puja fitxer, crea versió DRAFT) → API POST /versions/{vid}/approvals (registra aprovació d'un usuari) → API valida que l'usuari té poder vigent per al tipus de lliurament → API escriu fila immutable + segella hash SHA-256 del fitxer → object lock al fitxer → API GET /deliverables/{id}/export (paquet ZIP + manifest signat) ``` El manifest d'exportació inclou el hash de cada versió, la llista d'aprovadors amb el seu poder i la data de vigència, i una signatura del servei. Això permet verificar el paquet fora del sistema, cosa que és el punt: el client no ha de dependre que el sistema segueixi viu.

Esquema mínim (Postgres):

```sql -- Poders delegats, importats del registre o introduïts manualment CREATE TABLE authority ( id uuid PRIMARY KEY, person_name text NOT NULL, role text NOT NULL, -- 'apoderado_mancomunado' | 'apoderado_solidario' | ... scope text NOT NULL, -- tipus de lliurament que pot aprovar valid_from date NOT NULL, valid_to date, -- NULL = vigent source_ref text, -- referència BORME created_at timestamptz NOT NULL DEFAULT now() );

CREATE TABLE deliverable ( id uuid PRIMARY KEY, program_code text NOT NULL, -- p.ex. 'A350-WING' part_number text NOT NULL, title text NOT NULL, created_at timestamptz NOT NULL DEFAULT now() );

CREATE TABLE version ( id uuid PRIMARY KEY, deliverable_id uuid NOT NULL REFERENCES deliverable(id), seq int NOT NULL, object_key text NOT NULL, -- clau S3 sha256 bytea NOT NULL, state text NOT NULL, -- 'DRAFT' | 'APPROVED' | 'SUPERSEDED' created_at timestamptz NOT NULL DEFAULT now(), UNIQUE (deliverable_id, seq) );

CREATE TABLE approval ( id uuid PRIMARY KEY, version_id uuid NOT NULL REFERENCES version(id), authority_id uuid NOT NULL REFERENCES authority(id), approved_at timestamptz NOT NULL DEFAULT now(), signature bytea NOT NULL -- signatura del manifest ); ``` Decisions i motius:

• `authority` és una taula pròpia i no un camp de l'usuari perquè els poders canvien (la cronologia del registre ho mostra) i una aprovació ha de referenciar el poder vigent en aquell moment, no l'actual.
• `version` i `approval` són append-only; el pas a `SUPERSEDED` es fa amb una taula d'estat separada o un camp que només pot avançar, per no trencar la immutabilitat.
• `sha256` desacobla la integritat del fitxer de la disponibilitat del magatzem.

• `POST /deliverables` — crea un lliurament.
• `POST /deliverables/{id}/versions` — puja fitxer, retorna `version_id` i hash.
• `POST /versions/{vid}/approvals` — cos: `{ authority_id, signature }`. Valida vigència i abast; retorna 409 si el poder no cobreix el tipus.
• `GET /deliverables/{id}/export` — genera ZIP amb fitxers, manifest JSON i signatura; idempotent.
• `GET /authorities?at=YYYY-MM-DD` — consulta de poders vigents en una data (útil per a auditories).

Integracions:

• Importador BORME (opcional, fase 2): un job que llegeix els PDFs de nomenaments i cessions i proposa files a `authority` per a revisió humana. Motiu: la font de poders és el registre, i automatitzar-lo redueix l'error de transcripció; però sempre amb aprovació humana perquè un poder mal importat invalida l'exportació.
• Webhook de sortida cap al PLM del client (p. ex. Teamcenter) quan una versió passa a `APPROVED`.

1. Registre immutable de versions + hash + object lock. És el nucli; sense això no hi ha producte.
2. Taula d'autoritat i validació d'aprovacions. És el que diferencia el producte d'un simple gestor documental.
3. Exportació amb manifest signat. És el lliurable que el client pot conservar; valida tot el model.
4. Importador BORME i webhook PLM, després.

Ordre motivat: cada fita és verificable de manera independent i la 3 demostra el valor sense necessitat d'integració externa.

• Volum: un programa aeronàutic típic genera centenars de lliuraments i milers de versions; Postgres ho absorbeix sense partició fins a desenes de milions de files. El coll d'ampolla és el magatzem d'objectes (mida de STEP/PDF), no la base de dades.
• Risc 1 — importació de poders errònia: un poder mal transcrit fa que una aprovació sembli vàlida quan no ho és. Mitigació: revisió humana obligatòria i registre de qui va importar cada fila.
• Risc 2 — clau de signatura del servei: si es perd, els manifests antics no es poden verificar. Mitigació: clau en KMS amb còpia de recuperació i rotació documentada.
• Risc 3 — dependència del proveïdor de núvol: mitigat perquè l'exportació és autònoma i verificable fora del sistema.
• Risc 4 — abast de poders ambigu: el registre diu «apoderat mancomunat» però no sempre el límit material. Mitigació: el camp `scope` és obligatori i s'ha de configurar per programa; si falta, l'aprovació es bloqueja.

• Test d'immutabilitat: intentar modificar o esborrar una versió aprovada ha de fallar a nivell de base de dades i de magatzem; test automatitzat que ho comprova.
• Test d'autoritat: una aprovació amb un poder caducat o fora d'abast ha de retornar 409; test amb dates simulades al voltant dels canvis de poders documentats al registre.
• Test d'exportació: verificar el manifest signat amb la clau pública del servei, de manera independent, i comprovar que el hash de cada fitxer coincideix.
• Prova d'acceptació amb un client: lliurar un paquet exportat a un auditor extern i que aquest el validi sense accés al sistema. Aquesta és la validació definitiva del producte.