How we publish.

Three kinds of writing

Studio articles & project notes

Design decisions and build examples from our own work. Dated captures, fictional records and concept previews are identified where they appear. A design example does not establish customer results.

AI news & analysis

Source-linked coverage with an announcement date and an editorial review date. Provider claims are attributed; our proposed uses are analysis. Availability and pricing can change after a briefing is published.

Open Source / Local

Project guides based on upstream documentation. Commands, prerequisites and recovery considerations belong with the instructions. Unless an article documents a test environment and its results, it is a documentation-based guide.

Evidence before claims

We link to original announcements, documentation and source repositories for technical claims. We distinguish an announced feature from a public release and a demonstration from a completed production workflow. We do not turn a vendor benchmark into an araNET result.

AI tools assist research organization, drafting, editing and illustration. A generated answer is not a source. The published article must identify the evidence behind its claims and keep assumptions visible.

Images should show something real

Our project screenshots retain the source interface. Example customer records are labeled. Upstream project logos and screenshots retain attribution. Original diagrams explain a workflow; they do not impersonate a vendor’s product screen.

Updates stay at the same address

A substantial revision keeps the article’s original URL and publication date, adds an updated date and describes the change. Historical images retain their capture dates. We do not change a date simply to make an unchanged story look new.

Report a correction

Send the article URL, the passage in question and a supporting source to hello@aranetsolutions.com. We review the claim against its source and correct the existing page when a change is warranted.