What it does, and what it costs.

Apograph 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.

Releases are published to updates.thesector.lunalab.studio, a Cloudflare-hosted store that holds the installers and update packages, and no source. The download button on this site points at the current Setup.exe there, so it never goes stale. Earlier versions stay in the store beside the current one, which is what lets a copy that has missed several releases update in one step.

Windows

• Download Apograph-win-Setup.exe (56.9 MB) from this site or from the releases page.
• Run it. It installs for your user only — no administrator prompt — into %LOCALAPPDATA%\Apograph, and adds a Start Menu entry, a desktop shortcut and an Add/Remove Programs entry. It takes a few seconds and asks nothing.
• Apograph is not code-signed yet, so Windows may show Windows protected your PC. Choose More info, then Run anyway. The warning is about the missing certificate, not about the file; it goes away once signing is enrolled.
• If Microsoft Edge WebView2 is missing — rare, but it happens on freshly imaged or LTSC machines — the installer fetches it from Microsoft first. One extra progress step, nothing to answer.

macOS

• Download the .pkg for your Mac: Apple silicon for any Mac since late 2020 (M1, M2, M3, M4), Intel for the ones before. Apple menu › About This Mac says which.
• Open the .pkg. It installs Apograph into your Applications folder. The build is not signed, so macOS will say it cannot verify the developer: right-click Apograph in Applications, choose Open, then Open again in the dialog — or allow it under System Settings › Privacy & Security. That is asked once; updates afterwards install themselves.
• Signing and notarisation begin the day an Apple Developer Program membership (US$99 a year) is in place; the warning goes away from that release on.

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.

History

Clicking a run in History opens it in a popup over the page. Its Deliverables list every file made for the run: the omnibus PowerPoint and PDF and its gaps PDF from each build, each edited omnibus the split accepted, each report split from it, and the exported Snapshot workbook, with its size, when it was made, and whether it is on this computer, on the portal or both. Each can be opened, shown in its folder, saved as a copy, downloaded from the portal, or, if it is only on this computer, kept on the portal. Beside them, read-only, are the run's tables: the Snapshot table, the Provider key, and Tables 1 to 3. Delete run is in the popup too, and asks first. From 0.2.8 the question says exactly what goes and what stays: the run, its provider key, the enforcement detail behind its flags, its snapshot, the corrections typed over it and the year figures it filed are removed from this computer, and a deleted run no longer feeds a later one (a founding-year correction made in it goes with it). Left in place are the run's files in the report folder, the versions and files the portal has kept for it, and the governance and setting answers given for providers, which belong to the provider rather than the run.

Phases 01 to 05 produce the snapshot table. Phases 06 to 08 turn the saved table into the finished report. All eight are built and live on the application's own phase rail.

Phases 06 to 08: the report

A report is built from a run that has been saved to the portal, so the three report phases open only once Save new snapshot version on the snapshot screen has saved the run as it stands. Each press keeps a new version of the run (v1, v2, v3 and so on); earlier versions and the research are kept, and the report reads the latest. Phase 06 offers the report types: the LDC Review — Omnibus is the one generated; the Providers report and the Sector Review beside it are made when the edited omnibus is uploaded, and the others are listed and greyed until their own workflows exist. Then Check the database lists, provider by provider, what the report would print and what it lacks: a logo to upload, a governance or setting-type choice the research disagrees with, a box the page would print its stock text for, the edition's letter, signatures and date. Each provider has a tab of its own, in a list with a search and All, Needs review and Edited filters; the theme colour, the letter, signatures and date have the Edition tab, and anything the check found that has no box to fill is under Report notes. What is already in place is shown as such and can be changed. One Save new version saves the answers, edition details and chosen images together as a new version of the edition's report inputs; earlier versions and the research are kept, and the check runs again. An answer belongs to the edition, not to one run: it is laid over the run when the report reads it, still applies when a new run for the same year is saved, and never changes the run's own cells. Phase 07 runs the generator: the boxes that need words are written by the model chosen under Research options, on your own OpenAI key (about US$1 a build), and every number is placed by code, never by the model. Phase 08 shows every page of the omnibus as an image, opens its PDF, and downloads its PowerPoint wherever you choose. Open gaps PDF, with the number of items beside it when there are any, opens every gap and review note the build recorded, as a PDF the build writes beside its deck in the app's report folder as <deck name> - gaps and notes.pdf (the download copies only the PowerPoint); it also names the Snapshot and report-input versions the build read. Closing the application mid-build stops the generator with it. Since 0.2.8 that holds on a Mac when the application crashes or is force-quit too: the generator notices within a couple of seconds that the application has gone and stops, so a build can no longer go on making paid OpenAI calls that nobody can see.

The generator is a bundled Python runtime installed beside the application on both platforms; nothing has to be installed by hand. The Ready to run card on the Home page checks, at every launch, what a run needs on this computer — the portal sign-in, the OpenAI key, the register route, the report generator, the report fonts, LibreOffice for the split's PDFs, the update feed and disk space — and offers the fix for each: sign in, add the key, install the fonts, repair the generator, install LibreOffice. Since 0.2.8 the sign-in, register-route and key lines are checked again when the portal sign-in or the OpenAI key is changed in Settings, so the card (and the banner on the report steps) updates without CHECK AGAIN. A step that needs one of those opens with the same sentence and link rather than a disabled button.

The omnibus

The report is generated once, as the LDC Review — Omnibus: the cover, the contents, the Message from The Sector, 01 The year that was with its Key historic data page, 02 The year ahead, 03 Tables, 04 Providers, the about page and the back cover. The year that was is drafted only from the portal's own figures, ACECQA's quarterly NQF series and the Department of Education's Child Care in Australia series, and every figure it prints is one it was given. Key historic data is a table worked out exactly from the same series, one column per year for the latest eight years, with the source on each row. The year ahead is five theme boxes carrying stock text, for you to write in PowerPoint; the gaps PDF lists them as still to write.

The theme colour

Each edition is drawn in one accent colour, which takes the place of 2024's coral throughout: on the pages the generator draws, and in the icons, frames and dividers that carried the coral. It is the first item on the report step's Edition tab, Theme colour: a colour picker and a hex box that stay in step, with a swatch beside them. The box takes a colour written #RRGGBB and nothing else, and suggests the most recent edition's colour on record, or 2024's coral (#DC674F) when there is none. It is saved with Save new version, like the letter, and the omnibus is not generated until it has been.

Editing the omnibus, and splitting it

Download the omnibus PowerPoint from phase 08 and edit it in PowerPoint: write The year ahead, change any wording, add or move slides. Then bring it back to the UPLOAD THE EDITED OMNIBUS box on the same screen, by dropping the .pptx on it or with CHOOSE THE EDITED POWERPOINT. The app splits it into the Providers report (the Providers pages, then the Tables) and the Sector Review (The year that was and The year ahead; its name is still to be confirmed). Both keep the cover, contents, letter, about page and back cover, and every edit, picture and note you made on the pages they keep. The page numbers, the section numbers and the contents are renumbered for each new deck, and each cover carries that report's own line. A slide you added stays in the section PowerPoint shows it in. Each report has its own OPEN PDF, DOWNLOAD POWERPOINT, DOWNLOAD PDF and SHOW IN FOLDER, and anything the split had to decide is listed under NOTES FROM THE SPLIT. A later edit goes in the same way, with UPLOAD A NEW EDIT.

LibreOffice, for the PDFs

The split's PDFs are made by LibreOffice, and since 0.2.7 it comes with the app (LibreOffice 26.2.6, from The Document Foundation's own files), so nothing is downloaded and nothing has to be installed by hand. On Windows it sits inside the application and is ready from the first launch. On a Mac it ships as LibreOffice's own signed package inside the application and is unpacked into the app's data folder the first time the app starts, which takes a minute; a split started before that waits for it, with its progress shown in the upload box. If it could not be unpacked, the Ready to run card says why, and a LibreOffice already installed on the computer is used; without one the split still makes both PowerPoints, without their PDFs, and says why. The split itself does not need PowerPoint on the computer that runs it.

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. On Windows 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.

On a Mac there is no browser engine to embed, so the download runs through the data portal instead. The portal's own hidden browser has already fetched and archived the registers, and the application brings the two files down from there. An account with the admin role has the portal collect today's registers first, which usually takes about a minute and a half, and step 3 shows that wait as a clock against the usual time rather than a download sitting at nought; a member account gets the newest month the portal has archived and is told which day it was collected. A Windows machine without the WebView2 runtime takes the same route. Either way the files land in the same place and the match that follows is identical.

On a Mac the application log is under ~/Library/Application Support/TheSector/logs, and the whole route can be watched from Terminal: /Applications/Apograph.app/Contents/MacOS/TheSector.App --fetch-test signs in as the application would, brings both files down, checks that they read as registers, and says which step failed if one did.

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.

Starting it

Phase 04 does not start itself. It opens showing what it is about to do, how many providers and how many at a time, behind a START RESEARCH button, and nothing is asked of OpenAI until that button is pressed. Pressing NEXT on the phase before it therefore costs nothing. STOP ends a run in progress and the button returns, so a run can be stopped and taken up again.

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, one, two, four or six at a time on the chooser above the tiles, so a national run finishes in hours rather than days.

That chooser stays live while the run is going. Raising it lets that many more providers start straight away; lowering it stops new ones starting until enough have finished, and never interrupts a search already paid for. The feed records the change as it happens.

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.

The revenue figure is corroborated differently, because the schema gives each pass a single source for it. Two of the three passes must have found the figure, agreeing on the exact financial year and on an amount within half a per cent. Requiring two separate websites instead would set a bar most private providers cannot meet, since their only published figure is their own annual report or their ACNC filing.

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. CHANGE THIS on an answer already approved takes the approval back, not only on the screen: since 0.2.8 the question is open in the saved run too, so the Snapshot and the report never print the answer you withdrew, and the websites that earned a point in the trusted-sources ledger for it in this session lose that point (points from earlier sessions are history and stay). Approving the same answer again earns each website its point only once in a session, however many times it is changed.

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 the seventeen-element snapshot from everything the run established, one row per value: contact details are four rows (address, phone, email, website), the executive leadership one row per person (Person 1, Person 2 and so on, in the order the research named them), the quality ratings three (working towards, meeting, exceeding), and the centre network one row per year. This year's count comes from the registers; every earlier year is read from the data portal, never composed by the app, and a year the portal holds no count for is left out. 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.

Putting a cell right

Every cell in the snapshot table can be edited where it sits. Clicking one opens the editor that suits the element: a list holding only the two allowed answers for governance type and setting type, a number box for the founding year and the head count, and a long-text box for the prose elements. Enter saves, Escape cancels, and clicking away saves.

Each person in the executive leadership is a cell of their own, edited as one line, as in Jane Smith (CEO). + ADD A PERSON beside element 8's last row adds a row for someone the research missed, and REMOVE THIS PERSON in a person's editor takes them out (the cell then reads Removed by you; emptying it brings them back). The report's leadership box reads the people in that order.

An edited cell reads Entered by you and loses any UNCONFIRMED marking, because a person has now answered it. Emptying a cell deletes the correction and hands the cell back to whatever the run established, so an edit can always be undone. A correction to the founding year carries into the next year run, since a founding year cannot change; a correction to any other element is marked in the next run rather than applied, because next year the fact itself may be different.

What you type or choose in a run is also sent to the portal as typed when the run is saved, and from 0.2.8 the report treats it as your correction. A governance or setting type you chose is not overridden by research, a quality-rating figure you typed is kept instead of the register's counts, and prose you wrote is printed as written and never drafted again. An answer carried over from an earlier run still counts as carried, not typed, so research can still overrule it. A run saved by 0.2.7 keeps the old behaviour in the report until it is saved once more; the update does not mark it as edited, and its report stays open.

The ELEMENTS FILLED and BLANKS counters are buttons. Pressing either lights every blank cell and scrolls to the first of them, and pressing again clears the lighting. MANUAL ENTRIES NEEDED does the same for the cells still waiting on a person.

The revenue element

Element 15 carries one figure: total revenue for the most recent financial year the provider has actually published, labelled with that year. Earlier years belong to the data portal database rather than to the research, so the research asks for one year and one year only. A figure typed by hand has to be an amount and a financial year, for example A$1,669,170,000 · FY2025, and the box says so when what was typed cannot be read as one.

What the export contains

• The snapshot table, one row per value of each element and one column per provider.
• 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. Exporting does not send the run anywhere; sending a run to the data portal is a separate and deliberate action, described in the next section. Once the run is saved there, a copy of the exported workbook is kept on the portal with the run's other deliverables, and History lists it.

The data portal at thesector.lunalab.studio/portal is the other half of the system. It holds the monthly ACECQA register snapshots and the comparison tables built from them, it takes a finished run from the application and keeps the files made from it, and it is reached both in a browser and from inside the application itself. It runs on Cloudflare and needs no computer to be switched on.

Signing in

Accounts are made in the portal by an administrator, and the same account signs the application in: Settings, then DATA PORTAL, then the email and password. The password that works is kept on that computer, encrypted the same way the OpenAI key is, so the application signs itself in when it opens and again whenever the portal's twelve-hour session runs out. SIGN OUT forgets it. The password is kept exactly as you typed it, spaces included. If this computer cannot keep it, Settings says so (Signed in, but the password could not be remembered on this computer) and the application asks for it again the next time it opens.

A new account starts on a temporary password, and until it is changed the portal will do nothing else for it. Since 0.2.8 that is enforced for the application as well: signing in works, but Settings and the Ready to run card say that the portal is asking for a new password before it will do anything else, and the website's portal opens on Your account and loads its data once the password has been changed there. Change it on the Your account tab, in the application's DATA PORTAL page or in a browser.

Changing a password signs the account out on every other computer and browser, which have to sign in again with the new one (in the application, in Settings). Signing out ends that one session on the portal as well as on the computer, and removing an account ends all of its sessions at once.

If the portal refuses the password a computer has kept (it was changed elsewhere, or the account was removed and added again), the application tries it once, not on every call, and then stops using it: the portal's pages in the application read as not signed in until someone signs in again in Settings with the current password. Before 0.2.8 each page kept trying it, and enough refusals in fifteen minutes locked the account for everyone who uses it; a computer with a stale password now makes one failed attempt. If the portal asks for a wait after too many attempts, the application pauses its automatic sign-ins for fifteen minutes.

The monthly registers

On a set day each month the portal opens the ACECQA registers page in a browser it runs itself, brings back the approved providers and approved services files, archives both byte for byte, loads every centre and every provider, and compares the month with the one before it. What the comparison finds is three tables: centres that closed, either permanently or with their temporary-closure flag on; centres that appeared; and centres whose provider changed.

The two files ACECQA sent are kept for the newest three months: once a fourth month is collected, the oldest month's files are let go of, and its download says so. Everything loaded from them stays — every month's centres and providers, its three tables and any comparison between two months. If a scheduled collection fails, Luna Labs is emailed with the reason and what the run had and had not written when it stopped, and the collection can be run again from the portal. Since 0.2.8 that includes the quarterly collections (ACECQA and the Department of Education), which send one email for a failed or held run. A month whose two files turn out to be byte for byte the same as the month before is flagged in the monthly view, so an unchanged file cannot pass for a quiet month.

The DATA PORTAL page inside the application, reached from the home screen and from the pipeline rail, reads all of that back under the website portal's own seven tabs: Monthly changes, Register (both registers in full, with a search box, state filters and a CSV export), ACECQA, Department of Education, Accounts (admins only), Logs and Your account. An admin can also run the three collections from there (the monthly registers, the ACECQA quarter and the Department of Education quarter) with the same confirmations as the website, and a strip on the other tabs shows a collection that is still running. It replaces the REGISTERS page of earlier releases. The September 2026 snapshot holds 18,164 centres and 10,205 providers.

Comparing any two months

Monthly changes opens on the comparison the collection stored: the month chosen and the one before it in the archive. Above the tables, Compare … with … is a pair of month selectors, the later month first, and any two collected months can be compared on request, in the browser and on the application's DATA PORTAL page alike. The portal works that comparison out there and then from the two months' archived registers, by the same rules the monthly collection uses, and writes nothing. The three tables follow the pair chosen, and Reset to the stored comparison goes back.

Saving a run

Save new snapshot version on the snapshot screen asks once (Save a new version of this Snapshot? Earlier saves and the research are kept.) and then sends the finished run to the portal: every element for every provider, one row per value, Table 1 and Table 2 for the run year, the revenue figure, and the run itself as one document. The line under the button then names the version that landed, as in Snapshot v3 saved with the time and who saved it, and Saved versions lists every version of the run.

A save never overwrites anything. Each press of the button is kept as a new version of the run (version 1, 2, 3 and so on), with its own rows. Nothing already in the database is changed: not an earlier version of the same run, not another run, not the history loaded from the client's workbooks. The year's record shows the newest save of each value, and every earlier version can still be read back. A save that is sent twice (a retry after a dropped connection) is recognised and kept once.

Answers given in the report step are kept the same way, as versions of the edition's inputs. They never change the run: the report lays the latest answer over the researched value when it is built, and the researched value stays in the database beside it. Going back to fix the snapshot and saving again keeps every answer.

A run's deliverables

Every file made for a saved run is kept on the portal against it: the omnibus PowerPoint and PDF and its gaps PDF after each build, each edited omnibus the split accepted, each report split from it, and the exported Snapshot workbook. They go up in the background while you carry on, and the report screen's line reads Keeping the files on the portal · 2 of 5, then Kept on the portal · 5 files. A file that could not be sent never fails the build: the line says how many were not kept and why, with TRY AGAIN. Like a save, this only ever adds: a file is never replaced or removed on the portal, and the same file sent twice for the same build is kept once. History lists them beside the copies on this computer.

What a report reads and writes

A report is built from a saved run. Before a build the application checks what the run is missing (a provider's logo, the edition's signature and photograph, the letter, a blank cell) and asks for it. Each save of the answers is kept in the portal as a new version, so the next build on any computer finds the latest, and nothing earlier is lost. These addresses carry it, each for a signed-in account only:

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; phase 07 spends about US$1 a report build the same way (measured 26 September 2026, 49 boxes). 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.

An installed copy checks for a newer release when it starts, downloads it in the background while you keep working, with its progress in a strip across the top of the window. When it is ready, that strip becomes a gold bar reading Update ready · Apograph and the new version, with a Restart and update button. If the snapshot or the report inputs have unsaved changes, the restart first asks Save changes before updating? and can save them as a new version before it restarts; while the research, a collection or another long task is running, the restart is held until it finishes and the bar says why. With no newer version there is no bar: Settings says in words where the copy stands, and the left rail's version line reads Version 0.2.8 · up to date, or update ready with a restart offer beside it. There is nothing to configure and nothing to press if you would rather not — an update that has been downloaded and ignored is applied the next time the application starts anyway.

Where updates come from

The same place the download does: updates.thesector.lunalab.studio. The application reads a small release list from that store over plain HTTPS with no account and no token, picks up the Windows packages by name, and takes stable releases only. After the first update it downloads only what changed rather than the whole application again. Since 0.2.7 LibreOffice is part of the application, so the update to 0.2.7 carries it once; later updates carry it again only when its own version changes.

If updates are not arriving

A feed it cannot reach is not treated as an error. The version line says, quietly, could not check for updates, the reason goes into %LOCALAPPDATA%\TheSector\logs\app.log under [update], and the application carries on as the version it already is. To see the whole check written out, run "%LOCALAPPDATA%\Apograph\current\TheSector.App.exe" --update-test: it prints the version running, the feed it resolved, where that address came from, and exactly which step failed.

To ask which version is installed without opening the application, run it with --version ("%LOCALAPPDATA%\Apograph\current\TheSector.App.exe" --version on Windows, /Applications/Apograph.app/Contents/MacOS/TheSector.App --version on a Mac). It prints one line, Apograph and the version, and leaves: it opens no window, touches no data and applies no waiting update. Releases before 0.2.8 do not know the flag and open the application instead.

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: under %LOCALAPPDATA%\TheSector on Windows, and under ~/Library/Application Support/TheSector on a Mac. A report's files (the omnibus, its gaps PDF, each edit you upload and the reports split from it) are kept in the app's report folder, and exports are written wherever you save them. That local database is the working store, and a run is complete in it whether or not it is ever sent anywhere.

A run reaches a server only when it is saved: Save new snapshot version on the snapshot screen, or the same save when the application offers it before the report or before an update. It then goes to the data portal, which Luna Labs operates for The Sector on Cloudflare, and anyone holding a portal account can read what has been saved. From then on the files made from it are kept there too, as the data portal describes. Until it is saved, no run has left the machine and there is no copy of it to read. Earlier releases of this application had no such button and no portal, and this page said so.

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.
• A portal email and password when the application is signed in to the data portal under Settings, and the session that sign-in returns. The password is kept encrypted on the computer so the sign-in can be repeated without anybody typing it.
• On a Mac, or on a Windows machine without the WebView2 runtime, a request to the data portal for the two register files, and for an admin account a request that the portal collect them afresh. These carry no run data.
• When the snapshot is built, a request to the data portal for every provider's earlier years: centres, quality ratings and revenue by year, and the cells past runs saved. The app composes no earlier year itself; what the database holds is what the snapshot shows. The request carries no run data.
• Requests to the data portal from the DATA PORTAL page: reading what its tabs show, and the changes made there (a new password on Your account; for an admin, an account added or removed, one of the three collections run, or ACECQA's source changed: a new link to its workbook, which of the link and an uploaded copy is read, or the workbook uploaded from the computer, the fallback when the link cannot be read). These carry no run data.
• A finished run, and only when it is saved (Save new snapshot version, or the same save offered before the report or an update): every element for every provider, one row per value, Table 1 and Table 2 for the run year, the revenue figure, and the run as one document.
• The report inputs, and only when Save new version is pressed in the report step (or the same save is chosen before an update): the answers for each provider, the edition's letter, signatory, contact and as-at date, and any logo, signature or photograph added. An image is uploaded first. The answers and inputs then follow as one new version, and the image is used only once that version is saved. The edition's theme colour is one of those inputs.
• The deliverables of a saved run, the files themselves, each uploaded to the portal's private storage and kept against the run: the omnibus PowerPoint and PDF and its gaps PDF after each build, each edited omnibus the split accepted, each report split from it, and the Snapshot workbook once it has been exported. None is replaced or removed there.
• Nothing from the split itself. The edited omnibus is taken apart, renumbered and turned into PDFs on this computer, by the app and LibreOffice; what leaves is the files it made, as above.
• Nothing else. Leaving the snapshot for the report with a run that is not saved as it stands asks first, with Save new version and continue, Leave without saving (which starts a new run and sends nothing) and Stay here, because the report is made from the latest saved version in the database.

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, encrypted, and is excluded from source control and from the application log. It is sent only to the OpenAI API. On a Mac the application asks Time Machine to leave out the file that holds the encryption key, so a backup does not copy it beside the data it protects; if that file is ever damaged, the application sets it aside, makes a new one, and asks for the key and the portal password again.

Nothing fails silently. When a step fails, its panel shows the sentence that was recorded, the time, TRY AGAIN and SHOW THE LOG; the same sentence, with the step, the run, the version and the computer, is sent to the data portal's Logs tab, where any signed-in person can read it or download it as a spreadsheet. A failure on a computer that is offline is queued and sent at the next launch or sign-in; Settings shows how many are waiting.

Apograph 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