How we work

El Solitario is an independent technology blog covering programming, artificial intelligence, cybersecurity, infrastructure and open source. It is edited by Luis Navarro, a full stack developer based in El Salvador. This page explains how each article is made, which parts a person does and which parts tools do, and what happens when we get something wrong.

Who writes

Articles are signed by El Solitario Editorial because they are the work of a small team supported by tools, not of a single author. Luis Navarro is the managing editor: he sets the editorial criteria, oversees what gets published and is accountable for every article. That is why the byline says “Managing editor: Luis Navarro”.

Where topics come from

We follow primary sources and technical communities: official announcements and project changelogs, repositories, arXiv papers, security advisories (CVEs and vendor bulletins), Hacker News, Reddit and specialized media. Before anything is written, each topic goes through a filter: there must be a primary source we can cite, it must be useful to our readers and it must not repeat something we already published.

We do not publish sponsored content or paid placements. If an article ever involves a commercial relationship, it will say so at the top.

How articles are drafted

We use artificial intelligence as a writing assistant: it helps organize what the sources say, propose a structure and write a first draft. That draft is not published as is. Our editorial rules apply on top of it:

  • One type per article. A news piece covers what happened, the context, the numbers and what comes next. A guide explains a concept in depth. We do not mix both in the same text.
  • Titles that do not overpromise. The title is checked against the finished article and corrected if it claims something the article does not support.
  • Visible sources. Every article ends with linked references so you can go to the original.

Fact-checking

Specific claims (versions, dates, figures, names) are compared against the source that backs them. If a source contradicts the text, we look for another one; if none supports it, the paragraph is corrected or removed before publishing. This check is automated and not infallible, which is why the corrections policy below exists.

Hands-on testing

When the topic allows it (a tool, a code snippet, a configuration, a vulnerability with a public proof of concept), we test it in an isolated lab: virtual machines or containers with no access to real data or third-party systems. When an article includes results from those tests, the text says so. When we did not test something, we do not present it as if we had.

On security topics we only describe techniques already published by their authors or vendors, so that you can understand the risk and protect yourself.

Editorial criteria and oversight

The process is mostly automated, and we say so plainly. Before publishing, every draft goes through an editorial filter with criteria written by Luis Navarro: it has to add something that is not in the original source, back its claims with evidence, explain why it matters, compare itself with real alternatives and say when not to use what it presents. If it does not pass, it is not published. That is why we publish few articles a day, and some days none.

Luis does not approve every article before it goes out. He reviews every day what was published and what was rejected, adjusts the criteria and corrects when something is wrong. He also picks topics he considers important and asks for them to be researched in depth. Reader questions and corrections in the comments are part of that oversight.

Corrections

If you find a mistake, let us know. We fix factual errors as soon as possible. When a correction changes something important (a figure, a conclusion, a recommendation), the article says so, with the date of the update. We do not delete articles to hide mistakes.

Contact