Skip to content Skip to footer

AUSTRALIS · DEVLOG

When the mission became easier to follow

Historical period: 2026-07-06–2026-07-12

Descriptive infographic of documented AUSTRALIS progress from 6 to 12 July 2026: active public channels; a DIY/LatAm policy with an Accepted ADR and Bench ≠ Flight; and MIS-REQ-22 = Proposed — EGSE for weather instrumentation, pass logging, and park/inhibit at a ground station whose document remains Draft. It does not represent implemented or validated hardware or test evidence.
Descriptive infographic of documented AUSTRALIS progress from 6 to 12 July 2026: active public channels; a DIY/LatAm policy with an Accepted ADR and Bench ≠ Flight; and MIS-REQ-22 = Proposed — EGSE for weather instrumentation, pass logging, and park/inhibit at a ground station whose document remains Draft. It does not represent implemented or validated hardware or test evidence.

During the week, AUSTRALIS improved its public entry points—newsletter, WhatsApp, YouTube and website discovery—and documented two preliminary technical criteria: weather instrumentation and interlocks for the future ground station, and a DIY/low-cost policy favoring regionally accessible maker/COTS components. The public repository recorded no commits between 6 and 12 July; those documentation changes were published on 17 July. No documented mission-test results were found in the window, and spacecraft technical maturity did not increase.

The objective

AUSTRALIS already had public technical documentation, but the project was still difficult to discover and there was no clear path for choosing how to follow or support it. Demo pages remained in the sitemap, some community links were still pending and the footer did not reliably expose every available channel.

The objective for the week was to turn that fragmented presence into a clearer public route for following progress, receiving updates and proposing collaboration.

What changed

Between 6 and 7 July, a “Join / Support / Contribute” section was added, robots and sitemap were cleaned up to focus on real AUSTRALIS pages, and a footer problem that prevented the newsletter from rendering correctly was repaired.

Two public channels were also integrated:

  • a WhatsApp Channel for curated mission updates;
  • the @AustralisMission YouTube channel, linked from Home, Contact and the global footer.

On 10 July, two technical directions were also documented, still without a public commit inside this window:

  • a DIY/low-cost, non-commercial source-available design policy focused on maker/COTS components available in Argentina and Latin America, without confusing Bench with Flight-Like or Flight;
  • a proposal for local weather instrumentation at the ground station to record the environment of each pass and provide inputs for future park/inhibit interlocks.

These were architecture, requirements and documentation changes, not evidence of implementation or physical testing.

Evidence and maturity

The evidence for this week combines website/community implementation with architecture and requirements documentation:

  • Home, Contact, Mission and RF/LoRa returned HTTP 200 after the changes;
  • newsletter, WhatsApp and YouTube were visible in the intended public locations;
  • robots and sitemap were focused on the mission domain and real pages;
  • the public AUSTRALIS-1 history contains zero commits dated between 6 and 12 July;
  • the 10 July technical record documents the local DIY/LatAm policy and ground-segment weather changes, later integrated publicly in commit fd571017… on 17 July.

No physical, bench, RF, flight-software or mission test results were found inside the window. The documentation changes did not close a gate or increase spacecraft technical maturity.

What we learned

A documented mission also needs a coherent public interface. Newsletter, website and curated channels do not increase spacecraft technical maturity, but they help future evidence be found, understood and followed without mixing announcements, collaboration and technical operations.

Starting with a WhatsApp Channel —rather than an open community— prioritized privacy, moderation and verified updates. Engineering followed the same discipline through two boundaries: DIY/low-cost does not mean flight-ready, and a documented weather station is not the same as validated sensors, thresholds or interlocks.

Later evolution

The DIY/LatAm and ground-station work documented on 10 July was integrated into the public repository on 17 July in fd571017…; the public-v0.2 snapshot was published afterward through another commit on the same day.

The late-July audit kept the DIY/LatAm policy as an Accepted ADR and left MIS-REQ-23/24 active. Weather instrumentation, however, returned to MIS-REQ-22 = Proposed — EGSE: the ground-station document remains Draft, and sensors, thresholds, park/inhibit logic, quality and calibration require an Accepted ADR and hazard analysis before adoption. The project remains experimental pre-SRR with Gate A Open.

Next historical milestone

The next verifiable public window begins on 17 July: repository integration of the work documented on the 10th and the later publication of the public-v0.2 snapshot. That public integration should be reviewed as a separate period without rewriting the decisions’ date of origin.

Visual material

The infographic descriptively summarizes the week’s documented progress: active public channels, the DIY/LatAm policy with an Accepted ADR and Bench ≠ Flight, and MIS-REQ-22 = Proposed — EGSE for weather instrumentation, pass logging and park/inhibit at a ground station whose document remains Draft. It is an editorial summary: it does not represent implemented or validated hardware or test evidence.

Public sources