Why I started LinkedIn from scratch.
Where SysWarden goes next.

A smaller network can leave more room to think

Starting again gives me an opportunity to be more intentional. Who do I want to learn from? Which discussions deserve a proper response? Where can I contribute something useful instead of adding another agreeable sentence to an already crowded thread? Those questions matter more to me than recovering a previous follower count as quickly as possible.

A network becomes useful when someone can describe a constraint you had missed, share an operational lesson or ask a question that changes your design. Sometimes that person has a very senior title. Sometimes they are the administrator who has been maintaining an awkward system for years. Sometimes they are starting out and still ask the obvious question everyone else has stopped asking. All three can teach me something.

Of course, professional relationships also need ordinary human conversation. We do not need to turn every exchange into an architecture review. A little humour helps. My point is that there should be room for substance when the subject calls for it. I would rather finish a discussion with one useful insight than with twenty notifications and no clearer understanding of the problem.

Being self-taught means remaining teachable

I describe myself as self-taught because that is my path, not because it gives me an exemption from scrutiny. Learning independently creates habits: searching, reading, trying things, getting stuck, checking another explanation and trying again. It also creates blind spots. If I only discuss my work with people who approach problems the same way, those blind spots become comfortable. Comfortable is a poor reason to keep them.

That is why I value people who can take an argument apart carefully. Show me the assumption that does not hold. Explain what happens in your environment. Point me towards the evidence. If I have misunderstood something, I want the opportunity to correct it. Changing my mind after a good explanation is useful progress. Protecting my first opinion at all costs would be an exhausting hobby.

I also want to get better at saying, plainly, "I do not know yet." That answer creates room for investigation. Pretending to know creates work for whoever has to untangle the consequences later. In cybersecurity, where incomplete information is ordinary, the ability to name uncertainty is a professional skill. I would like more of that in my conversations and more of it in the software I build.

Bring your constraints, especially the inconvenient ones

Cybersecurity architects and CISOs often look at the same decision through different windows. One conversation starts with trust boundaries, privileges and failure modes. Another starts with exposure, continuity, accountability and what a team can realistically operate. I want both perspectives around the table. A technically attractive control still needs to fit the organisation that will live with it.

Tell me there is a short maintenance window. Tell me the server cannot reach an external service. Tell me the operations team is small, the recovery procedure is unclear or the person approving the change will need a readable explanation. Those details are not interruptions to the architecture discussion. They are inputs to it. A design that depends on ignoring them is already drifting away from the problem.

So, if you reconnect with me, there is no special password and no requirement to agree with my posts. Bring curiosity, experience, a specific question or a different point of view. Explain your reasoning. Be willing to hear an answer. I will try to do the same. That is the professional network I am rebuilding, and it is closely related to the community I want around SysWarden.

PART TWO / THE PRODUCT

The same standards belong in the code

SysWarden gives that mindset a very practical outlet. The project sits in the world of Linux host defence, where signals, policy and enforcement have to meet real operating systems. A decision can affect an administrator's access, an application connection or the recovery path of a machine. That makes the quality of the decision, and the explanation that accompanies it, a serious matter.

The direction I have set for v5.00.0 LTS is a connected workflow: detect, explain, contain, prove and roll back. Each verb creates obligations. Detection needs a trustworthy observation. Explanation needs a traceable reason. Containment needs a bounded action. Proof needs an identifiable record. Rollback needs a recovery path that has actually been exercised. I want to carry SysWarden through that whole chain.

That is a substantial ambition, and I am comfortable calling it one. I am equally comfortable saying that planned work is still planned. The public v5 tracker describes work packages, dependencies and acceptance conditions. At the time of writing, the site continues to distinguish the stable v4.04.3 release, v4.10.0 source qualification and the planned v5 LTS. A new article does not promote one of those states into another.

IVVQ starts before the release candidate

The engineering discipline behind this direction is IVVQ: Integration, Verification, Validation and Qualification. I use those terms as a practical framework for organising work and evidence. The questions are straightforward. Do the parts work together? Does the implementation meet its specified requirements? Does it serve the intended operational need? Can this exact candidate be accepted within a defined environment and scope?

The useful part is what happens when those questions are asked early. Before implementing a feature, I want to understand its expected behaviour, its limits and how we will recognise success or failure. What should happen when an input is missing? Who is allowed to approve a change? What must remain available during recovery? Which observations would cause us to reject the result? Those answers shape the implementation.

IVVQ also needs to stay proportionate. A focused utility and a security component acting across several hosts do not need identical test programmes. They both need explicit claims and evidence appropriate to those claims. For SysWarden, I am choosing a demanding standard because its operational role warrants one. Calling this approach IVVQ does not claim external certification, universal compatibility or freedom from defects.

For the distinction between verification and validation: NASA Systems Engineering Handbook, section 2.4. The qualification approach described here is my engineering framework for SysWarden.

Integration: follow the signal all the way through

Consider an authentication event. A handcrafted example can establish that a parser recognises one string. A native integration test asks a wider question: does the actual service produce the expected event, does the real collector receive it, and does the installed package carry it through the intended decision path? Log formats, permissions, service managers, rotation and startup order all become part of the answer.

This is why a packaging boundary matters to me. A binary executed from a development directory is useful during implementation. An installed DEB, RPM or APK introduces another set of responsibilities: ownership, service configuration, dependencies, upgrades and removal. The operator receives a package in an environment. The integration evidence needs to represent that experience closely enough to support the claims we make about it.

I want the interfaces between components to be explicit enough that a mismatch is visible. An unknown format should not quietly become a reassuring empty screen. A missing source should not look indistinguishable from an absence of suspicious activity. A message lost between observation and presentation should leave a diagnosable gap. Integration is where we discover whether the whole chain tells a coherent story.

Verification: make the requirement testable

Verification asks whether the implementation conforms to what we specified. That works best when the specification contains something more precise than "secure," "fast" or "robust." If a policy update is meant to preserve unrelated rules, we need to observe those rules before and after the change. If an operation must fail without partially applying state, the failure path belongs in the test.

A useful requirement names a behaviour, a boundary and an observable result. For example: a rejected configuration leaves the previous effective policy intact, and the command returns a clear failure. We can then examine both the stored configuration and the real host state. Checking only the exit message would leave half the claim unexamined. The test should follow the consequence we care about.

Positive cases are only part of this work. Malformed input, duplicate events, stale information, interrupted operations and simultaneous changes can reveal assumptions hidden by a tidy demonstration. I want those cases considered deliberately. The aim is to discover where the design needs stronger boundaries, clearer ownership or a more honest error message before someone depends on it under pressure.

CI is valuable here. It provides repeatable checks and a fast way to catch regressions. A green pipeline tells us that the checks included in that run passed for the identified revision and conditions. That is useful evidence with a defined scope. I still need to examine native packaging, operational scenarios and the rest of the acceptance requirements before drawing a release-level conclusion.

Validation: would this help the person on duty?

Validation brings the intended use back into the room. A workflow can satisfy its technical requirements and still ask too much of the person operating it. A security decision may be accurate but poorly explained. A recovery command may exist but be hard to find. An interface may be responsive while making it difficult to distinguish current information from something observed several minutes ago.

I want to ask practical questions. Can the operator understand why an address was blocked? Can they see which evidence contributed to that decision and where the evidence is incomplete? Can they distinguish an explicit allow policy from a lack of detection? When a change fails, can they determine whether anything was applied? Can the person reviewing the incident reconstruct the sequence without guessing?

Validation also means listening when someone says a technically elegant workflow is difficult to operate. That feedback may lead to a simpler command, clearer terminology or a better default. I do not want users to need my personal explanation every time they encounter a difficult case. The product and its documentation should carry the explanation well enough for another professional to make an informed decision.

Qualification: accept an identified candidate

Qualification is where I expect the claims, the candidate and the evidence to line up. Which source revision was evaluated? Which package bytes were installed? Which operating systems and configurations were covered? Which scenarios passed? Which limits remain? A useful qualification record should make it possible to answer those questions without relying on the maintainer's memory or a convenient screenshot.

The acceptance conditions need to exist before the result is known. Changing a threshold after an inconvenient measurement would make the report easier to finish and harder to trust. If a requirement was wrong, we can review and change it explicitly. That is a different engineering decision, with a reason and a traceable consequence for the evidence. The distinction needs to survive in the record.

When a blocking defect appears, I want the process to stop that acceptance claim. The successful observations still have value and should be retained. The failed attempt has value too: it describes a condition we now understand better. A correction then needs an impact analysis, a clear candidate identity and the relevant new checks. That is how a qualification campaign becomes useful engineering knowledge.

Evidence should survive a break, a fix and a different reviewer

There is a very human reason for keeping structured evidence: nobody should have to reconstruct a week of work from a long conversation. A usable record identifies the requirement, environment, action, observation and conclusion. It also identifies the files behind that conclusion. Checksums help establish file integrity; the surrounding record explains what those files mean and how they were obtained.

Preserving evidence does not mean treating every old result as permanently valid. When code changes, I want to know what the change can affect. Some observations may remain applicable under a reviewed continuity argument. Others must be repeated. The decision needs to be explicit enough for a reviewer to challenge it. Keeping everything and blindly trusting everything are very different engineering choices.

The same discipline applies to laboratory restoration. A campaign should account for temporary services, network rules, fixtures and recovery settings. We should know what was changed and verify the return to the agreed state. Otherwise, the next campaign inherits an unexplained environment, and its result becomes harder to interpret. Cleaning up properly is part of producing evidence that another run can build on.

What I want v5 LTS to make possible

The planned v5 work builds on four connected pillars. The first is authenticated file integrity: establish an operator-approved baseline, observe change and reconcile it against the authoritative state. A change in a file is an observation that needs context. I want the project to explain what changed and how that relates to the approved baseline, rather than casually treating whatever it sees first as trustworthy.

The second pillar is deterministic incident correlation. I want related observations to form an intelligible timeline, with a reason for their relationship and visible limits where information is missing. If two reviewers examine the same inputs and policy, the explanation should be reproducible. That gives a professional something concrete to inspect, contest and improve. It also makes confusing outcomes easier to investigate.

The third pillar is reversible response with signed evidence. The plan calls for typed, bounded actions and explicit approval by default. A response should describe its intended effect, record what actually happened and have an exercised recovery path where rollback is supported. Signing an evidence capsule is useful only alongside a clear trust model, suitable key handling and an independent way to verify the record.

The fourth pillar is secure operation across multiple nodes through a responsive terminal interface. I want visibility across registered, authenticated peers while keeping local authority and stale or unavailable information understandable. Seeing several machines on one screen must not hide differences between their states. The interface should help an operator distinguish what is known, what is current and what still needs attention.

LTS is a commitment to maintainable decisions

The LTS direction matters because a security project needs a life after its release announcement. Operators need to understand what will be supported, how maintenance changes will be evaluated and what an upgrade can mean for their configuration and data. The roadmap proposes a long-term support approach, with the actual support commitments to be defined and published before they become active.

I want major releases to receive comprehensive qualification, and maintenance releases to receive checks appropriate to their changes. That requires disciplined impact analysis and explicit treatment of unaffected evidence. It also requires accurate compatibility information. A rollback can involve data and configuration formats as well as executable files. A signed older package alone does not prove that returning to it is supported.

That is where determination needs a little restraint. I intend to take SysWarden a long way, but I want each step to leave something maintainable behind it. Documentation, migration paths, understandable decisions and repeatable acceptance are part of that work. They are what make it possible for someone else to use, review and eventually help maintain the project without needing to reverse-engineer my intentions.

Open source deserves a sustainable standard of quality

Making the code available creates opportunities for inspection, contribution and independence. It does not remove the cost of engineering. Native environments, infrastructure, development tools, documentation and careful review still consume resources. I want to be candid about that, because a project cannot promise durable maintenance while treating the maintainer's time and finances as an unlimited background service.

I am happy to receive a reproducible bug report that challenges a feature I worked hard on. I am happy to hear that a command is confusing or that a documented assumption does not fit a real environment. That information gives us something to improve. The most helpful community is one in which people can report those problems without being treated as an obstacle to the project's story.

This brings me back to LinkedIn. The conversations I want there are the conversations that can make this work better: practical, curious, technically serious and comfortable with disagreement. We can discuss architecture, operational reality, risk or funding without pretending any of them exists in isolation. We can also enjoy the process. Being rigorous does not require being permanently solemn.

The invitation is simple

I will keep learning, asking questions and revising decisions when the evidence gives me a reason. I will keep developing SysWarden towards the v5 LTS vision, with IVVQ built into that development. And I will keep separating an ambition from a delivered capability, a successful check from a complete qualification, and a confident statement from something we can actually demonstrate.

Bring the difficult question. Show me the constraint I have missed. Tell me what would make the solution useful to the person who has to operate it. That is a good conversation to have, and a good place from which to build the next version.