Development Update — September 2026

The latest Trabant Systems development cycle has produced an unusual combination of results.

Some began as technical incidents.

Others began as internal experiments.

A few started simply because an existing system worked, but did not explain clearly enough why it worked — or why it failed.

What connects them is not a common technology stack.

It is a common method.

A practical problem appears. The existing system is observed under real conditions. The smallest useful intervention is identified. The result is tested before deciding whether it deserves to become a permanent component.

During the current cycle, this approach has produced progress in five areas:

• Linux Trabant
• IFA — Internet Failover Architecture
• Trabant Total
• Trabant PNEUS
• AI directives and legal operational layers, including SSM, MINOL and TLR

Some of these systems are already stable and operating in production.

Others remain under extended production testing or deliberately experimental.

That distinction matters.

The objective is not to accumulate software.

It is to determine which systems and additional layers actually improve the environment in which they operate.

1. Linux Trabant

Status: STABLE / IN PRODUCTION

Linux Trabant has now moved beyond its initial experimental phase and is operating as a stable production environment.

The current distribution has continued to incorporate updates from its underlying Debian repositories and related dependencies without significant compatibility problems or disruption to normal operation.

This is important because one of the objectives of the project has never been to create an isolated or frozen legacy environment.

Linux Trabant is intended to remain lightweight while continuing to coexist with actively maintained software repositories and contemporary services.

The most notable recent development has been the integration of the OpenAI ChatGPT client.

The client is now operating normally within the Linux Trabant environment and has so far presented no significant problems in ordinary use.

This provides a practical demonstration of one of the ideas behind the project.

Older or resource-constrained hardware does not necessarily need to be separated from contemporary computing services merely because the surrounding software ecosystem has evolved.

A sufficiently lightweight operating environment can preserve the useful characteristics of existing hardware while providing access to current tools.

Linux Trabant is therefore no longer being treated simply as a laboratory proof of concept.

It is a working system.

For the moment, no major architectural intervention is required.

Development will remain incremental: upstream updates, compatibility testing and the addition of tools where they provide a clear practical benefit.

2. IFA — Internet Failover Architecture

IFA began with a simple resilience problem.

A website could become inaccessible through one network path while remaining technically available through another.

The initial objective was therefore not to redesign the hosting environment, but to introduce a minimal failover mechanism capable of changing the route used to reach the service.

The architecture has now undergone additional production testing.

The most recent extended test confirmed that the system can detect the relevant condition, alter the DNS/proxy configuration and subsequently restore the normal state without requiring a complete redesign of the underlying infrastructure.

The current implementation remains intentionally small.

It does not attempt to become a general high-availability platform.

Its function is more specific:

Detect a particular accessibility failure, introduce an alternative route and restore the preferred route when conditions return to normal.

The latest extended production test is documented separately:

IFA Trabant — Extended Production Test

Further testing will include additional domains and longer observation periods.

The important result at this stage is not that the architecture is theoretically possible.

It is that it has now operated satisfactorily under real production conditions.

3. Trabant Total

Trabant Total emerged from a completely different incident.

A WordPress website generated warnings in Google Search Console concerning invalid breadcrumb structured data.

At first sight, the problem appeared to originate from the SEO plugin responsible for producing the site’s schema.

Inspection of the rendered HTML showed something else.

The website was simultaneously producing two independent breadcrumb implementations.

One was a valid BreadcrumbList generated through JSON-LD.

The other consisted of legacy Schema.org microdata generated by the WordPress theme.

Although both described the same visible breadcrumb navigation, their simultaneous presence created inconsistent structured-data signals.

The solution did not require replacing the SEO stack or modifying the visible navigation.

It required removing the obsolete semantic duplication.

That intervention became the basis of what we now refer to as Trabant Total.

The implementation has continued to operate normally, and the structured-data incidents previously detected in Google Search Console have disappeared.

For the moment, no further intervention is required.

The system works, and there is no technical reason to modify a successful correction unnecessarily.

If the result remains confirmed over time, the next step will not be additional functionality.

It will be documentation and packaging.

Trabant Total may then be prepared as a dedicated WordPress plugin addressing this particular compatibility issue.

The objective would remain deliberately narrow:

One problem, one correction, one small plugin.

There is no reason to turn a successful corrective mechanism into a large framework merely because it can be packaged.

4. Trabant PNEUS

A third project emerged from an email security incident.

The message in question appeared, at first sight, technically legitimate.

Sender authentication passed.

The message used real infrastructure.

The link led through a genuine Microsoft SharePoint environment.

Nothing about those individual components was necessarily fraudulent.

And yet the complete sequence was wrong.

The apparent sender, the SharePoint tenant, the organizational context and the subsequent authentication flow did not form a coherent system.

The decisive question was therefore not:

Is this component legitimate?

It was:

Are these components coherent with one another?

That distinction is becoming increasingly important.

Modern phishing does not always depend on obviously fake domains, broken authentication or primitive copies of login pages.

A compromised legitimate account can send correctly authenticated mail.

A real SharePoint tenant can be used as an intermediary.

A genuine Microsoft authentication page can appear later in the sequence.

Each individual component may pass a conventional test.

The relationship between them may still be anomalous.

This incident led to the concept of Trabant PNEUS.

A second layer before the click

PNEUS is not intended to replace antivirus software, email filtering, Microsoft Defender, threat-intelligence databases or enterprise security platforms.

Those systems already exist, and many are significantly more sophisticated than anything we intend to build.

PNEUS addresses a smaller problem.

A suspicious message has already reached the user.

The existing filters have not blocked it.

The user is not yet sure whether it should be opened.

For some professions, this uncertainty is especially relevant.

Lawyers, for example, routinely receive legitimate communications from people they do not know personally: other lawyers, court representatives, potential clients, experts, insurers, professional bodies and public authorities.

A policy of simply refusing to interact with unexpected messages is therefore unrealistic.

PNEUS is intended to occupy the space between:

The filter allowed the message.

and

The user has decided to trust it.

Systemic coherence of sources

The first version will focus on something deliberately modest:

Systemic coherence of sources.

The system may examine elements such as:

• sender domain;
• Reply-To;
• Return-Path;
• Message-ID;
• Received headers;
• SPF, DKIM and DMARC results;
• domains used by embedded links;
• SharePoint, OneDrive or other external tenants;
• authentication endpoints;
• URL redirections;
• mismatches between visible and actual destinations;
• organizational relationships between the apparent sender and the linked infrastructure.

The question is not whether every component is independently valid.

The question is whether they make sense together.

A message could therefore produce a result such as:

Sender authentication: PASS

External infrastructure: legitimate

Organizational relationship: inconsistent

Authentication request detected: YES

Assessment: DO NOT OPEN

The importance lies in the explanation.

A user should not receive a mysterious numerical score without knowing why it exists.

Intended interaction

The objective is a deliberately simple Linux utility.

From a webmail inbox:

Right click → Analyze with Trabant PNEUS

The message would be inspected without normal rendering of its potentially active content.

No links would be opened.

No remote images would need to be loaded.

No attachments would be executed.

The result would be presented through a small number of clearly differentiated outcomes:

SAFE TO INSPECT

SUSPICIOUS

DO NOT OPEN

The first label is intentionally not simply “SAFE”.

No static inspection system should suggest absolute certainty where none exists.

Linux Trabant and standalone Linux use

PNEUS is intended primarily as an addon for Linux Trabant.

The same application could also be distributed independently as a .deb package for compatible Linux systems.

The objective is not to build another security suite.

It is closer in philosophy to a small utility: one function, minimal dependencies, immediate output and no unnecessary infrastructure.

Existing Linux components should be reused wherever possible.

The application should add logic, not duplicate the operating system.

5. AI Directives

Alongside these utilities, we have continued developing a separate line of work concerning the use of artificial intelligence in professional environments.

The emphasis here is not on building another AI model.

It is on defining the rules under which different models should operate.

SSM — a portable internal directive

SSM continues to function as an internal AI directive within EBAN workflows.

Its purpose is to impose discipline on the use of AI-generated information.

Among other principles, it requires clear separation between:

• documented facts;
• reported facts;
• interpretation;
• inference;
• uncertainty;
• and information that remains unknown.

It also preserves human validation where professional responsibility is involved.

The next stage is portability.

Instead of associating the directive with a particular AI provider or model, we are exploring whether SSM can be reduced to a sufficiently clear and reusable instruction layer — potentially a plain-text or similarly simple structured file — that can be supplied to different compatible models.

The principle is straightforward:

The model may change. The operating discipline should not.

This matters because dependence on a particular model can create a new form of technological lock-in.

If the methodology exists only inside one interface, changing the underlying model may require rebuilding the workflow around it.

A portable directive attempts to separate the operating rules from the engine executing them.

6. MINOL — Minimal Operative Layer

MINOL explores a related but different problem.

Where SSM governs, MINOL processes.

The Minimal Operative Layer is an experimental mechanism for receiving an unstructured request and converting it into information that can be reviewed more efficiently.

In controlled tests, MINOL has been used to:

• classify incoming requests;
• identify the apparent subject;
• separate supplied information from assumptions;
• detect missing elements;
• identify possible urgency;
• and prepare a preliminary structured response.

Technically, these processes can be automated to a significant degree.

That does not mean that we intend to automate them completely.

Within EBAN, MINOL has been used in controlled conditions to train and evaluate the system.

We do not currently intend to deploy it as an autonomous replacement for initial professional interaction.

This is a matter of design philosophy rather than technical capability.

An initial enquiry to a professional firm often contains incomplete information, emotional context or apparently secondary details whose significance may only become apparent through conversation.

Automating that interaction simply because it is possible can remove precisely the element that makes it useful.

MINOL therefore remains an experimental operational layer.

Its value lies partly in discovering where automation should stop.

7. TLR — Trabant Legal Relay

Legal work requires a more specialized version of the same architecture.

This is the purpose of TLR — Trabant Legal Relay.

TLR can be understood as the legal adaptation of MINOL.

The term relay is deliberate.

The system does not replace the lawyer at the end of the process.

It receives information, structures it and relays it toward professional assessment.

A simplified flow would be:

Request → TLR → structured legal information → SSM constraints → professional review

TLR may assist in identifying matters such as:

• jurisdiction;
• apparent legal area;
• procedural context;
• missing documentation;
• possible urgency;
• relevant official sources;
• and the point at which general information becomes individualized legal assessment.

The decision remains human.

The architecture can therefore be summarized as:

MINOL processes.

TLR structures legal information.

SSM governs.

The professional decides.

8. USResidence as a Practical Implementation

USResidence remains one of the principal environments in which these ideas can be tested.

The project is built around a source-first approach to information concerning residence and immigration-related pathways in the United States.

A user may understand the objective — studying, working, investing, joining family members or establishing lawful residence — without knowing which aspects of the factual situation are legally significant.

An assisted system can help organize that information.

It can identify missing elements.

It can direct attention toward authoritative government sources.

It can explain terminology.

But there is a clear point at which organizing information becomes professional judgment.

That boundary is not a technical failure.

It is part of the architecture.

Within USResidence, SSM provides the operating discipline while MINOL and TLR provide different forms of structured processing.

The purpose is not maximum autonomy.

It is controlled assistance.

9. Specialized Legal Directives

The same architecture is also being tested outside USResidence.

One example is the Larson Systemic Contrast Directive — Family Law.

This experimental directive explores whether AI can provide a structured second reading of a family-law matter before the lawyer introduces a new intervention into an already complex system.

The objective is not to create a new legal category.

Nor is it to transfer legal judgment to a machine.

The directive begins by separating:

DOCUMENTED FACTS

REPORTED FACTS

EXPRESSED EMOTIONS

INTERPRETATIONS

INFERENCES

UNKNOWN VARIABLES

It may then identify provisional patterns, alternative hypotheses and variables that require further information.

One underlying principle is particularly important:

A useful hypothesis is not one that eliminates uncertainty, but one that helps identify what information is required to reduce it.

The system may also contrast a contemplated strategy.

For example:

Proposed position: sole custody.

Available information: both parents appear suitable, with comparable availability and support networks.

Systemic contrast: no sufficiently clear differentiating variable has yet been identified to explain why ordinary residence should be concentrated with one parent.

The tool does not decide that the proposed position should be abandoned.

It asks a more useful question:

What is the differentiating variable?

If the lawyer has one, the strategy may become stronger.

If not, expectations may need adjustment.

A second opinion without a vote

The best description of this type of tool may be:

A second opinion without a vote.

The lawyer retains the file, experience, legal analysis, professional intuition and knowledge of the court.

The system supplies another structured reading.

Sometimes both will coincide.

Sometimes the system will identify a contradiction that disappears immediately once the lawyer introduces a fact that was not previously included.

And occasionally it may identify an objection that deserves further consideration.

That final situation may be its greatest value.

Not because the AI is necessarily more accurate than the lawyer.

Because it is capable of asking a different question.

The directive is equally defined by what it must not do.

It should not:

• decide whether somebody should divorce;
• diagnose psychological disorders;
• determine credibility automatically;
• mechanically classify behaviour as criminal;
• decide custody arrangements;
• predict judgments as deterministic outcomes;
• transform demographic patterns into conclusions about an individual;
• or replace professional judgment.

A particularly important distinction must remain intact:

The relational state may be uncertain.

The legal risk may require immediate action.

Both propositions can be true at the same time.

Systemic analysis must therefore coexist with legal and safety priorities, never displace them.

10. What Connects These Projects

Linux Trabant, IFA, Trabant Total, PNEUS, SSM, MINOL and TLR solve very different problems.

They are not intended to form an artificial software suite.

What connects them is a shared development principle.

Linux Trabant

Useful hardware did not require replacement merely because contemporary software environments had become heavier.

It required a lighter operating environment capable of connecting legacy hardware with current services.

IFA

A connectivity failure did not require a new hosting architecture.

It required another route.

Trabant Total

A schema warning did not require replacing the SEO system or the WordPress theme.

It required eliminating an incoherent duplicate layer.

PNEUS

An apparently legitimate email did not necessarily require another antivirus.

It required another layer of inspection.

SSM

Changing AI models should not require abandoning the professional discipline applied to them.

The directive should remain portable.

MINOL and TLR

Not every process that can be automated should be transferred completely to automation.

Sometimes the valuable intervention is simply to structure information before a human decision.

The common principle could therefore be expressed in a familiar form:

Do not rebuild the system when an additional layer can solve the problem.

11. Current Development Position

At the end of the current development cycle:

Linux Trabant is stable and operating in production. It has continued to incorporate updates from Debian repositories and related dependencies, and the OpenAI ChatGPT client has been integrated successfully into the working environment.

IFA has completed further satisfactory production testing and will continue to be tested under additional conditions.

Trabant Total remains operational, and the Search Console incidents that led to its creation have disappeared. If that result remains confirmed, the functionality may be documented and packaged as a dedicated WordPress plugin.

Trabant PNEUS has moved from incident analysis to project definition. The first objective is a lightweight Linux application capable of assessing systemic coherence in suspicious email before the user opens it.

SSM continues to operate internally and is moving toward a portable, model-independent directive format.

MINOL remains a controlled experimental operating layer rather than an autonomous client-facing system.

TLR — Trabant Legal Relay is being defined as the legal implementation of that operational architecture.

USResidence continues to provide a practical environment in which source discipline, structured processing and human validation can be tested together.

The Larson Systemic Contrast Directive — Family Law provides a separate experiment in applying the same architecture to professional legal contrast rather than automated decision-making.

12. Next Development Cycle

The next cycle will focus primarily on testing, observation and consolidation rather than expansion.

For Linux Trabant, the priority is continued production use, upstream compatibility and controlled incorporation of useful applications rather than architectural change.

For IFA, that means additional domains and longer production observation.

For Trabant Total, it means confirming that the current correction remains stable before preparing documentation and deciding whether publication as a standalone WordPress plugin is justified.

For PNEUS, it means defining the minimum viable inspection engine and determining how much useful analysis can be performed locally without relying on large external reputation databases.

For SSM, the principal question is portability:

Can substantially the same directive produce sufficiently consistent behaviour across different AI models?

For MINOL and TLR, the relevant question is not how much autonomy can be added.

It is where autonomy stops being useful.

That distinction continues to shape the work.

A Note on Development

Not every experiment described here will necessarily become a permanent product.

Some may remain internal.

Some may be simplified.

Some may be abandoned.

Others, like Linux Trabant, may move gradually from experiment to ordinary production use without requiring a dramatic transition.

A negative result can still be useful if it identifies a boundary that was previously unclear.

The purpose of these Development Updates is therefore not to announce a sequence of finished products.

It is to document what is being tested, what is already working, what has not yet been demonstrated and what we intend to examine next.

That record is part of the experiment.

Trabant Systems
DDR Lab

Small systems. Additional layers. Human control.