What it does, and what it costs.

The Sector is a desktop application for analysts working on Australia's early childhood education and care sector. It replaces a manual eight-step process that previously ran across a spreadsheet, a browser and a search engine.

A run starts from the national provider list, reconciles it against the ACECQA approved provider and approved service registers, researches each provider on the open web, puts every disagreement to a person to decide, and fills a snapshot table that exports as a workbook. Every accepted figure keeps the sources it came from.

Who it is for

One analyst at a desk, running the sector view periodically. It is a single-user desktop application, not a server or a shared service. Runs are kept locally and can be reopened.

What it is built on

C# on .NET 8 with Avalonia UI, compiled to a native binary for each platform. There is no Electron and no embedded browser rendering the interface, so the installed application is small and starts quickly. The one place a browser engine is used is fetching the ACECQA registers, which is covered under the eight phases.

No installer is published yet. Packaging, code signing and the update feed are the remaining items before the first tagged release. This section describes what installing will involve, so the process is known before it exists.

Windows

• Download Setup.exe from this site.
• Run it. The application installs per-user, adds a Start Menu entry and an Add/Remove Programs entry.
• Until code signing is enrolled, SmartScreen will warn that the publisher is unknown. That warning is accurate and will disappear once the certificate is in place.

macOS

• Download the .dmg, open it, and drag the application to Applications.
• The build is signed with the client's Apple Developer certificate and notarised at publish, so Gatekeeper opens it without a right-click override.

The application opens on phase 01 with a single primary control. Each phase completes, shows what it produced, and hands over to the next when you press NEXT. Nothing runs without being started.

• Open the application. Research options carry the OpenAI API key; set it before reaching phase 04.
• Press START A NEW RUN. Phase 01 collects the provider list and asks you to confirm which entries are for-profit.
• Phase 02 fetches the two ACECQA register files. On Windows this happens inside the application; if it fails, import the two CSV files by hand.
• Phases 03 to 05 build the tables, research each provider, take your approvals and fill the snapshot.
• Export the workbook from the snapshot screen.

Phases 01 to 05 are built and produce the snapshot table. Phases 06 to 08 turn that table into the finished report; they are designed but not implemented, and appear dimmed on the application's own phase rail.

Phase 02, and why a browser engine is involved

The ACECQA register downloads sit behind a bot-protection layer. Plain HTTP requests and headless browsers are both refused, so the application fetches the two CSV files through an embedded WebView2 instance driven at a normal viewport. The window is not shown; it renders to a one-pixel sliver while reporting a 1280 × 900 virtual viewport.

If the fetch is refused, the phase falls back to manual import: download the approved providers and approved services CSV files yourself and point the application at them. Matching is by exact provider registration number, not by name.

Phase 04 is the only phase that spends money and the only one that can be wrong in an interesting way. It asks a set of fixed questions about each provider, answers them from web search, and then decides whether the answer is safe to accept or has to go to a person.

How an answer is produced

Each provider is researched over three independent passes against the OpenAI Responses API with web search enabled, under a strict response schema. Providers are researched concurrently, ramping from one at a time up to six with backoff on error, so a national run finishes in hours rather than days.

When an answer is accepted without asking

An answer is accepted automatically only when all three passes agree on it and at least two independent domains support it. Anything else becomes a question on the approval screen, carrying its candidate answers and the sources behind each. A domain that repeatedly produces answers that survive approval gains standing in a trusted-sources ledger; one that produces answers that are overturned loses it.

Approving

The approval screen works provider by provider, then question by question, advancing on its own as you decide. Three bulk actions are available once a run has produced enough to judge: accept every answer two of three passes agreed on, accept the provider's own website where it is the source, or take the best-supported answer for everything remaining. SKIP FOR NOW and CONTINUE ANYWAY both leave questions open rather than forcing a decision, and open questions survive into the next run.

Every run researches afresh

Starting a new run issues new searches for every provider. Answers accepted in an earlier run are not reused as this run's findings; they are kept only to flag a contradiction if the new research disagrees with them. This is a setting in the research options, and it is the reason a repeat run costs roughly what the first one did.

Phase 05 fills a seventeen-element snapshot matrix from everything the run established. The snapshot screen carries tabs for the provider key, Tables 1 to 3 and the snapshot itself, with provider chips to move between them and pinned columns so a wide table stays readable.

What the export contains

• The snapshot table, one row per provider, seventeen elements wide.
• The provider key, scoped to that run.
• Table 1, the centre network, and Table 2, quality ratings, with the Australia long day care average as a ruled-off benchmark line rather than as a provider row.
• Answers still awaiting approval, exported as the best-supported candidate and marked UNCONFIRMED.

The export is an .xlsx workbook written through Save As, with a control to reveal the saved file in Explorer. Nothing is uploaded.

The application itself has no metered cost. Running phase 04 spends money on the OpenAI API, billed to your own key at whatever rate your account carries. Every figure below was measured on a real run rather than estimated.

The full run produced 254 automatically accepted answers and raised 386 questions for approval. Cost per provider is not constant: the national run cost roughly twice per provider what the two-provider pilot did. Larger providers carry more subsidiary entities and raise more open questions, which is consistent with the difference, though the split between those two causes has not been measured.

Controlling what a run costs

• Run a subset of providers rather than the full national list.
• Reduce the number of research passes, at the cost of accepting fewer answers automatically.
• Reuse an earlier run's accepted answers instead of researching afresh, where a point-in-time view is not required.

The application will check for updates on launch, download only the changed parts of a release, and apply them on the next restart. The update feed is served as static files from this domain, so no additional service is involved.

Where data is kept

Everything a run produces is written to a single SQLite database on the machine that ran it, alongside an application log. Exports are written wherever you save them. Luna Labs operates no server for this application, receives no copy of your runs, and has no ability to read them.

What leaves the machine

• Requests to the national provider list and the ACECQA register downloads, which are public sources.
• Research queries to the OpenAI API, containing provider names and the questions being asked about them. These are subject to OpenAI's terms and to whatever data controls your account carries.

The registers and the provider list are public records about organisations. The application does not handle records about children, families or staff, and no personal data of that kind passes through it.

Your API key

The key is stored locally and is excluded from source control and from the application log. It is sent only to the OpenAI API.

The Sector is built and maintained by Luna Labs. Questions about a run, a figure the application produced, or the release schedule go through lunalab.studio/contact.

Back to downloads