La piattaforma
Ogni applicazione svolge una parte del lavoro — e passa le sue evidenze alla successiva. Usale insieme, o una alla volta.
Panoramica della piattaformaScopri come funziona il cicloOrchestrazione
DjiniousEngineeringOrchestrazioneProgettazione e dimostrazione
DjiniousLabModellazione e simulazione
DjiniousWorkshopIntegrazione di sistema
DjiniousSafeCodice certificabileOperatività
DjiniousCCOperatività e SCADADjiniousEngineeringOrchestrazioneDjiniousLabModellazione e simulazioneDjiniousWorkshopIntegrazione di sistemaDjiniousSafeCodice certificabile
DjiniousWorldRepliche 3D
DjiniousMapGIS ad agentiDjiniousCCOperatività e SCADA
DjiniousDataBase di conoscenza
DjiniousWorkflowAutomazione ad agenti
DjiniousEngineeringOrchestrazioneDjiniousEngineering è un ingegnere di sistema IA. Consegnagli una manciata di specifiche e porta il sistema fino a un pacchetto dati per la produzione o il deployment — derivando requisiti, confrontando architetture, dimensionando il progetto e chiudendo la verifica. Ogni progetto è un System Ledger: il filo digitale, lavorato fase per fase, e fermato a ogni gate di revisione per una persona.
DjiniousEngineering
Cos’è
Tutto ciò di cui il ciclo di vita ha bisogno, in un unico prodotto con un unico modello dati — così non c’è cucitura tra il requisito che derivi, il componente a cui è allocato, e la verifica che lo chiude.
Il filo digitale come undici colonne di fase. Ogni elemento porta con sé un tipo di artefatto, una classe di evidenza, una revisione e uno stato di validazione; revisionarne uno segna come obsoleto tutto ciò che sta a valle.
ISO/IEC/IEEE 15288Requisiti derivati dai bisogni, allocati sui componenti, approvvigionati da fornitori, e chiusi dalla verifica — tutti come archi di grafo che puoi percorrere, non collegamenti mantenuti a mano.
ISO/IEC/IEEE 29148Un unico modello verificabile automaticamente dell’intero sistema lungo quattro pilastri e ventisette tipi di entità, verificato rispetto a ventisei regole di buona formazione, con i suoi scostamenti elencati.
Conformità L0–L3Cinque gate che l’agente valuta ma che solo una persona può superare. Ognuno blocca l’esecuzione finché gli elementi a monte non sono validati dall’utente e i criteri non sono soddisfatti.
SRR · PDR · CDR · TRR · PRRUna distinta base con make-or-buy, tempi di consegna, fonti alternative e rischio, che raggiunge la libreria componenti condivisa — perché il CDR non passa senza una fonte qualificata su ogni componente.
Make-or-buyL’artefatto di rilascio — baseline, procedure ed evidenze — generato dal ledger validato ed esportato come pacchetto di documenti, non redatto a parte.
Generato dal filoDentro al prodotto
Ogni schermata qui sotto è il prodotto in esecuzione.
01 · System Ledger
Ogni progetto è un System Ledger — il filo digitale che contiene la Baseline Tecnica e il Pacchetto dati tecnico di un sistema. Non documenti in cartelle condivise, ma elementi tipizzati collegati da archi produces: undici fasi del ciclo di vita ISO/IEC/IEEE 15288, ogni elemento con il proprio tipo di artefatto, classe di evidenza, revisione e stato di validazione. Segui gli archi e hai l’intera catena: i bisogni producono requisiti, i requisiti producono componenti, i componenti producono fornitori, e la verifica chiude l’anello.
DjiniousEngineering
02 · Classi di evidenza
Un’affermazione vale solo quanto ciò che la sostiene. Ogni valore sul ledger porta con sé una classe di evidenza su una scala ordinata, dalla più forte alla più debole. Un requisito dichiara il metodo di verifica che richiede, e il ledger si rifiuta di chiuderlo su un’evidenza più debole di quanto quel metodo consenta. Non puoi chiudere un requisito MEASURED su JUDGMENT, e un valore ancora marcato UNKNOWN blocca tutto ciò che dipende da esso.
DjiniousEngineering
03 · Il modello ELANG
ELANG — l’Engineering Language for Artifacts, Processes, and Governance — è un unico modello dichiarativo dell’intero sistema, redatto nell’app in un editor CodeMirror come elemento system_model. Viene verificato rispetto alle regole di buona formazione e riportato a un livello di conformità con gli scostamenti esatti che lo trattengono, non un semplice segno di spunta verde.
DjiniousEngineering
04 · I gate di revisione
L’agente propone elementi fase per fase e poi si ferma. A ciascuno dei cinque gate di revisione ISO 15288 può solo presentare il lavoro a monte; una persona convalida l’evidenza e lo lascia passare. Questi sono i veri criteri di accettazione che il ledger verifica prima ancora che un gate venga offerto per la validazione — ed è ciò che impedisce a un’esecuzione autonoma di progettare sopra una baseline non revisionata.
05 · Supply chain
La fase di supply chain trasforma un’architettura in una distinta base con make-or-buy su ogni riga. I componenti vengono attinti dalla libreria componenti raggiunta tramite il connettore DjiniousWorkshop, ciascuno con una fonte qualificata, una fonte alternativa e un tempo di consegna — che è esattamente ciò che il gate di Critical Design Review verifica.
DjiniousEngineering
06 · Deliverable
Poiché ogni elemento è tipizzato, tracciato e validato, i deliverable vengono generati dal ledger anziché redatti a parte. A Baseline Release l’intero filo si compila in un Pacchetto dati tecnico — completo e internamente coerente, che è precisamente ciò che il gate di Production Readiness Review richiede prima di aprirsi.
DjiniousEngineering
IA e agenti
L’agente legge il ledger, lavora una fase alla volta rispetto a una recipe ed emette un singolo elemento tipizzato per passo. Ciò che non può fare è superare un gate di revisione da solo — si ferma a ogni gate finché una persona non ha convalidato l’evidenza a monte, applicato lato server a ogni passo. L’IA è un acceleratore, mai una dipendenza: imposta ogni classe di strumento su deny e la stessa revisione umana chiude comunque gli stessi gate.
Il bisogno di missione viene prima ancorato: cosa deve fare il sistema e in quali condizioni deve farlo. Da esso l’agente deriva requisiti singolari e verificabili e assegna a ciascuno un metodo di verifica — niente entra nel filo che non possa poi essere chiuso rispetto a un’evidenza.
I concetti candidati vengono confrontati, viene scelta un’architettura, e il ciclo di dimensionamento gira finché non converge con margine positivo rispetto a ogni vincolo rigido. Il risultato viene catturato come un unico modello ELANG verificabile automaticamente, verificato rispetto alle sue regole di buona formazione.
I requisiti vengono chiusi rispetto a un’evidenza, mai a un’affermazione. Niente chiude un requisito su JUDGMENT quando il suo metodo di verifica richiede MEASURED, e una classe UNKNOWN blocca la chiusura senza appello. La replica digitale viene correlata rispetto ai modelli che dichiara di rappresentare.
Una persona rivede la proposta e l’evidenza che la sostiene, poi convalida o respinge. Solo gli elementi user_validated contano come contratti adempiuti — l’agente non può portare una baseline non revisionata oltre un gate.
L’autonomia è una policy sulle classi di strumento: read, write e browser, ciascuna impostata indipendentemente su ask, allow o deny. Il valore predefinito è ask — una chiamata che richiede approvazione viene instradata a una coda umana.
Qualsiasi chiamata a uno strumento che la policy invia ad ask viene instradata a una coda di approvazione umana prima di essere eseguita. Niente aspetta per sempre: una chiamata lasciata senza approvazione viene respinta automaticamente dopo cinque minuti.
Gli strumenti lavorano direttamente sul ledger — leggerlo, trovare il passo successivo, verificare un gate, accodare un elemento, sostituirne uno con una motivazione scritta, tracciare un requisito — con il ragionamento e le chiamate agli strumenti trasmessi live.
DjiniousEngineering
Funzionalità
Requisiti, trade-off, architettura, modelli, sicurezza, supply chain e verifica qui non sono sette documenti — sono un unico filo tracciato con un unico modello dati.
Undici fasi che prendono il nome dai processi ISO/IEC/IEEE 15288, da Mission & Need a Production & Operation.
Cinque gate validati da una persona, dopo Requirements, Engineering Models, Supply Chain, Verification & Validation e Baseline Release.
Trenta output di elementi tipizzati, da spec_brief a technical_data_package.
Otto classi ordinate — MEASURED → … → JUDGMENT → UNKNOWN; UNKNOWN blocca la chiusura.
Insiemi di istruzioni per classe di sistema che gli agenti eseguono, estendendo la baseline generica ISO 15288 con input, output, regole di evidenza e asserzioni automatizzate espliciti.
Quattro pilastri, ventisette tipi di entità, un’unica sorgente verificabile automaticamente.
Ventisei WFR, livelli di conformità L0–L3 con un elenco di scostamenti.
derives_from · allocated_to · satisfies · verifies · supplied_by.
Archi produces su un DAG; obsolescenza propagata in avanti a ogni modifica.
Architetture candidate confrontate su criteri espliciti e pesati, con una decisione registrata e i requisiti allocati sui componenti che li implementano.
Guidato da recipe su pi-agent-core, un elemento per passo, si ferma a ogni gate.
Per classe di strumento — read, write, browser — ciascuna impostata su ask, allow o deny.
Una coda di approvazione umana per le chiamate soggette a gate; una persona convalida ogni gate.
Un endpoint MCP di circa trenta strumenti più REST, dietro chiavi API con ambito.
Bun · React 19 · TypeScript.
SurrealDB — grafo, vettori e full-text in un unico store.
JWT (OIDC) più token API di lunga durata con ambito.
admin · user · viewer.
Un unico punto autenticato per raggiungere DjiniousLab, Workshop, Safe, World, Map e CC.
Fiducia
DjiniousEngineering è API-first e self-hostabile. Ogni capacità è un endpoint REST, l’intero System Ledger è esposto tramite un unico endpoint MCP, e ogni elemento sul filo digitale porta con sé una revisione, uno stato di validazione e l’evidenza rispetto a cui è stato chiuso.
L’agente lavora il ledger fase per fase e si ferma a ogni gate di revisione finché gli elementi a monte non sono validati dall’utente rispetto a criteri espliciti. Propone; una persona convalida. Nessun gate si supera da solo.
SRR · PDR · CDR · TRR · PRROgni elemento si muove da draft → proposed → agent_validated → user_validated, porta con sé una revisione, e nomina il proprio tipo di artefatto. agent_validated significa in attesa di una persona; user_validated è la firma della persona sul record.
Sostituire un elemento richiede una motivazione scritta, e modificarne il contenuto segna come obsoleto tutto ciò che è raggiungibile in avanti lungo gli archi produces — così niente poggia silenziosamente su una fondazione spostata.
Un requisito non può chiudersi su un’evidenza più debole di quanto il suo metodo di verifica richieda — UNKNOWN blocca la chiusura senza appello. I ruoli sono admin, user e viewer, con una policy di autonomia per utente su ciò che l’agente può fare senza supervisione.
Le undici fasi prendono il nome dai processi ISO/IEC/IEEE 15288, i requisiti seguono ISO/IEC/IEEE 29148 e l’architettura segue ISO/IEC/IEEE 42010. Il Pacchetto dati tecnico è l’artefatto di rilascio, non un ripensamento aggiunto alla fine.
ISO/IEC/IEEE 15288 · 29148 · 42010La stessa API REST usata dal front end del prodotto è quella su cui costruisci. Il ledger è esposto tramite un unico endpoint MCP di circa trenta strumenti, e la CLI dje guida l’agente direttamente da un terminale, così un’esecuzione appartiene a una pipeline con la stessa facilità con cui appartiene al browser.
REST · MCP · CLIUno stack Docker Swarm — l’applicazione Bun su React 19, sostenuta da SurrealDB per grafo, vettori e full-text in un unico store — dietro il tuo reverse proxy. I tuoi dati e il tuo filo restano sulla tua infrastruttura.
Docker SwarmL’autenticazione è JWT su OIDC; token API con ambito e lunga durata mettono in sicurezza l’automazione. Le credenziali dei connettori e altri segreti sono sigillati a riposo con AES-256-GCM e non vengono mai restituiti al browser — niente condivide una chiave unica per tutto.
AES-256-GCMNon predice né prevede: il ledger registra ciò che è stato stabilito e con quale forza. L’agente non supera mai un gate da solo. E un requisito il cui sostegno è ancora UNKNOWN non può essere chiuso — un’evidenza debole viene lasciata visibile come tale invece di essere promossa per far sembrare pronto un gate.
Nel filo digitale
DjiniousEngineering svolge la propria parte del ciclo di ingegneria e trasmette le proprie evidenze — e funziona altrettanto bene anche da sola.
Riceve
DjiniousDataLe specifiche, gli standard e i documenti sorgente su cui si fonda il bisogno dell'incarico, come conoscenza governata e ricercabile.DjiniousLabModelli numerici, esecuzioni del solver e codice generato, che arrivano sul Ledger come evidenze con la loro provenienza intatta.DjiniousWorkshopComponenti dalla libreria di componenti condivisa, integrazione di sistema e risultati delle simulazioni Isaac Sim.DjiniousSafeCodice safety-critical verificato formalmente per gli elementi che devono essere dimostrati, non solo testati.DjiniousWorldModelli 3D, mock-up e repliche digitali del sistema e del suo contesto.DjiniousMapDati geografici per l'ambiente operativo.DjiniousCCSupervisione SCADA e operatività della replica digitale una volta che il sistema è in esercizio.DjiniousEngineeringOrchestrazioneConsegna
DjiniousLabIl lavoro di modellazione di ogni fase: il sistema da rappresentare, con i requisiti e i parametri rispetto ai quali deve essere testato.DjiniousWorkshopL'architettura e la distinta base da integrare in un sistema completo e chiudere in simulazione.DjiniousSafeLe funzioni safety-critical e i requisiti che il loro codice verificato deve soddisfare.DjiniousWorldLe richieste di replica e mock-up da cui dipende la fase Replica digitale.DjiniousMapL'ambiente operativo che ogni progetto ha bisogno di vedere descritto.DjiniousCCLa baseline rilasciata e il Technical Data Package rispetto ai quali il sistema distribuito viene gestito in esercizio.Da sola, DjiniousEngineering è una piattaforma completa di systems engineering: il System Ledger, requisiti e tracciabilità, il modello ELANG, gate di revisione, supply chain e il Technical Data Package in un unico prodotto con un unico modello dati. I connettori sono opzionali; il Ledger e i suoi gate funzionano anche senza.
Modello commerciale
DjiniousEngineering è concesso in licenza per programma — un’organizzazione, una pratica ingegneristica — senza nulla che, al suo interno, sia misurato a consumo. Nessun costo per requisito, nessuna tariffa per progetto, nessun conteggio di postazioni, nessun tetto sulle esecuzioni degli agenti o sulle app connesse. Nessuno dovrebbe razionare i requisiti o chiudere un progetto a causa di una licenza.
Un’unica licenza copre la pratica ingegneristica della tua organizzazione, non un singolo progetto. Ogni System Ledger che apri, ogni elemento del ledger che i tuoi agenti redigono, ogni modello ELANG che verifichi e ogni gate che una persona convalida è incluso in essa.
Non esiste un listino prezzi, perché il numero dipende dal tuo programma. Il prezzo si definisce nella call — porta il tipo di sistemi che progetti, un'idea di quanti progetti e ingegneri, e se lo vuoi self-hosted o gestito.
Casi d’uso
5 casi documentati.
Autonomia subacqueaAUV Marlin-XR per rilievo del fondale marinoUn veicolo sottomarino autonomo che rileva il corridoio del cavo di esportazione del parco eolico offshore di Dogger Bank. Il ledger dimostrativo incluso: quaranta elementi seminati in tutte e undici le fasi del ciclo di vita, dal brief di missione alla procedura di dispiegamento.DjiniousEngineeringAeromobile senza equipaggioUAV di rilievo Kestrel-1Un UAV di rilievo ad ala fissa, seminato come caso documentato: otto requisiti, sei componenti, quattro fornitori e quattro verifiche, cablati in un grafo di tracciabilità, con un vero system_model ELANG e un Technical Data Package inline.DjiniousEngineering
Robotica industrialeCella di lavoro robotica KronosUna cella di lavoro robotica a sei assi modellata end-to-end in ELANG come riferimento sottoposto ad audit — circa mille righe che portano un design di sicurezza funzionale conforme a ISO 13849-1 Performance Level d, con ogni salvaguardia tracciata fino al pericolo che mitiga.DjiniousEngineeringEnergia su scala di reteImpianto solare con accumulo SunnyGrid80Un impianto fotovoltaico da 80 MW con un sistema di accumulo a batteria da 40 MW / 80 MWh e la sua sottostazione di rete, modellato in ELANG come riferimento sottoposto ad audit rispetto a UL 9540A e IEC 62443 — un sistema di sistemi in cui le interfacce portano tanto design quanto i blocchi stessi.DjiniousEngineeringRilevamento RF e radarModulo radar embeddedUn modulo radar embedded — la classe di sistema coperta dalla ricetta RF/radar: una scheda a segnale misto in cui gli standard di spettro, EMC, ambientali e di fabbricazione vincolano il design tanto quanto il requisito di rilevamento.DjiniousEngineeringPrenota una demo
Una sessione di lavoro, non un mazzo di slide. Portaci un sistema — poche specifiche e un requisito a cui tieni davvero — e lo portiamo attraverso il Ledger: inquadriamo il bisogno, deriviamo requisiti verificabili, costruiamo il modello ELANG e attraversiamo un gate di revisione, dal vivo. Oppure ti diciamo chiaramente quale parte DjiniousEngineering non fa ancora.
Lungo il filo
DjiniousLabModellazione e simulazioneModelli di sistema multi-dominio, repliche digitali e una cassetta degli attrezzi matematica, guidati dall’IA.
DjiniousWorkshopIntegrazione di sistemaComponenti collegati in un sistema completo e chiusi in anello tramite la fisica GPU in NVIDIA Isaac Sim.
DjiniousSafeCodice certificabileSpecifiche Lean 4 e dimostrazioni verificate dal kernel trasformate in Rust embedded privo di panic, fino a SIL 4.
DjiniousWorldRepliche 3DAmbienti reali ricostruiti da LiDAR, fotografie e video — il contesto fisico del gemello.
Djinious