Own it.Run it.Prove it.

The films load only when you start a film and consent in the window that follows. Before that, no data is sent to YouTube (youtube-nocookie.com). Details are in the privacy policy.

• No army of consultants.

  Domain models are built in the interface, without program code. Your specialist department creates objects, relations and rules itself and maintains them later.

• Check before anything happens.

  The prover rejects classification errors, the plan coach reports what is missing in the crisis plan. Both by fixed, traceable rules.

• One change applies everywhere.

  Views, documents and reports are generated from the data. Change the model and everything that follows changes with it.

• Provable.

  Every change is a chained event. Who changed what and when can be proven.

• Local, no cloud.

  Defconder runs on your infrastructure. Data and models never leave your house.

• A world instead of a map.

  Terra is a world you can enter, where you set weather, time and outages and play through the effects.

All films show invented exercise data, in the vector space film on technical texts our own texts. The voices are synthetic (Piper). Defconder is under development, not approved and not legally reviewed. As of 24 October 2026.

Defconder

Example from a real file: Cologne city centre with the LoD2 3D building model and the aerial imagery of North Rhine-Westphalia (Geobasis NRW, Data Licence Germany Zero 2.0). For buildings without a footprint in the model, such as the cathedral, the outline is simplified from the hull.

Defconder

Left real data: Berlin on the aerial imagery of Brandenburg (GeoBasis-DE/LGB, dl-de/by-2-0) with the drone geozones of the DFS (dipul, CC BY-ND 4.0, unaltered) as walls. Heights are shown as given in the data, terrain is not included. Right the alert card of the interface with two test messages over the airport and the city centre, fed in through the Cursor-on-Target input.

• 0federal states with an aerial imagery service in the catalogue, each checked with a real tile
• 0sectors by which buildings are coloured from their official use
• 0buildings of a real LoD2 tile (56 MB CityGML), read in about four seconds
• 0building functions of the official code list from which the sectors are derived

• Buildings with real height

  CityGML and CityJSON from the land surveying offices are read in the server, converted to world coordinates and drawn as 3D bodies. The height comes from the measured values in the data. Tilted view with one click, rotate and tilt with the right mouse button.

• Surroundings by sector

  From the building function in the official data, Defconder assigns buildings to seven sectors: health, education and care, supply and disposal, state and administration, security and rescue, transport, and culture and religion. All other buildings recede in grey.

• Aerial imagery from all 16 states

  Baden-Württemberg, Bavaria, Berlin, Brandenburg, Bremen, Hamburg, Hesse, Mecklenburg-Vorpommern, Lower Saxony, North Rhine-Westphalia, Rhineland-Palatinate, Saarland, Saxony, Saxony-Anhalt, Schleswig-Holstein and Thuringia. Licence and attribution stay visible. For Hamburg the catalogue shows the latest vintage of the time series of the state survey office (Landesbetrieb Geoinformation und Vermessung).

• Viewshed and water level

  From an uploaded elevation model Defconder computes from where a point can be seen and which areas an assumed water level covers. These are scenarios without a forecast and without water depth.

• Relief and labels

  An uploaded elevation model appears as a real 3D relief. Maps from Protomaps data carry place, street and water names, set with built-in open fonts (Noto Sans, SIL OFL). The relief replaces the chosen map, the interface does not yet show both at once.

• Maps under your own control

  Your own server delivers tiles, files and fonts, every request is checked against the user's clearance. Your own maps run from MBTiles, PMTiles, GeoPackage, GeoTIFF, CityGML and CityJSON without internet. Only the DFS geozones and the online aerial imagery need a connection, and that can be switched off on the server.

• Positioning interference from the air picture

  Aircraft report in ADS-B how accurately they know their position. Per area of about 1,900 square kilometres Defconder counts how many report at least 185 metres of uncertainty, as a 15-minute sliding window, with and without a filter for older equipment. This is an indication of disturbed satellite reception and not proof. The data comes from adsb.lol.

• Drone geozones as walls

  The zones of the German air navigation service (dipul) stand in the map with their height values as translucent walls, on click also as filled bodies: control zones, flight restriction areas, airports, airfields and temporary restrictions. Where the data names no upper limit, as with airfields, the area stays flat. Zones are shown unaltered and retrieved live, so the server needs internet.

• Alert when a track enters a zone

  Every 15 seconds the server checks whether a track from sensors, Remote ID or other inputs lies in a zone, by position and, where the data allows, by height. The alert is an event in the log and, if set up, goes to e-mail and webhook. Pure ADS-B tracks do not count, they fly through control zones as planned. Height is compared with a 50 metre tolerance because sources report sea level and ellipsoid height differently.

As of 7 October 2026. Limits: the relief works only with an uploaded elevation model and then replaces the aerial imagery layer, the map does not yet show both at once. In maps from OpenStreetMap data only buildings with a height value appear as bodies, in the checked example Florence about one in ten. The sector assignment is Defconder's classification by building function and not an official designation as critical infrastructure. The read time was measured on the development machine.

• 0building parts from official state data in the pilot area Hanover centre, with roof shapes
• 0automatic checks or more for the computation cores, the plan and the documents, including comparisons with the sun table of the US Naval Observatory, the EU database PVGIS and the exact solution for the dam break
• 0weather situations as templates, every value continuously adjustable or taken from the real situation
• 0data layers from official sources: radiation monitoring network, residents by census, protected areas, weather warnings
• 0check rules with which the plan coach examines a crisis plan in a traceable way and without AI
• 0requests to third parties in the test with blocked internet, in both views

World and weather

The scene follows date, time and weather. Whoever plans an exercise sets the situation. Whoever wants to know exactly takes over the measurement or the forecast of the Hanover station.

Defconder

Hanover centre, 21 December, 9:30. The shadows come from the computed sun position. Buildings: 3D building model LoD2 and terrain model DGM1 of the LGLN (CC BY 4.0), roads, water and green from OpenStreetMap (ODbL). Everything is served by your own server.

Defconder

Heavy rain at 35 millimetres per hour. The colours are kept, the rain falls in the wind. On the right are the effects of the situation with level and figures. The classification follows the warning criteria of the German Weather Service.

• Two views, one scene

  A fast map for situation management and a 3D world with roof shapes and shadows. Date, time, weather, camera and layers are kept when switching. Both run with open libraries from your own server.

• Sun and season

  The sun position is computed astronomically and checked against an independent library and the tables of the US Naval Observatory: largest deviation 0.016 degrees. Sky colour, twilight, day length and foliage follow the date.

• Weather you set

  Cloud cover, precipitation, temperature, wind, visibility, snow and wetness can be set freely or chosen from templates: from heavy rain and thunderstorm to hurricane and snow chaos. Beaufort, perceived temperature, solar radiation and visibility follow named formulas and are checked.

• Real situation from the weather service

  One button takes the current measurement of the Hanover station or a point in the forecast of the German Weather Service: cloud cover, rain, temperature, wind, gusts, visibility, snow, thunderstorm and freezing rain. Missing readings are named. Only this retrieval needs internet.

• What the situation causes

  Storm, heavy rain, snow, ice, heat, cold, fog, thunderstorm and softened ground become effects with level, figures and text: gusts in kilometres per hour and dynamic pressure, snow load on the roof, risk of slippery roads, heat stress. In heavy rain the ground visibly turns to mud.

• Passability during floods

  For every water depth Terra says whether roads are free, restricted or no longer passable for cars and emergency vehicles. The thresholds are rules of thumb and marked as such.

Water, fire, plume, sun

The computation cores run in the browser or on your own server. Every computation names its assumptions and its check.

Defconder

Exercise scenario heavy rain with 35 millimetres per hour, for one hour, computed on a 6 metre grid. Buildings are obstacles, infiltration and sewer network are placeholder assumptions and not calibrated. An exercise model, not a forecast.

Defconder

Leine, 100-year flood (HQ100). The official flood hazard map of the NLWKN lies on top in orange. The model covers 85 percent of the official area, the areas match by 59 percent, 34 percent of the computed area is overestimation. The initial water level was set against these maps: a calibration, not an independent forecast.

• Flash flood with buildings as obstacles

  A shallow water model computes where the water from a rain situation runs. It stays at rest where it must, conserves the water volume and meets the known exact solution for the dam break. Result: affected buildings, closed roads, sectors hit.

• River flood of the Leine, checked against the official map

  Three runs for frequent flood, 100-year flood and extreme flood. The official flood hazard maps can be laid over them, the agreement is shown in the panel. For the frequent flood the areas match by only 27 percent, which is shown as well.

• Fire and pollutant plume

  Click an ignition or source point: the fire spreads by wind, slope and fuel, the plume by wind and stability of the air. Both compute directly in the browser, in fractions of a second. The parameters are marked as placeholders.

• Roof by roof: solar potential

  From slope, orientation and shading by neighbouring buildings and terrain, Terra computes the irradiation of every roof surface. For twelve slopes and orientations the method is on average 1.2 percent off the EU database PVGIS, in the worst case 5.9 percent.

Supply and outage

What happens when a substation fails, the gas stays away or the petrol stations run empty? Terra computes it as an exercise scenario, from the first outage to the consequence in the plan. Real operator data can be attached as a file, further formats are in progress.

Defconder

Exercise outage of a substation in frost, after 52 hours. The assignment of the 1,527 critical buildings follows distance, the emergency power times per sector are adjustable assumptions. Violet: health facilities whose emergency power is exhausted without fuel resupply. The network comes from OpenStreetMap and is incomplete.

• Outage and cascade

  Let a substation, transformer station, gas station, fuel depot or petrol station fail, with start and end. Terra computes hour by hour: emergency power per sector, heating, water pressure after a buffer time, mobile network, traffic signals, risk of cooling down in frost. All assumptions are adjustable.

• Fuel and petrol stations

  Petrol stations without power do not pump. Without delivery they run empty according to stock and crisis factor (panic buying). Emergency power lasts longer when fuel is resupplied and shorter when not: power, gas and fuel are linked in the model.

• Exercise network from open data

  55 nodes from OpenStreetMap (substations, transformer stations, petrol stations, gas storage) and 1,527 critical buildings as consumers. What is missing can be set as an exercise node, marked as exercise. It is a consequence model, not a load flow or hydraulic model.

• Attach real operator data

  File import for GeoJSON and CSV, every import with name, licence and origin, removable at any time, exercise and real data kept apart. In progress: CIM/CGMES (IEC 61970), INSPIRE utility networks (GML), OGC WFS and API Features, the Marktstammdatenregister as CSV and operator-specific adapters.

• From the consequence into the plan

  Saved outages run as a step in scenarios. From the outage Terra creates measures as drafts: emergency power for hospitals, fuel, warming rooms, water, traffic without signals, radio. The impact analysis holds the bridging time by emergency supply, and the plan coach reports when it is shorter than the recovery time.

Aerial imagery and data layers

On request Terra shows the real aerial image with 20 centimetres per pixel instead of the map and lays official layers over it. Every layer names source, licence note and retrieval date in the program.

Defconder

Digital orthophoto of the LGLN (taken March 2025) with the number of residents per 100 metre cell from the 2022 census. The layers are stored when the data is built and run without internet in operation.

• Real aerial image under the 3D world

  The aerial image lies on the terrain, the buildings stand translucent above it. Switchable in both views. The image shows the time of capture, not the season you set, and the panel says so.

• Radiation monitoring network

  Ambient dose rate of the stations of the Federal Office for Radiation Protection, 1,676 stations nationwide with hourly value, colour scale by value, single values on click.

• Residents by census

  Number of residents per 100 metre grid cell on the reference date 15 May 2022. Small values that are altered or suppressed in the original data are marked that way and not filled in.

• Protected areas and weather warnings

  Nature, habitat, bird protection and landscape protection areas of the Federal Agency for Nature Conservation, and the weather warnings of the German Weather Service for municipalities, as a snapshot at the time of retrieval.

Crisis plan on the map

The situation becomes a plan: measures with number, type, responsible person and deputy stand as markers, zones, lines and arrows on the aerial image. The document follows at the push of a button.

Defconder

Example plan for an exercise: Leine flood in the city centre. The zone is the danger area, the arrow the escape route to the assembly point, assembly point and staging area appear as tactical symbols. In the panel the plan coach checks against 29 fixed rules. The plan names no real persons or phone numbers.

Defconder

The document for reading is built from the plan state: profile, situation map, measures by phase, timeline, roles, resources, communication matrix, impact analysis, reporting duties, check by the plan coach and the proof from the chain. As a page for reading in your own network, as a Word file and as data.

• Profile, trigger, escalation

  Purpose, scope, trigger criterion, responsible and deputy office, up to six escalation levels and a review interval. The plan coach reports overdue reviews.

• Measures with type, place and prerequisite

  Thirteen measure types with colour, phase, start, duration, means, success criterion, prerequisites, lead time, escalation and map reference as point, zone, line or arrow. Assembly point, staging area, care point and information point appear as tactical symbols after the BBK recommendation 2024. Immediate measures are marked. Release only when all mandatory fields are filled in.

• Roles, resources, communication, impact, reporting

  Who deputises for whom and how the person can be reached. Which resource exists in which quantity and where it is needed twice. Who informs whom by which route and by when. Which processes fail and how long that is tolerable. To whom, and by when, must be reported.

• Plan coach without AI

  Twenty-nine fixed rules check completeness, deputies, double booking of people, timing prerequisites and circular references, reporting deadlines, recovery against tolerable outage and emergency-power bridging, overbooking of resources, warning route for evacuation, place reference, release and review deadline, plus staff with groups and sections, head of staff with two deputies, immediate measures, reporting points with guiding questions, fallback channels without IT, emergency power against the guideline of 72 hours, de-escalation, lead time against warning lead time, exercises and findings. Every finding names the place and jumps there.

• Draft from the situation

  From a computed flood run Terra creates measures as drafts: assess the situation, warn, close roads, evacuate buildings and one measure per affected sector. Responsible persons, means and success criterion stay open for humans, and the draft cannot be released before they are filled in.

• Document, Word, data, reading link

  Page for reading and printing, Word file, data as JSON, situation map as image. The reading link shows the current plan state in your own network without editing.

• Scenes and scenarios

  Scenes hold view and situation. Scenarios play a timed sequence: rain starts, level rises, closure is triggered, measure starts. Plans, scenes and scenarios can be created, read, changed and deleted.

• Every change in the chain

  All plans and their parts are event based. Every event carries the hash of the previous one. A later change breaks the chain and is reported with the number of the first affected event. The state of the chain is shown in the plan document.

All functions, standards and the downloadable sample are in the crisis plan section further down.

Sensor data and world export

From time, weather and scene Terra computes a view from above and delivers it as a dataset: for training and testing software, for exercises with drone and satellite images, and for game and simulation engines.

Defconder

Section at the Opernplatz, summer afternoon. Aerial image, computed colour image, classes and thermal image from the same scene. In the thermal image roofs and sunlit asphalt are high, green areas and shade low. The temperature comes from an energy balance, not from a measurement.

• Computed thermal image

  An energy balance per pixel from absorbed sun, sky back radiation, wind and evaporation, with thermal inertia of the materials and shadows of neighbouring buildings. Sensor blur and noise are adjustable, the seed is fixed.

• Dataset with georeference

  A ZIP with colour image, aerial image, surface height, height above ground, classes, shadow and two thermal images in 16 bit (centikelvin), plus world files, class list, assumptions and sources. All channels have the same size and the same grid.

• World export for engines

  The pilot area as 3D Tiles and glTF with roof shapes, in three colourings, plus terrain, surface, classes and aerial image as rasters with georeference. For Cesium for Unreal, Cesium for Unity, Blender, Godot and QGIS, with instructions in the package.

As of 15 October 2026, pilot area Hanover centre. Limits: the models are simplified and not calibrated, especially for sewer network, soil type and fuel. The supply network is an exercise model from open data without line topology, OpenStreetMap records transformer and gas stations only incompletely, and real operator data need an agreement with the operator. The river flood of the Leine is set against the official flood hazard maps; for the frequent flood the areas match by only 27 percent. The thermal image looks straight down, uses material values from the literature and is not calibrated against measurements. The data of the German Weather Service is that of the Hanover station, not specific to the area, and needs internet for the retrieval. The aerial image shows the capture time March 2025. Terra is not a forecast. The terms of use of the state data, aerial images and flood maps for passing on to customers are still being clarified. There is no security test by third parties yet.

• 0fixed check rules with which the plan coach checks the crisis plan traceably and without AI
• 0measure types with start, duration, resources, success criterion and map reference
• 0public sources the structure is oriented along, without any claim of conformity
• 0hours of emergency operation without refuelling as guideline value, calculated per site
• 0pages in the English sample, the German one has 17, all details fictitious

What a crisis plan in Terra contains

Every building block is its own data object that can be created, read, changed and deleted. Measures are released only when all mandatory details are filled in.

Defconder

Roles with staff group, section and several deputies. On the map staging area and assembly point appear as tactical symbols with the number of the measure.

• Profile, trigger, escalation

  Purpose, scope, trigger, up to six escalation levels, warning lead time and review interval. Document properties such as classification, responsibility, storage location and approval are part of the document.

• Staff and sections

  Roles with staff group (head, core team, extension, assistance, response team, advisers, liaison), section S1 to S6 following the command organisation of DV 100 and several deputies for the head of staff.

• Reporting points and guiding questions

  Who receives event reports, how they can be reached outside working hours and which yes/no questions belong to the initial assessment. If one is answered with yes, the head of staff is alerted.

• Immediate measures

  Measures that allow no delay are marked and appear as a checklist with a done column in the document. The rule is: protecting life and health comes before protecting property.

• Measures with map reference

  Thirteen measure types with start, duration, means, success criterion, prerequisites and lead time. Location as point, area, line or arrow. For assembly point, staging area, care point and information point the map shows tactical symbols.

• Communication with a fallback channel

  Who informs whom, by which route and by when. The plan coach reports recipients that can only be reached through channels that depend on the network or on IT.

• Emergency power per site

  Survey form with output, fuel, tank content, consumption, mobile feed-in and secured delivery. Terra calculates the run time and checks it against the guideline of 72 hours. Import as CSV.

• Impact analysis and reporting duties

  Critical processes with tolerable downtime, recovery and bridging by emergency supply. Reporting duties with recipient, deadline and legal basis, legal bases as a free list.

• De-escalation, exercises, findings

  Criterion and procedure of de-escalation, documented exercises including those played from scenarios, and findings with priority, responsible person and target date.

• Operations log and final report

  Reports, decisions and orders with time, assumptions marked as such. The final report compares planned and actual times per measure and lists the findings.

The document: red page, staff chart, situation map

From the plan state Terra produces a document to read and print, a Word file, the data as JSON and a designed sample version as PDF at the press of a button.

The document begins with a red page for an emergency: trigger, escalation levels, head of staff with deputies, reporting points, reporting deadlines, immediate measures and the emergency call. Then follow document control with change history and approval, terms, escalation and alerting, immediate measures, command organisation with a chart, situation map, measures by phase, timeline, emergency power supply, resources, communication matrix, impact analysis, reporting duties, de-escalation, check result and the proof from the verification chain.

Defconder

The reading document is generated from the plan state, the designed sample version with red page as PDF.

After an operation or an exercise the final report compares what was planned with what the operations log records: start and duration per measure, deviation in minutes, decisions and findings with responsible person and target date.

Defconder

Final report: planned and actual per measure from the operations log of an exercise (example data).

Emergency power and fuel: survey, calculation, import

What happens when a substation fails, the gas stays away or the petrol stations run empty? Terra computes it as an exercise scenario, from the first outage to the consequence in the plan. Real operator data can be attached as a file, further formats are in progress.

The survey form records per site whether a stationary generator exists, how much fuel is in the tank and how much the generator uses per hour, whether an external feed-in is prepared and who delivers fuel during a power failure. Terra divides tank content by consumption and warns when the run time is below 72 hours and delivery is not secured. The Federal Office of Civil Protection and Disaster Assistance recommends emergency operation for at least 72 hours without refuelling.

Existing surveys can be imported as CSV. Equal sites are updated, and on an error nothing is imported. Interventions in the energy supply are a matter for the grid operators, Terra plans one's own ability to act and not grid operation.

Defconder

Emergency power per site with calculated run time and import of the survey form as CSV.

Emergency power and supply outage in Terra

Defconder

The Crisis team hospital application in the exercise scenario of the fictitious Klinikum Beispielstadt: a district power outage and a mass casualty incident. All names and data are invented. The interface of the product is German.

Defconder

Generator in the exercise scenario: remaining runtime follows from fill level, reserve and load, the buffer until delivery stands next to it. Thresholds and delivery time are placeholders. All data is invented. The interface is in German.

Defconder

The stream of admission, transfer and discharge messages. Every HL7 message sits unchanged in the stream, its proof value is in the main log, and the marker shows which one became a record of the situation picture. The interface of the product is German.

• 0object types in the domain pack, plus 8 relation types and 7 actions with rules
• 0automated checks on the domain pack and the interfaces, all passed
• 0standards for connecting the hospital information system: HL7 v2 over MLLP and FHIR R4

• HL7 v2 with acknowledgement

  Admission, transfer and discharge messages (ADT) arrive over a persistent connection with MLLP framing. Defconder acknowledges every message (AA), explicitly rejects unreadable ones (AR) and only accepts from registered sender addresses.

• FHIR R4

  Bundles and single resources are accepted by webhook and split up. Every resource becomes an entry, fields such as id, status or subject.reference are available for mapping.

• Update instead of duplicate

  If the hospital system reports the same patient repeatedly, a key attribute selects the existing record and it is adjusted. An identical message changes nothing and creates no event. Fields that are not reported, such as the triage category, are kept.

• Provenance you can verify

  The raw message sits in the stream, its Merkle proof value in the chained main log. Every record points to the stream and entry it came from.

• Patient data with a level

  The patient type is held as restricted (VS-NfD) and as a special data category. An account with a lower clearance sees neither the records nor the messages behind them.

• Remaining runtime and thresholds

  From tank size, fill level, unusable reserve and the generator load, the action Check remaining runtime calculates the hours until empty, compares them with the delivery time and sets a warning level: normal, inform staff or check load shedding. If the tank will not last until delivery, the level rises even when the thresholds are not yet reached. Thresholds, reserve and delivery time can be set per house, the example values (6 and 3 hours) are placeholders. Trigger resupply and Decide load shedding record the decision but switch nothing off. Without consumption there is no remaining runtime and the action refuses. The calculation lives in a building block that any installation can apply to any object type, with no hospital pack needed, for example a tank, a water reserve or an oxygen store.

• Emergency operation as a rule

  If the hospital information system fails, the action IT emergency operation declares it and notes paper documentation on every ward it supports. On a system that is not disrupted the rule refuses.

As of 22 October 2026. Demonstrated in a conversation, by video call or on site.

• No programming

  Pick a block, pick an object type, check the preview, apply. Existing attributes and records stay unchanged.

• Any industry

  The same capability fits an emergency generator, a fuel tank, a water reserve or an oxygen store, in a hospital, a utility or an authority. No change of domain pack is needed.

• Provable

  Every application is logged with block, release and target. What a block does can be read from the rules of its actions.

• Stays with you

  Which blocks you get depends on your delivery. There is no call home to the vendor. In your house you switch blocks on and off yourself.

• Keeps growing

  We extend the range continuously and across industries. New blocks arrive with the delivery, without you having to rebuild your domain model.

• Check before acting

  Actions of a block refuse when details are missing. Decisions with consequences require a release.

Defconder

The building blocks area in the interface. Every block states what it can do, what it creates and where its limits are. The interface is in German.

• Stock and remaining runtime

  How long will the stock last, and will it last until delivery? The block calculates the remaining runtime from fill level, capacity, unusable reserve and load, compares it with the delivery time and sets a warning level. One action triggers the resupply, a second records the decision on measures and requires a release.

  • Consumption follows the load between idle and full load
  • The warning level rises as soon as the stock will not last until delivery
  • Each check shows the change since the previous one, and a notification can be set for a raised warning level
  • Each house sets its own thresholds, reserve and delivery time, the block switches nothing off

  Example with invented exercise data: a 600-litre tank filled to 56.6 percent, 10 percent reserve unusable, load 85 percent at 30 to 160 litres per hour, delivery time 4 hours. Result: 2.0 hours of remaining runtime, 2 hours short of delivery, warning level check load shedding.

• Connections: plant technology and warnings

  The block unlocks templates with which you read plant technology devices and take in warning messages. Every connection carries its origin: the device a value comes from, or the licence of the source.

  • Modbus TCP for generators, meters and gauges, read access only
  • CAP warning messages from a feed, with severity, urgency and area
  • Without origin or licence Defconder does not create a connection

  Tested so far against a simulator and sample data, not yet on your device. Before operation we test together with you.

Defconder

The building block Stock and remaining runtime in version 2.0: inputs such as reserve, load and delivery time, calculated values such as usable amount, remaining runtime and buffer until delivery. The interface is in German.

Defconder

The Modbus TCP template in the form for new connections. The register map is in your device manual and is entered by you, Defconder does not guess it.

All data in the example is invented.

• Checked before starting

  Graph analysis detects loops, missing details and reachable actions without required approval. The current checks also cover paths from AI nodes to actions.

• Export and verify run receipts

  A completed run contains a hash chain. Its JSON file can be exported and recomputed independently; changes to steps are detected.

• Retry from a checkpoint

  A failed run can be restarted from a saved, classified input checkpoint. The retry is recorded as a new run.

• Deterministic CLI runner

  The local runner executes workflow files with supplied host functions. The tested example produces the same receipt as the workflow core.

• Resource lineage

  Lineage shows stored object types, actions, event types, data streams, vector indexes, sub-workflows and selected models for each workflow.

• Model status at a glance

  Models can be maintained locally as experimental, active, deprecated or replaced. Status is not automatically synchronised with a model provider.

• Building blocks for the whole workflow

  Triggers from an event, a threshold, a schedule, a data stream or by hand. Plus data queries, conditions, loops over reports, parallel paths, waiting, merging, similarity search, AI classification and summaries, approval, action and notification.

• A tidy editor

  The step catalogue on the left collapses by category and is searchable. Context menus on canvas and nodes, a compact action bar, undo and redo, and import and export keep the way to a workflow short.

• Publish with a second person

  A published version stays immutable. On request, a second person must confirm the publication. Any change results in a new version.

• Test cases and simulation

  A dry run plays a workflow through with sample data without sending notifications or triggering actions. Stored test cases and a simulation with several events check the expected behaviour.

• Compare and roll back versions

  Two versions can be compared side by side. A rollback plan shows in advance what changes. Rolling back creates a new draft and leaves the old version untouched.

• Approval inbox, history and metrics

  Pending approvals are collected in one inbox. The history can be filtered, every step of a run can be inspected, and the approver's decision is recorded. Metrics show how often workflows were started, how they ended and which versions are in use. They are based on the recorded runs of the local instance.

Defconder

The large 15-node exercise workflow. The left section shows triggers, data, checks and the first branches. All example data is invented.

Defconder

The right section follows the paths through search and a join to approval and completion. The green bar shows the graph check result.

• Exercise: warning level to resupply

  An invented emergency generator reaches a warning level. The workflow notifies staff, waits for approval and then records the action.

  • An action requiring approval stays pending until approval
  • The approving person is recorded in the run
  • The dry run shows steps without effects

  All data is invented exercise data.

• Exercise: check and approve a report

  An invented report is classified. The draft shown contains deliberate errors so the check can reveal missing approval paths.

  • Errors are shown at the affected node
  • The graph can be viewed as a branching workflow
  • A locally maintained model status appears in lineage

  All reports and names are invented for the demo.

Defconder

The faulty exercise draft is not approved. All three findings identify a path to the action without an approval node.

Defconder

The step catalogue arranges 32 building blocks in six categories. Search and collapsible groups keep large workflows manageable.

Defconder

An expanded category shows its building blocks, here the seven blocks for data. The other groups stay collapsed.

Defconder

The action bar is compact: save, undo, check, dry run and publish sit in one row, less frequent tools in the More menu.

Defconder

Right-click a node: open properties, copy, duplicate or delete. The properties appear in the side panel on the right.

Defconder

Right-click the canvas: paste, auto-arrange, fit view, create presentation images, and import or export workflows.

Defconder

The same tools are available in the More menu of the header. Undo and redo sit next to it.

Defconder

The properties show the selected node name, assigned action and error strategy.

Defconder

The dry run marks notification and action as simulated. Internal example identifiers are anonymised in the capture.

Defconder

The run visibly waits for approval. Its recorded steps remain available for inspection.

Defconder

The receipt was exported and independently verified. Person identifiers are anonymised in the capture.

Defconder

Lineage links stored resources to workflows and nodes. The local model catalogue is empty in this example.

All names and data in the workflows shown are invented exercise data. Person identifiers are anonymised in the screenshots.

Defconder

The Version spaces building block. The live state is secured as the main state. All names and data are invented exercise data. The product interface is German.

Defconder

A branch of its own is created for the exercise, separate from operations. Direct changes to the main state are locked.

• Main state locked

  The live state is locked against direct changes. Changes only arrive through checked merges.

• Isolated branches

  Drafts and exercises run in branches of their own. Operations stay untouched until a change is approved.

• Commits with a reason

  Every secured state carries a message, the author and the time. The history lives in the chained event log.

• Comparison field by field

  For every changed resource the comparison shows the fields with old and new value before anything is adopted.

• Restore and mark

  An earlier state can be restored in a branch. This creates a new commit, nothing is deleted. Tags mark verified states.

• Adoption by two people

  Whoever requests adoption may not approve it. A second authorised person decides, and the approval is in the log.

• Conflicts are detected

  The three-way comparison checks base, branch and main. If two branches change the same field, nothing is silently overwritten.

• No secrets in the history

  Passwords and credentials are rejected in version objects. Only a reference to the secret is stored.

• Packages with checksums

  A state can be exported as a package and imported at another site as its own, separate branch. The checksums protect integrity.

• Eight rights of their own

  View, secure, create branches, request adoption, approve adoption, restore, export and import are separate rights in role management.

• Case: The hospital practises a power failure

  An emergency generator is to be described anew, and ongoing operations must not be disturbed.

  • The main state is secured, the exercise runs in the branch notstrom-uebung
  • The generator is renamed and the tank content added, a password in the model is rejected
  • A wrong name is rolled back, the verified state gets a tag
  • One person requests adoption, self-approval is rejected, a second person approves

  All names, data and persons are invented. The case is an exercise and not a domain rule for a hospital.

• Case: Two changes to the same field, one state for a partner site

  While the branch is running, someone changes the same field differently in a variant. And a partner site needs the same state.

  • Adopting the variant is detected as a conflict and not overwritten
  • The branch has to be adjusted and secured again
  • A commit is exported as a package with checksums
  • The partner site imports it as its own, separate branch, never directly into operations

  The conflict is detected in the three-way comparison. The message in the interface names the number of conflicts.

Defconder

A password in the model is rejected: secrets must not be written into version objects. A reference is used instead.

Defconder

The comparison shows every changed field with old and new value: the new name and the added attribute.

Defconder

Restoring creates a new commit that carries the name of the restored state. Nothing is deleted.

Defconder

Self-approval is rejected: the person who requested the merge may not approve it themselves.

Defconder

A second person approves. The merge appears in the history of the main state, with their name.

Defconder

A variant changes the same field differently. The three-way comparison detects the conflict, adoption is not carried out.

Defconder

An exported package is imported as its own branch, here under the invented name Import-Klinik-Nord.

All names and data are invented exercise data. The user names in the captures are test accounts.

Defconder

The graph over millions of entries: nodes with icons, tooltips on hover, shortest path between two persons. Every edge names the stream and entry it came from. Exercise data. The interface of the product is German.

Defconder

Person matching: from fifteen points and three independent pieces of evidence a pair is merged automatically. Twin risk, a conflicting date of birth or a common name block the pair until two people have decided. The interface of the product is German.

Defconder

Geocoding without internet from open map data. The result states its precision (house number, street, postcode, town). Ambiguous addresses deliberately get no coordinate. The interface of the product is German.

Defconder

SQL over the data lake with a chart: dispatches per hour of the day from 43,743 exercise messages. Every query is read-only and recorded in the main log. The interface of the product is German.

Defconder

Semantic search over 5,000 situation reports; the meaning map shows which reports are close in content. The language model runs locally, nothing leaves the server. The interface of the product is German.

Defconder

Blind graph: investigators see connections under pseudonyms. Real names are unmasked for a limited time only with an uploaded order and the signatures of at least two custodians. The interface of the product is German.

• 0million rows (3.9 GB) ingested in 505 seconds on a single machine
• 0million edges between 11 million nodes built into a graph in 306 seconds
• 0false automatic merges across 3.6 million person records with known ground truth
• 0milliseconds for 10,000 address lookups, offline

• Streaming instead of memory limits

  Files of any size (CSV, NDJSON, Parquet, whole folders) are read in chunks. Each chunk gets a Merkle root in the chained main log, each row its own proof value.

• Connect databases

  PostgreSQL, SQL Server, Oracle, MySQL, MariaDB and SQLite are queried as sources. Credentials sit in the vault, queries are read-only, time offset and resume are part of the configuration.

• Graph with provenance

  Link rules define which fields become nodes and edges. Path search, neighbourhood and filters run over the data lake. Anyone who may not see a stream does not see the edges attached to it.

• Matching that blocks

  Phonetic pre-selection, a points system and independent evidence. When there is risk, the software does not decide: the pair stays blocked until two people have assessed it. Every decision is an event in the log.

• Geocoding open and offline

  An address index from OpenStreetMap data is built in seconds and works without a network. Optionally a chain queries Nominatim or Photon, bound to the stream classification, without writing addresses to the usage log.

• Local semantic search

  Embedding uses a local model. Exact search over a million vectors takes under a second, an approximate index makes it up to thirteen times faster. Plus a three-dimensional map of meanings.

• DuckDB analysis in the browser

  Group, count, time series: SQL directly on the stream, with bar, line and area charts, column profile and CSV export. After 60 seconds a query is aborted.

• Judicial approval built in

  In the blind graph real names stay encrypted. Unmasking needs the order as a file and approvals under the multi-person rule. The key is held in memory only for the duration of the approval.

• Purpose limitation

  Roles and clearance levels apply all the way into the graph. Queries and unmaskings are events with time, person and purpose, so it can be proven later who saw what and when.

Status 22 October 2026. Demonstration in conversation, by video call or on site.

Defconder

A question in full sentences, below it the query Defconder ran and the result. All data is invented. The interface is in German.

• The system computes, the model explains

  The number, the list and the groups come from a query that Defconder runs itself. You see the query as text. If the model fails, the result stays.

• Every statement with source and quote

  The model may only say what it can prove verbatim. If a quote or a number does not match, the statement is shown as not proven and cannot be confirmed.

• Only what you may see

  Case questions use the same view by clearance level as the rest of the system. What your account may not see enters neither the query nor the answer.

• Local models only

  Only models you have approved on your own infrastructure run, never cloud models. The operator lock of the AI layer applies here too.

• Links only after an objection

  If the model proposes a connection, a second agent first writes the strongest argument against it. Only after you have read it does Defconder record the link.

• Proof you can recompute

  Every answer gets a check value in the log. The proof recomputes sources, quotes and query, and an independent tool checks the extract without Defconder.

Defconder

Two statements by the model, each with quote and source. If proof is missing it says not proven, and the statement cannot be confirmed. The interface is in German.

Defconder

The proof recomputes check value, sources, quotes and query and says whether the answer holds.

Status: built and proven in test. On machines without a graphics card an answer with a model takes minutes. All information without guarantee, all sample data invented.

Defconder

The process map from 400 invented emergency cases: case count and mean time at every transition. The interface is in German.

• Process map from the real cases

  How often does it go from step to step, and how long does that take on average? The map is built from the events, not from a wish model.

• Variants without singling anyone out

  The most common paths with case counts. Groups below the minimum size (five by default) are never shown.

• Figures with limits

  Throughput time, median, rework loops. What cannot be computed is shown as not available instead of being estimated.

• Bottlenecks at the handovers

  Waiting time between roles with frequency. A finding can be turned into a measure with an owner, a deadline and a metric.

• Local, encrypted, off until released

  Imported sources are stored encrypted, cases pseudonymised. Process analysis only runs once an administrator switches it on.

• Check value and independent proof

  Every result carries a check value. The metric proof can be downloaded, and a separate verifier recomputes it without Defconder.

• Understand

  • Process map with frequency and time
  • Variants and variant comparison of two periods
  • Compare case groups by exact attributes
  • Object relations according to OCEL 2.0

• Measure

  • Performance: throughput time, median, target time
  • Role handovers with waiting time
  • Data quality: times, duplicates, order
  • Outlier check with an explained threshold

• Discover

  • Heuristic discovery from the events
  • Inductive discovery with a declared fallback model
  • Export as BPMN 2.0, PNML or model JSON

• Check against the target

  • Target-actual comparison with target models from the workflow studio or from BPMN and PNML import
  • Deviation report per case
  • Rule check: mandatory step, deadline, four-eyes approval
  • Cause analysis with a limited decision tree, correlations instead of proof

• Look ahead

  • Prediction of the next activity and remaining time, trained locally and checked on later cases
  • Event simulation for what-if on arrivals and resources

• Act and prove

  • Turn a finding into a measure with an owner, a deadline and a metric
  • Saved views and filters
  • Check-value report and independent metric proof

• What you expect, and it is there

  • Process map, variants and variant comparison from the real event log
  • Object-centric analysis according to OCEL 2.0
  • Target-actual comparison against BPMN and PNML models, deviation report, rule check
  • Cause analysis, prediction of remaining time and next activity, what-if simulation
  • Import of CSV, XES, OCEL and Parquet
  • Reports, saved views, measures with a deadline and a metric

• What Defconder adds

  • Runs on your own infrastructure, encrypted, no cloud
  • Cases pseudonymised, groups below the minimum size are never shown
  • Off until an administrator releases it, every source with classification and rights
  • Every result with a check value, an independent tool recomputes the proof without Defconder
  • Every analysis and every measure is in the chained log
  • What cannot be computed shows as not available instead of being estimated

Defconder

Performance: 400 cases, 116.8 minutes on average, median 85 minutes. What cannot be computed shows as not available.

Defconder

Handovers between roles with mean waiting time. A finding becomes a measure with a deadline and a metric.

Defconder

Cause analysis: which attributes go along with long throughput times? The view shows correlations, not proof of causation. On the left the seventeen analysis types, on the right result check value and proof. The interface is in German.

Defconder

What-if simulation: more resources and different arrivals compared with the baseline. The baseline values are explicitly hypothetical, the computation is reproducible with a fixed seed.

Status: built and proven in test. All sample data invented, all statements without warranty.

• Association first

  Two reports count as the same object when they share an identifier OR lie close enough in space and time. Configurable thresholds, not rigid assumptions.

• Honest uncertainty

  Every fused track carries its own quality figure: the largest distance between its contributing reports, reported openly instead of hidden.

• No report gets lost

  A report with no match stays its own single-report track instead of quietly disappearing.

• Checkable, not a black box

  Weighted averaging, not a trained estimate. Every step can be recomputed, not just trusted.

• Rewind with a check stamp

  Timeline with playback at several speeds. At every point a stamp shows that the fingerprint is right, the chain is gapless and browser and server compute the same state.

• Four kinds of forecasts

  Trend of a measured value, approach and protection corridor, endurance and relief, plus your own model with an uncertainty band. All recomputable, none of it part of the real picture.

• Options side by side

  Several courses of action are computed and checked against conditions. The interface names the option with the fewest violations, the human decides and gives a reason.

• Formally proven under assumptions

  A prover runs locally in the server and checks three kinds of properties: timely interception, approach paths outside restricted zones and continuous minimum staffing. The result carries its assumptions.

• Sealed runs

  Every recorded run sits in its own check chain with a reference in the main log. Recomputing from the events of that time yields the same result.

• Clearance applies backwards too

  Whoever may not see something today cannot see it in time travel either. A run receives the strictest level of the data it used.

Time travelOptionsOwn modelAudit trail

Yesterday's picture, to the second, with evidence

Map, objects and events are restored from the log up to the chosen point. The check stamp on the left shows what was recomputed in the browser.

• Fingerprint of the event recomputed in the browser
• Chain checked on the server, picture seal compared independently between browser and server
• The real picture stays untouched, the historical state is only a view

Defconder

The views shown come from a test instance with exercise data. Formal proofs hold under the stated model assumptions and say nothing about the correctness of the input data. Chronos Guard carries no approval for use by authorities.

Defconder

The verifier in the browser, with sample data from a test instance: trust level 2, three witnesses have cosigned the log state. The statements say that one record has exactly two events, another was accessed exactly once and a third never.

• 0implementations of the verifier in JavaScript, Python and Rust, all written against the same specification
• 0test vectors that all three pass: tree roots, consistency proofs, signatures (including hash-based ones from an independent reference), events, extracts, statements, time anchors, OpenTimestamps proofs including a real one from 2015, draws and receipts
• 0runtime dependencies. The verifier only needs the cryptographic functions of the browser or of Node
• 0randomly modified documents in the random mutation test of all document types, with no crash and no forgery accepted unnoticed

• Three trust levels, honestly named

  Level 0: internally consistent. Level 1: the key belongs to whom you expected. Level 2: independent witnesses have confirmed the log state. Every result names its level, and level 0 says explicitly that it does not prove who made a document.

• Extracts: show without revealing

  Every event is a tree of its fields, each field with its own salt. Whoever passes a document on can hide fields. The hash of the event and its place in the log stay verifiable.

• Decisions against published rules

  Rules stand in the log as an event before they are applied. A denied access or a federated query carries a receipt with rule, inputs and result. The verifier evaluates the rule itself, including all edge cases, and needs no external prover for that.

• Observers and the citizen app

  An observer fetches checkpoints continuously and raises an alarm on rollback, rewriting or two roots for the same size. The citizen app contains the same check for the phone (developer version). Two signed roots of the same size are a proof anyone can recompute.

• Read access in the log

  Hits of federated queries, file downloads, citizen photos, the log export and handing a record to an AI model stand in the log as an event. That makes it provable that something was never accessed by these routes. Merely viewing something in the dashboard is unknown to the server and is therefore not recorded.

• Time corridor from public computation

  Optionally a checkpoint carries the header of the latest Bitcoin block (not earlier than). A time proof in the OpenTimestamps format shows that it existed at the latest at a later block time. Together they give a time corridor, accurate to about two hours. A real example with all files is open: a checkpoint in Bitcoin block 970912, created no earlier than 11 October 2026 05:58 UTC and existing at the latest at 12:33 UTC, with the original proof from the tool ots. It is not an eIDAS qualified timestamp.

• A signature a quantum computer cannot forge

  In addition to Ed25519 the log can sign its checkpoint with SLH-DSA per FIPS 205. The scheme only needs SHA-256, the page recomputes it in the browser, and our signatures match an independent reference byte for byte. The witnesses' cosignatures stay Ed25519 for now.

• Audit sample with public randomness

  Where not everything can be proven without gaps, for example that every decision followed the rule, the verifier draws events with the randomness of a Bitcoin block the operator did not know when committing. For error-free draws it states a bound on the share of violating events. A sample does not find single rare violations, and the report says so.

• Release only against a log entry

  A log only proves what is in it. If data lies encrypted and its key is shared among several custodians, the custodians hand out their share only if the request stands in the confirmed log. Whoever decrypted has left an entry. The verifier recomputes receipts and statements and shows when no key could be released for an object. A reference custodian is open, connecting it to the application is still to come.

• Count proofs for reports

  Every key has a proven number, also per month. A quarterly report to the supervisory body can thus be computed and checked without showing the events: exactly this many accesses of this kind in this month. Whoever adds the proven numbers gets the sum over several months.

• Evidential value beyond the break of a scheme

  A renewal chain keeps the evidential value of a checkpoint by committing it in time under a second scheme with a time proof. Whoever later forges a broken scheme cannot backdate before the renewal. The verifier recomputes this against an assumed date of the break.

• Report in plain language

  For every result the verifier says what is proven, what is not, what an adversary would need and what to do next. For people who have to pass a result on and explain it.

• Open formats, rebuildable

  Checkpoints follow the C2SP formats, trees follow RFC 9162. The specification describes every format precisely enough to rebuild the verifier in another language. So far there are three implementations by one author. An implementation by third parties is still missing and explicitly welcome.

• Network lock built in

  The verifier page carries a Content-Security-Policy that forbids every connection to the network and every loaded script. A copy that secretly sends data would be stopped by the browser, and the hash of the page can be compared with the reproducible build.

• Page and source signed, built reproducibly

  The verifier page is built reproducibly. Its hash stands in a manifest signed with Ed25519 and hash-based, and the verifier checks that itself. There is no attestation by independent third parties yet.

Defconder

The plain language report for the same result. It first names what is proven, then what is not proven and what an adversary would need, including a witness that was only brought in after a forgery.

As of 11 October 2026. The figures come from the test run of the verifier. The three demos compute in the browser with the same rules as the verifier, reduced to a few entries. In the application itself the hash-based signature and the count keys can be switched on, the audit sample exists as a server function, time proofs are stamped with the ots tool, and connecting the key custodians to the application is still to come. The images show the verifier with sample data from a test instance.

• 0corrupted inputs in the differential test of the three independent verifiers in JavaScript, Python and Rust. The target is any input with a differing verdict
• 0corrupted messages against four sensor inputs, no crash, no hang
• 0disagreements between the verifiers after the fix in the identical run, previously 17
• 0individual checks in the full baseline, the same before and after all fixes

• Differential testing of the verifiers

  Three independent implementations of the verification logic judge the same corrupted proof documents. The test exposed differences in type checking and in reading hexadecimal values. They are fixed, and the identical run no longer shows any disagreement.

• Permission model

  Accounts with exactly one narrow permission tried to raise their clearance or to change other accounts. The model was closed at that point: six test cases now pass, and two counter-checks confirm that what is allowed still works.

• Robustness of the inputs

  Malformed frames without login ended the server process in one case. Malformed input is now discarded, and an unexpected error no longer ends the server.

• Log under load and after failure

  The append-only log is bounded against failed attempts before login. After a power loss only an incompletely written last entry is saved aside and removed, any change further up remains a hard failure.

• Tampering detected

  Changed, deleted and reordered entries in the log are detected at start and the start is refused. A hard kill in the middle of a write burst leaves a readable log and a clean restart.

• Supply chain

  Known vulnerabilities in build tooling were removed, with the build shown in a clean copy. Two sub-projects need a major version change and are listed as open in the report.

As of 22 October 2026. The test cases are written as single defensive assertions, not as chained attacks.

• Prove, don't merge first

  Not merge-then-filter: every hit is checked individually before anything comes back at all. Technically impossible to return more than proven permitted.

• Two independent axes

  Clearance level and data category are separate. Victim and witness data can stay locked for every purpose, no matter how high someone is cleared.

• Bound to the role

  Which purposes a role may even select is set on the server. A role without clearance for a purpose cannot technically use it, not just hidden in the dropdown.

• Every denial logged

  Rejected hits are counted and recorded in the event log, never silently dropped.

The real app, not a mockup

• No server required

  Every device holds its own complete copy of the picture. Two devices that meet reconcile directly, mathematically guaranteed to converge without conflict.

• Keeps moving through relays

  A device carries reports along until it meets the next one. A report reaches its destination even if sender and recipient never meet directly.

• Forgery gets caught

  Each device signs only its own reports in its own chained ledger. A tampering relay is caught automatically by the next device.

• Clearance level is preserved

  Once a mesh packet reaches a network again, it is verified and fed into the main chain, at the clearance level it was originally given, never reassigned.

• Built for citizens too

  The Defconder Citizen app runs on ordinary smartphones, reports observations and relays warnings, even when not a single cell tower nearby is transmitting.

• Actually verified, not just sketched

  State reconciliation, multi-hop relay, origin verification, and feeding into a real server instance are all verified as working code, not just outlined.

Defconder

The active advance mandate: requested by one person, approved by another. On the right the checklist (several sources, plausibility, escape routes) and the evidence chain. All places invented. The interface is in German.

• Advance mandate instead of a decision in the emergency

  Two people approve a limited mandate for a shift. Whoever requests it does not approve it, self-approval is rejected.

• A track counts only with several sources

  At least two independent sensing methods and a plausibility check against the threat class. A single detector triggers nothing.

• The contradiction agent holds back

  It argues against: rescue helicopter in the corridor? Escape routes open? On a hit nothing is switched, and the reason is in the chain.

• Instant veto

  Any authorised person stops it with one key press. All active mandates end, the building systems return to their base state, the event is recorded.

• Weapon-free and reversible

  No effectors, 0.0 watts of transmit power. Protective steps are dimming lights, switching shutters and ventilation dampers, instructing shelters. Escape routes and safety lighting stay off limits.

• Every decision in a chain

  Mandate, approval, track, block and veto sit in a SHA-256 evidence chain. Who decided what and when can be recomputed.

• I Passive localisation

  Time differences of arrival from microphones, radio shadows in Wi-Fi and a timing check of GNSS give direction and time window. The system transmits nothing for this.

• II Signature masking

  Dim outdoor and facade lighting, throttle heat peaks. Safety and escape-route lighting always stay on.

• III Civil-protection cocoon

  Expected overpressure per facade with an uncertainty band and shadowed sectors. Shutters and ventilation dampers switch with read-back of the actual state, shelter instructions go out as a CAP message.

• IV Cyber mirror world

  Detected attacks in your own network are redirected into a separated environment with masked data. Grid frequency and emergency fuel stock are monitored.

• V Truth protection

  Crisis messages are checked against signature and sensor values. Without proof, the result is honestly: not verifiable.

• Two-tier delivery

  The civil edition and a sovereign edition are delivered separately. This is verified in the proof run.

Defconder

The contradiction agent blocks: a rescue helicopter is in the corridor, so nothing is switched. The reason is in the evidence chain. Simulation.

Defconder

After the instant veto: all mandates ended, building systems in their base state, the event as an entry in the chain. Simulation of a payload drone.

Status: prototype with proof run, being developed into a product. All places, data and scenarios invented, all statements without warranty.

Defconder

The draft: text for the other side, evidence per statement and the text checks. All data is invented. The interface is in German.

• Only truth from your data

  The object and the figures come from the dataset, and every statement carries a proof with the check value of its source. Nothing is freely worded or estimated.

• No threat, no countermeasure, no weapon

  A text check rejects drafts that contain any of these. Coordinates appear only if someone has weighed in writing that they do not make the building a target.

• Object first, approve afterwards

  A counter-argument is mandatory, and whoever approves acknowledges it with their own reasoning. Two other people approve, and the author of the draft cannot do it themselves.

• Signed and recomputable

  The extract carries a signature and a check value. A separate command-line verifier recomputes everything without Defconder and says how far it holds.

• Warning format for open channels

  The same message as a CAP file in German and English, with the same check value. A person hands it to a neutral body and the handover is recorded in the log.

• Time-limited, revocable, honestly labelled

  Every message is valid only for a set time. Withdrawing needs a reason, and exercises are marked as exercises in the text.

Defconder

First the strongest counter-argument, then the acknowledgement with your own reasoning. Only then can you approve.

Defconder

Published and signed. The proof recomputes check value, signature and texts and says whether it holds.

Status: built and proven in test. All sample data invented, all statements without warranty.

1. 01

   A memory of its own per installation

   Every installation builds its own knowledge: documents from the knowledge base and reviewed feedback, separated per tenant, encrypted, with a rights check on every retrieval. None of it leaves your infrastructure, and no model learns from the data of several customers.

   • Documents and feedback examples, separated per tenant
   • Rights are checked anew on every retrieval
   • Deleting removes the content from storage and knowledge index

2. 02

   Learning you control

   Every installation starts without learning. The operator switches learning levels on per area. Feedback sits encrypted in a queue and takes effect only when a named role reviews and adopts it. The model weights do not change.

   • The default is level 0: no learning
   • Create, edit, adopt, archive and delete feedback
   • Learning lock: existing material stays, nothing new is taken in

3. 03

   The gate in front of the model

   No model is called before the server has checked who asks, for what purpose, at which classification, with which approved model, and whether the operator has locked the AI. If anything is missing, the answer is no.

   • Role, purpose, classification, model approval and lock in one place
   • On failure, timeout or an unclear value: refused
   • Every decision in the log, without prompt and without model answer

4. 04

   Objection before approval

   Before a person approves an AI proposal, a second agent states the strongest argument against it, with a different model where possible. Without a counter-argument the proposal cannot be approved.

   • The objection carries a severity: low, medium or high
   • At high severity the action waits for a person and requires a written assessment
   • Counter-argument and acknowledgement are in the log with hashes

• Master switch for the operator

  A lock file and an environment variable limit the AI. The variable cannot loosen a lock from the file, and a damaged file locks. Only the architect changes the lock in the system, and the change is logged.

• Local first

  Models run on your server by default. Cloud models are possible only when enabled, and blocked from a classification level you set.

• Knowledge with source reference

  The knowledge base answers from your documents, run locally and with sources. What a person may not read appears neither in hits nor in answers nor in source references.

• Examples are data, not commands

  Learned examples never reach the system part or the rules, only a marked data block, at most three per request and of limited length. Whether a model follows instructions hidden in them we measure separately.

• Model change only with two people

  A new model is first a candidate with a test result. It becomes active only after approval by a second person and against a threshold the operator sets. Rolling back is possible.

• No self-configuration

  The AI can change neither learning levels nor locks, rights or model approvals. The server enforces this outside the model.

All displays use fictional exercise data.

• Image and documents

  From a photo to a scanned file.

  • Text from photos and scans, line by line with position. Scanned PDF pages are read automatically.
  • PDF documents page by page with structure and reading order.
  • Objects in the image, also with a free search term, and search by meaning.
  • One click into the image outlines the object.
  • Change detection between two shots of the same spot, even with a small camera shift.
  • Document comparison down to the single word.
  • Redaction that is burned irreversibly into the pixels and checked by the system itself.

• Video and drone

  From the camera stream to the flight path on the map.

  • Division into scenes with preview image, objects tracked over time, overlaid text read.
  • Sensor data per MISB ST 0601 runs on the map in sync with playback: flight path, altitude, heading and ground footprint. Packets with a wrong checksum are discarded.
  • Live recording of camera and drone streams. Each segment is encrypted on arrival and chained to the previous one.
  • Provisional alerts during recording, clearly marked as machine-generated and unreviewed.

• Audio

  From a radio recording to a transcript.

  • Speech to text with time marks, in many languages.
  • Translation, including from Russian, Ukrainian and Arabic.
  • Detection of acoustic events such as siren, gunshot or explosion.
  • Speaker separation: who speaks when, and the transcript shows the speaker.

• Biometrics, strictly governed

  Only within a framework, only with authorisation, only as a candidate.

  • Face and voice matching against your own reference sets, technically blocked without an active legal framework package and a valid authorisation.
  • Matches are candidates with a similarity value, never an established identity. Every candidate needs a justified confirmation by a human.
  • Error rates between groups of people are measured, and a model with significant differences is not deployed.
  • Access and deletion requests by data subjects are covered, and templates are destroyed through cryptographic erasure.

1. 00Done

   Foundation

   • Ontology builder with rule checking
   • Chained event log with independent verifier
   • Clearance levels on the server
   • Roles, purposes and four-eyes principle
   • Hardware keys for sign-in
   • Secrets encrypted at rest
   • Main log and system backups encrypted at rest with AES-256-GCM
   • Actions, AI agents, cloud lock above a set classification level
   • Central AI policy layer with operator kill switch
   • Learning per installation, stage 1: documents and feedback examples per tenant, with a learning lock
   • Building blocks for any object type, delivery per customer
   • Version spaces: branches, comparison and merging with a second person
   • Workflows: visual editor with checks, approvals and run receipt
   • Workflows: receipt export, retry from a saved checkpoint, deterministic CLI runner, resource lineage and locally maintained model lifecycle
   • Emergency restoration rehearsal
   • Pipeline, sensor and analysis builders
   • Layout and app builder for custom applications
   • Hardening test in seven stages
   • Navigation with side bar and info bar per module, also on the phone
   • AI layer: evaluation run with 30 synthetic test cases and model release by two people
2. 01Done

   Domain functions

   • Data streams with millions of entries, provably anchored
   • Graph, geocoding and person matching with hold
   • Semantic search and vector space
   • Media analysis with verifiable evidence package
   • Federated queries across multiple domain packs
   • Own map server with tactical graphics and terrain analysis
   • Situation interfaces for tracks and warnings, airspace map with zone marking
   • Time travel and forecasts with audit trail (Chronos Guard), with templates for grid load, water level, endurance and emergency power
   • Comms for command and communication: core with orders, alerts and receipts
   • Terra: walkable 3D world with weather and scenarios
   • Crisis plan with plan coach
   • Hospital domain package as a scenario
3. 02Next

   Operational readiness

   • My dashboard: personal start page of module widgets (first stage runs, extension follows)
   • Process analysis (process mining) on your own log and on imported event data (built, proven in test, every figure can be recomputed)
   • Case questions: questions in plain language put to a case, every statement with its source, a verbatim quote and a verifiable proof (built, proven in test)
   • Help and documentation in the application (help centre with articles per module and an introduction is in, operating procedures and operations handbook follow)
   • Workflows: more node types and a Terra threshold are in the editor, execution for deadlines and webhooks and judicial hold in the editor follow
   • Offline maps: street map and map packages without internet (first street map for Hannover runs in testing)
   • Comms: radio paths and mesh in device testing
   • Highly available operation
4. 03Planned

   Deployment readiness

   • Protective Shield: prototype with proof run (five layers, advance mandate, veto), to be developed into a product with real sensor hardware and legal review
   • Plain truth: signed, verifiable protection notices to the other side, approved by two people, handed over to open channels by people (built, proven in test)
   • Roles and rights separated across organisations
   • Directory service and single sign-on
   • Provenance for data
   • AI layer: a model that passes the evaluation run, and its release by the operator
   • Independent security review
   • Biometrics: real-time matching and protection against presentation attacks
5. 04Planned

   Ecosystem

   • Public programming interface
   • Marketplace for industry models
   • Partner programme for integrators
   • More templates and sample applications
6. 05Vision

   Vision

   • Federated operation across organisations
   • Offline operation in the field
   • Data processing at scale
   • Targeted retraining per installation once suitable hardware is available
   • Accreditation for classified information
   • Delivery into air-gapped environments