UTXOSUITE — home
LABS / BUILD-ORGANISATION

Getrennte Disziplinen. Gemeinsame Delivery-Regeln.

Labs erklärt die Organisation um UTXO Suite und Sibling Systems, ohne Teamgröße, externe Review oder Production Readiness zu zertifizieren.

BUILD UNITS

Infrastruktur und Applied Software bleiben unterscheidbar.

UTXO Labs Team und Idovio Team können zusammenarbeiten und unterschiedliche Scopes behalten; das bedeutet nicht, dass jede Capability shipped ist.

UNIT 01

UTXO Labs Team

UTXO Labs Team fokussiert Protocol, Security, Transaction Analysis, Routing und Systems Research; in UTXO Suite zeigt sich das in SafeSign und Security Core.

TRANSACTION SECURITY
SYSTEMS / PROTOCOL RESEARCH
ROUTING / ANALYSIS
UNIT 02

Idovio Team

Idovio Team fokussiert Application- und Product-Software. Sibling Apps und Experimente bleiben vom Kernversprechen getrennt.

APPLICATION SOFTWARE
PRODUCT ENGINEERING
SIBLING SYSTEMS
DELIVERY-DISZIPLIN

Status ist Teil der Architektur.

Research, Scaffold, Prototype, Integrated Surface und Production Release sind unterschiedliche Stufen.

RULE 01

LOCAL-FIRST

LOCAL-FIRST WO PRAKTISCH — sensible Analyse und Einstellungen bleiben auf dem Gerät.

RULE 02

NON-CUSTODIAL

NON-CUSTODIAL — Request-Erklärung braucht keine Private-Key-Custody.

RULE 03

EXPLICIT AUTHORIZATION

EXPLIZITE AUTORISIERUNG — Nutzer/Wallet bleibt Signing Boundary.

RULE 04

EVIDENCE-LED STATUS

EVIDENCE-LED STATUS — starke Labels nur mit realem Nachweis.

Research öffnenProjects öffnen
BETRIEBSMODELL

Arbeit durch explizite Engineering-Gates führen.

Research→Production explizit machen: Artefakte, Security Boundaries und Status müssen gemeinsam voranschreiten.

01 / DISCOVERY

DISCOVERY

Userproblem, Threat Model und Elemente außerhalb der Trust Boundary definieren.

02 / SPECIFICATION

SPECIFICATION

Invarianten, unterstützte Inputs, Failure Behavior und Negative Tests vor Implementierung schreiben.

03 / VALIDATION

VALIDATION

Positive, negative, adversariale und Regression-Fixtures vor Status-Upgrade ausführen.

REIFEGRAD-GATES

Status wird Release-Kontrolle statt Marketing-Adjektiv.

Research→Production explizit machen: Artefakte, Security Boundaries und Status müssen gemeinsam voranschreiten.

STAGE
ARTIFACT / INPUT
EVIDENCE / MEANING
OUTPUT
RESEARCH
problem + hypothesis
Richtung existiert; Implementierung wird nicht impliziert.
RESEARCH
SCAFFOLD
source + checks
Code existiert, reale Integration kann unvollständig bleiben.
SCAFFOLD
RELEASE
validation + ops
Release-Artefakt, Rollback-Pfad und operative Evidenz existieren.
RELEASE
RELEASE RECORD
{
  "surface":"guard",
  "stage":"integrated",
  "required":["real provider flow","negative fixtures","payload-integrity test"],
  "publicLabel":"BETA"
}
SECURITY GATE
{
  "privateKeyCustody":false,
  "autoSign":false,
  "payloadMutation":"forbidden",
  "unsupportedInput":"visible failure"
}
LABS RULE

Eine polierte UI kann vor vollständigem Backend existieren, aber der öffentliche Status muss den Unterschied exakt beschreiben.