The Foundry — change management software by The TJ Method

Last updated: 22 August 2026 · Contact: thomas@thetjmethod.com.au

This page is written for the person in your organisation who has to sign off on a new supplier. It says where your data is, who else touches it, what the product actually enforces, and what we do not have. Every control described here is implemented in the database and the migration that implements it is named beside it, so your engineer can check rather than take our word for it.

---

Read this first — what we do not have

We would rather you learned this from us than found it yourself in week three of an assessment.

• No SOC 2 report. No ISO 27001 certificate. No IRAP assessment. None started.
• No independent penetration test. On 22 August 2026 we completed an internal, AI-assisted source and configuration assessment, following the earlier structured adversarial review. It found no confirmed critical source-code vulnerability, fixed four repository gaps, and recorded the unresolved risks openly below. It did not test the production service. On 25 August 2026 a further internal assessment exercised the running hosted service itself — live multi-tenant isolation (two accounts, confirming no cross-tenant read, write, delete or privilege escalation), Edge-Function authentication, HTTP security headers and transport security — with no high or critical findings; the one gap it found, a missing Content-Security-Policy, was added the same day. Both are internal evidence and not an independent attestation.
• No independent privacy assessment. On the same date we completed an internal, AI-assisted privacy impact assessment across the whole product. It is not legal advice, not a certification, not independent assurance, and no customer, employee representative or outside assessor took part. It produced a register of privacy risks and a dated action register, and none of those actions is closed yet. Completing an assessment is not the same as fixing what it found. Several corrections on this page came straight out of it and are marked where they appear. See §Privacy assessment below.
• No SSO, no SAML and no SCIM. Multi-factor authentication — a 6-digit code from an authenticator app (Microsoft Authenticator, Google Authenticator, 1Password, Authy, Bitwarden — TOTP, RFC 6238) — is live. Migration 0066_mfa.sql is applied to the hosted service: any account can enrol, anyone who administers an organisation must hold a factor, and anyone who holds one must present it to open a confidential change. It is still not an org-wide policy an owner can force on every member, and there are still no printed recovery codes. See §MFA below for exactly what the control does and does not reach. Signing in with a Microsoft work account (Entra ID) is a different question and the answer to that one is still no.
• No continuous integration and no staging environment. Version control was established on 20 August 2026.
• AI drafting runs outside Australia. The local-model option that avoids this is available in a self-hosted build, not on the hosted service. See §2.
• The Foundry is supported by a three-person business team: David leads sales, Shirley leads business relationships, and Thomas leads development and support. It remains a small operation: there is no dedicated security team or 24/7 staffed on-call, and technical delivery and production responsibility are concentrated with Thomas.

What we do have is a set of controls enforced inside PostgreSQL rather than in application code, and a willingness to describe them precisely. If you find a claim on this page you cannot verify, tell us and we will correct the page.

---

1. Where your data lives

Data at rest

All customer data is stored in Australia, in a single Supabase project in the AWS Sydney region (ap-southeast-2). That covers:

• the PostgreSQL database — every change record, stakeholder cohort, survey response, account record and audit entry;
• Supabase Storage — one private bucket (support-evidence) holding files you attach to a support ticket;
• database backups belonging to that project.

There is one region. There is no second project, no read replica, and no backup or replica that we operate outside Australia. The region was fixed when the project was created and cannot be changed for an existing project.

There is also no region-routing logic in the product. The application is a single client talking to a single database URL. Every tenant's data is in Sydney because there is nowhere else for it to go — not because a flag was set correctly.

Evidence: SETUP.md §2 (project region, ap-southeast-2); supabase/migrations/0063_support_desk.sql (private evidence bucket, public = false, re-asserted on every replay); supabase/migrations/0064_data_residency_truth.sql.

Processing — a different question, with a different answer

Storage is not the whole answer, and vendors who stop at "our data is in Sydney" are usually hiding this part.

Privacy assessment — scope, date and limitations

Completed 22 August 2026. Internal. AI-assisted. Not independent.

Source is not production. A control being correct in the code we deploy from is not the same as that control being verified in the service you use. We separate the two everywhere on this page, and where we have not verified something we say so rather than rounding up.

Completing an assessment is not closing its findings. It produced a risk register and a dated action register. Nothing in the action register is closed. The highest-priority items are: getting a written data-processing agreement with our AI provider before more free text leaves Australia; narrowing what survives an erasure in the people register; correcting how survey respondent codes are generated; and putting the retention scheduler somewhere that alerts when it stops.

What we corrected on our public pages because of it. The survey-anonymity wording in the privacy policy (it overstated the protection); the description of what an erasure leaves behind; the scope of trash-and-purge; the fact that we record your browser's user-agent; and the limits of the respondent-code protection described above. We have left the superseded wording described rather than quietly deleted, so you can see what changed.

Availability. The assessment itself is internal, because it is a candid list of problems we have not fixed yet and publishing it in full would be a map for someone acting in bad faith. A scoped extract with current status, dated, is available under NDA.

Other regions

Hosting in another region is available by written agreement only. It is not a self-service setting, and it would require infrastructure we do not operate today. If you need EU or UK residency, ask before you buy rather than after.

The product stores a data_residency value against each organisation. It is a record of the region we have promised you, not a mechanism that puts you there — nothing in the database or the application routes by it. That column has defaulted to 'EU' for every organisation while every organisation's data sat in Sydney. Migration 0064_data_residency_truth.sql was applied on 19 August 2026; it corrected the default to 'AU', corrected every existing row, and recorded in the schema comment that the column is a declaration rather than a placement. The column now reads 'AU', which is where the data has been throughout. We are still telling you about the old default rather than quietly deleting this paragraph, because the wrong value sat in the database for months and may appear in any export you took before that date — and because a trust page that only ever describes its current state is not evidence of anything.

Who can reach it

Thomas Joffe, in Australia, holds the production credentials and leads development and support. David's sales role and Shirley's business-relationship role do not carry standing production access. That is deliberate least privilege, but it also means there is no technical segregation of production duties today: production responsibility is concentrated with Thomas. Supabase is a US-incorporated company operating the Sydney infrastructure; its personnel access is governed by Supabase's own terms, not ours.

---

2. Sub-processors

If you find a sub-processor we did not list, this whole page is worthless. So this is the complete list.

Change notice. We will give 30 days' notice before adding a sub-processor that will handle customer data, to the billing contact on the account. If you object within that period and we cannot resolve it, you may terminate without penalty for the remainder of the term.

The Anthropic disclosure, in full

This is the most important paragraph on this page for an Australian buyer.

The Foundry calls Anthropic's first-party API, which does not offer Australian data residency. When you use an AI drafting feature, the content of that request leaves Australia. We treat this as a cross-border disclosure under Australian Privacy Principle 8, and under s 16C of the Privacy Act we remain accountable for what happens to it. We do not claim the "use, not disclosure" cloud-storage carve-out for this, because running inference over your content is not a storage-and-access arrangement.

(For completeness, because your analyst will check: Claude is available in an Australian region through AWS Bedrock. Our proxy does not call it. Repointing there is on our roadmap and is not done.)

What we do about it:

• On the hosted service, our API key is never in the browser. Every model call from a signed-in customer passes through a Supabase Edge Function that holds the key as a server-side secret, calls one hardcoded host, and accepts only an allowlist of model identifiers. A client cannot supply a URL or redirect that call. (supabase/functions/anthropic/index.ts — hardcoded endpoint and model allowlist at the top of the file; key read from the function environment.) The scope of that sentence is deliberate, because the shipped bundle also contains a browser-direct path: in the demo and in a self-hosted build, the operator supplies their own Anthropic key in Settings, it is held in that browser's local storage, and the browser calls api.anthropic.com directly (dangerouslyAllowBrowser). No key of ours is ever involved and no hosted customer's data goes that way — but if your reviewer greps our bundle they will find it, so we would rather name it here.
• Authorisation fails closed. If the database check for a blocked account, blocked organisation or expired trial errors, the request returns 503 rather than proceeding. Read-only users are rejected at the API, not merely hidden in the UI. (supabase/functions/anthropic/index.ts, the guard block before the upstream call.)
• Minimisation, enforced by column types. The communication-guidance path sends controlled enum labels and a controlled intent — channel, format, framing, cadence — not free text, not individual records, not sentiment. An individual is not expressible in those fields. (See ENGAGEMENT_PLAYBOOKS_DPIA.md §2 and §5, and ENGAGEMENT_PLAYBOOKS_RoPA.md.) This does not apply to a free-text drafting prompt or an attached document, where what you send is what you send.
• The egress can be switched off — but not on the hosted service, and you need to know which one you are buying. The Foundry supports drafting against a local model on your own machine via Ollama, and in that configuration no content reaches any AI provider. That configuration is available in the demo and in a self-hosted build only. On the hosted service every drafting call routes through our server-side proxy to Anthropic, and any local engine setting is deliberately ignored — the proxy is where the spend cap, the blocked-account check and the read-only refusal are enforced, so we do not let a client setting bypass it. The engine control is hidden entirely for signed-in hosted users. (app/src/ai/client.ts, generateJSONBlocks: if (useProxy()) return claudeJSONViaProxy(...) precedes the provider switch; app/src/pages/Settings.tsx returns the "nothing to set up" card when the mode is live.) Three honest limits, then: the local model is less capable than Claude, it cannot read attached PDFs, and if you are on our hosted plan you cannot turn it on. If you need drafting to stay on infrastructure you control, that means a self-hosted deployment — raise it before you buy, not after.

What we have not done. We have not executed a Data Processing Agreement or a Zero Data Retention arrangement with Anthropic, and our proxy sets no zero-retention header. Anthropic's published commercial terms exclude API inputs from model training by default — that is a statement about their terms, not about a contract we hold. Signing a DPA is an open item in our own threat model. We will say so here when it is signed and not before.

What we do not use

The application ships with no analytics, no telemetry, no tracking pixels, no session recording and no third-party CDN assets or web fonts. There is no Google Analytics, no Sentry, no PostHog, no Intercom. The only outbound connections a browser makes are to Supabase and, if you choose it, your own local model. This is unusual and it is deliberate; it is also easy for you to verify from the network tab.

Supply chain — disclosed because you would find it

Our Edge Functions import the Supabase client library at runtime from the public package CDN esm.sh. No customer data is sent to esm.sh — it is code delivery, not data processing, which is why it is not in the sub-processor table. But it is a third party in the execution path of functions that hold privileged keys, and it is a floating major-version reference rather than a pinned build. We are vendoring that dependency to remove the question. Until we do, you know about it.

---

3. How the product protects people

The Foundry holds the kind of change data that damages people if it leaks early: restructures, redundancy consultation, enterprise agreement negotiation, and what employees said when they were asked how they were coping. The controls below are enforced by PostgreSQL, not by the user interface. That distinction is the whole design: there is no application server in front of the database, so a bypassed client bypasses nothing.

Tenant isolation — row-level security, enabled and forced

Row-level security is enabled on every one of the 102 tables in the schema, and forced on every one of them. Forcing matters: an ordinary RLS policy does not apply to the table's owner, and a table owned by the role your queries run as is a common and quiet gap in Postgres deployments. Forcing closes it.

Policies are default-deny and keyed to the authenticated identity from the JWT. No policy uses USING (true), and no policy accepts a tenant identifier supplied by the client.

Evidence: 0001_init.sql onward — alter table … enable row level security; alter table … force row level security; on each table at the point of creation. Verification scripts in supabase/tests/verify_.sql assert pg_class.relforcerowsecurity and query for cross-tenant rows.*

Privileged functions cannot be hijacked

Roughly 600 SECURITY DEFINER functions carry a pinned schema search path — almost all set search_path = '', requiring fully qualified object names, with four early trigger functions pinning public. A privileged routine therefore cannot be tricked into calling an attacker-planted object of the same name.

The confidentiality wall — a walled change never reaches an uncleared browser

When a change is marked confidential — a restructure before announcement, a redundancy programme — access is decided by a database function, can_see_change, evaluated inside Postgres and referenced across 39 migrations and several hundred call sites.

Why this matters more than it sounds: most products filter restricted records out in the browser or in an API layer, which means the data was sent and then hidden. Here the row is never returned. A colleague who has not been cleared does not receive a filtered view of a restructure; they receive nothing, because nothing left the server. The system-side variant used by background jobs, can_see_change_sys, has EXECUTE revoked from application users entirely.

Evidence: 0024_restricted_changes.sql (definition and grant); redefined for soft-delete in 0038_dr_softdelete.sql; redefined again in 0066_mfa.sql to add the second-factor requirement described under Two-step verification below, with the clearance and tenancy logic carried forward unchanged; can_see_change_sys and its revoke in 0035_audit_actor.sql.

Measurement cannot be worked back to a person

Every published measurement is floored at k ≥ 5. If fewer than five people are behind a figure, the figure is suppressed. Where suppressing one group would let a reader recover it by subtracting the visible groups from the total, a second group is suppressed too — the complementary suppression pass, which exists specifically to defeat the subtraction attack. A per-person series is rejected outright as unreportable.

The floor is a CHECK constraint (min_k >= 5), not a setting. An organisation administrator cannot lower it, including to see their own team. The gate is applied to the weakest reading in a window rather than the sum, specifically so that five monthly readings of one person each cannot be added together to clear it.

What this claim covers, and what it does not. It covers published measurements. It does not cover AI-generated themes over free-text survey answers: that surface counts answers rather than people, so in principle one person answering the same question in five consecutive waves could constitute a themed group. We found this in our own review on 22 August 2026. Nothing is wired to the theming pipeline on the hosted service, so no themed output is published today, and fixing the count before anything is wired to it is a priority action in our register. We are naming it here rather than letting the sentence above be read as covering it.

This is what makes it safe to ask an employee an honest question. If a manager can identify who said what, the answers stop being honest, and the measurement stops being worth anything.

Evidence: 0028_measurements.sql — min_k integer not null default 5 check (min_k >= 5), suppression logic, per-person series rejection; 0042_measured_readiness.sql — k_floor int not null default 5 check (k_floor >= 5) and suppression_reason in ('below_k','complementary'), with the subtraction attack named in the comments.

Respondent identifiers are hashed with a secret that is not in the database

Where a respondent identifies themselves, the identifier is converted to a one-way code using HMAC-SHA256 with a pepper held in the Edge Function environment, with a domain separator, and a minimum key length. The function fails closed if the pepper is missing — no pepper, no write.

The consequence is the point: a complete copy of our database does not allow the hashes to be recomputed. Someone holding a database dump cannot rebuild the mapping from a person to their answers, because the secret needed to do it is not in the dump. The schema comment on the unsalted deduplication hash explicitly forbids using it as a pseudonym, so that the shortcut is closed for the next developer as well.

Two limits we previously left out, added 22 August 2026 after our own review. First, the sentence above used to say "including us", and that was wrong. A database dump is not the only thing in play: we hold the secret as well, because it lives in the function environment we operate, and we hold the staff list the customer uploaded. Nothing in the product does this and we do not do it — but the honest statement is that a database compromise cannot re-identify a respondent, not that nobody can. Second, the secret is one secret for the whole service rather than one per organisation, so the same person produces the same code in every wave and in every tenant, which makes answers groupable over time. Deriving the code per organisation and per wave is a priority action in our register. Neither limit is visible to your administrators or to anyone reading the database.

Evidence: supabase/functions/submit-token/index.ts (HMAC, RESPONDENT_PEPPER, fail-closed); contract documented in 0029_identity.sql; mandatory on survey writes in 0040_instruments.sql and 0041_frontline_reach.sql.

The audit log is append-only, and users cannot write to it

Application users are granted SELECT and a narrow column-scoped INSERT on the audit log. UPDATE and DELETE are never granted to anyone — append-only by omission of the permission, not by a trigger that could be dropped. The writer function write_audit has EXECUTE revoked from anon, public and authenticated, and granted only to the server role, so a user cannot forge an entry either.

After an incident, this is what lets us tell you precisely what was accessed and by whom.

Evidence: 0001_init.sql (revoke-then-grant on audit_log); 0035_audit_actor.sql (actor capture; write_audit revoke and service-role grant).

Privilege escalation is not forbidden — it is not permitted

Column-level privileges are an allowlist, not a denylist. For each table, all privileges are revoked from application users and then UPDATE is granted on a named list of columns. is_admin, trial fields, blocked, daily_cost_limit and model are simply not on any list.

A user cannot make themselves an administrator, extend their own trial, or raise their own spend limit. Not because a rule says no — because the permission to write those columns was never issued.

Evidence: 0001_init.sql ("Column-level GRANTs — defense in depth against privilege escalation"), 0004_organisations.sql, 0014_grants_reconcile.sql, 0015_surveys.sql, 0032_activity_notify.sql.

Deletion has a date on it

Deleting content moves it to a recoverable trash and writes a tombstone carrying a mandatory purge_after date. The default retention is 30 days, configurable between 7 and 365, and the remaining days are shown to the user at the moment they delete. One live tombstone per subject is enforced by a unique index. The tombstone ledger itself has RLS enabled and forced with all client access revoked.

A privacy-law erasure request is honoured out of band and does not wait for the trash window.

Evidence: 0038_dr_softdelete.sql — deleted_objects ledger, purge_after date not null, retention policy bounds, days-remaining surfaced to the user; user-facing description in app/src/pages/DataRights.tsx.

Other controls worth naming

• Cross-tenant admin reads are aggregate-only. The single platform-admin overview function returns counts and status, never the content column. An administrator account takeover cannot exfiltrate change content through the API. (0001_init.sql.)
• AI spend is reserved atomically before the upstream call, so concurrent requests cannot collectively exceed an organisation's cap. (0021_ai_budget_atomic.sql.)
• Support evidence files are never served from a raw storage URL. The signing function refuses a caller-supplied path, scrubs a denylist of request parameters, and never returns the service key. The bucket is private and is re-asserted private on every deployment. (supabase/functions/support-evidence-url/index.ts; 0063_support_desk.sql.)

Encryption

Traffic between your browser and Supabase is encrypted in transit with TLS. Data at rest is encrypted by the underlying platform (AWS/Supabase, AES-256). We do not operate application-layer encryption or customer-managed keys, and column-level encryption of the most sensitive fields is on our hardening list, not in the product.

Two-step verification (MFA)

Available since 22 August 2026. Migration 0066_mfa.sql is applied to the hosted service, so everything in this section describes a control you can use today rather than one we intend to ship. A 6-digit time-based code (TOTP, RFC 6238) from any authenticator app — Microsoft Authenticator, Google Authenticator, 1Password, Authy and Bitwarden all work, because they all implement the same standard. This is not signing in with a Microsoft work account; that is SAML/OIDC SSO and we do not have it.

Enrolment is offered immediately after you set your password and is permanently available from your profile. You are challenged once per sign-in, not per action and not per day.

What is enforced. Two rules, and no more than two:

1. If you hold a verified authenticator, you must present it. This is per-user and opt-in by construction — you cannot be locked out by a control you did not switch on. Blast radius on the day it was applied was nil: nobody held a factor yet, so nothing changed for anybody until they chose to enrol. 2. Anyone who administers an organisation must hold one. Inviting, removing, changing a role, granting Portfolio Manager clearance, revoking an invitation, resetting someone else's factors and break-glass owner reassignment all require it. Ordinary change-management work does not.

An owner cannot yet require MFA of every member. That is designed and is the next step.

Where rule 1 reaches, precisely. Because this is the sort of thing an assessor derives if we do not say it. Rule 1 is enforced by PostgreSQL in six places, and between them they cover the direct table API, the write surface and the read surface:

• RESTRICTIVE row-level-security policies on every table the browser can reach directly — 79 of them, computed from the grant catalogue rather than hand-listed;
• the single predicate every organisation write passes through, so roughly 150 write functions inherit it from one definition;
• the confidentiality wall itself. Opening a change marked confidential requires the code. That predicate is the one thing about 140 of our read functions ask before they answer — the RAID register, the readiness reading, the cutover runbook, the capability heatmap, the trash — so the requirement reaches all of them without any of them being rewritten. The trashed-item view of the same wall carries the identical rule, so deleting a confidential change is not a way to read it;
• the membership and administrator tests, which is what closes the reads that are not about one particular change: the organisation roster and its email addresses, the people register, the notification inbox, the audit log, the pending invitations, the saturation and capacity views, and the vendor's own platform console;
• the Portfolio Manager test. A Portfolio Manager sees every change in the organisation, confidential ones included — the broadest clearance the product has — and that clearance now requires the code as well. This one was added last and it is worth being explicit about why: it appears in our code beside the administrator test, joined by or, and gating only the administrator half would have left the wider half standing;
• five functions gated individually, because they ask a question none of the five predicates above can answer for them: erasing every stakeholder group in an organisation, listing confidential changes that have lost their owner, reading the cleared team of a change, acknowledging a governance event, and purging groups past their retention window.

What that leaves. Two things, and we would rather name them than imply there is nothing.

By design: the anonymous and pre-enrolment surfaces stay reachable at first-factor strength, because they must. A survey respondent and a share-link holder have no account at all. Someone accepting an invitation, or creating their first organisation, has no factor yet by definition — gate those and an invited user could never join. The sign-in screen's own status read stays answerable too, and so does the report of a rejected code: gating the record of a failure would destroy the evidence of the thing that failed. The session-liveness probe the app polls every 60 seconds is exempt for a sharper reason — the app treats no answer as "carry on", so gating it would quietly switch off the blocked-account and removed-from-org enforcement for exactly the sessions we are trying to constrain, rather than denying them anything.

Not by design, and not proven absent: a read function that asks none of those questions is not reached by any of this. We do not have an automated check that proves the remainder is empty, and we are not going to claim completeness we have not tested. We can say how we have looked, because the method is the only honest measure of the claim: we enumerate the function catalogue rather than the calls our own front end makes, and compute which functions reach a gated predicate transitively. That method is what found the Portfolio Manager gap and the five hand-gated functions above, and it also found one function that had no permission check of any kind and is now unreachable from a browser. A check that reads "does this function mention a gated predicate" is not sufficient and we no longer use one — a function can mention the right predicate and still have a second way in beside it.

What we can state and have tested, by calling the functions rather than by inspecting them: for an account that holds a factor, a stolen password at first-factor strength cannot read a table directly, cannot save anything, cannot administer anything, cannot open a confidential change, cannot open a standard change either, cannot read the organisation's roster, audit log or people register, cannot export the people register with its email addresses, and cannot grant anybody clearance into a confidential change. That last one is tested from a Portfolio Manager's account specifically, because it was the account that could still do it.

A note on scope, because it is wider than "confidential". Requiring the code for the membership test means an enrolled user at first-factor strength cannot open an ordinary change either, not only a confidential one. That is broader than this section's heading implies and we have chosen it deliberately rather than arrived at it: the alternative was a wall that a Portfolio Manager could walk around, and half a wall is not one.

Recovery. There are no printed recovery codes; Supabase does not offer them for TOTP and we have not built our own. Three mechanisms instead, in order of how often they should be needed: enrol a second device (we ask for one during setup — a desktop password manager beside the app on a phone); an administrator clears your factors from the Team page, which is audit-logged with actor, subject and a written reason, is never self-service, and refuses to leave an organisation with no MFA-capable administrator; and an operator break-glass for a sole owner with nobody to reset them, which is a documented offline procedure and a support conversation, not a button. The sign-in screen names that route rather than assuming you will find it: if you are the only administrator, it gives you the support address to write from.

Evidence. Enrolment, confirmation, removal, rejected codes, administrator resets and break-glass resets all land in the same organisation audit log as everything else, readable and exportable by an owner from the Assurance page. A rejected code is reported by the sign-in screen rather than observed by the server — GoTrue leaves nothing behind for a failed attempt — and it is labelled as a client report in the log so that a client assertion is never presented as a server observation.

Testing

40 of our 68 migrations ship a hand-run verification script that asserts forced RLS, checks grants, and queries for cross-tenant rows by impersonating real users. These are real and they are evidence, and you may have them under NDA. Two limits, because a count is only useful with its denominator:

• The convention starts at migration 0027. The first 26 migrations — the ones that built the core schema, the audit log and the grant model — predate it and have no script of their own. They are exercised indirectly by later scripts that read the same tables, which is weaker than a script written to test them, and we are not going to describe it as equivalent. Two later files (0027b, 0034a) are also uncovered.
• They are run manually at deploy time. We have no CI, so nothing automatically prevents a future migration from silently weakening the posture described above.

Automating those scripts, and backfilling the missing 28, are the two most valuable engineering items on our list. Neither is done.

Which migrations have actually been applied has, until now, been recorded only in a document and one person's memory. Migration 0065_schema_migrations.sql creates a schema_migrations table so that the database itself holds the record; from 0066 each migration writes its own row in the same transaction as its schema change, so the row cannot exist unless the migration ran. Rows for 0001–0064 are backfilled on the day the table is created and are labelled as such — they are not backdated, because a manufactured date in the one table whose value is that it is not manufactured would be worse than no record. This migration was applied on 19 August 2026, alongside 0064. The table now holds 68 rows spanning 0001 to 0065, every one of them marked BACKFILLED with a null checksum: the record starts honest about being a reconstruction, and only migrations from 0066 onward will carry a row written in the same transaction as their own schema change.

---

4. What we do not have yet

Where this is going — sequence, not dated promises

We publish status, not aspiration, so this is an order of intent rather than a set of dates. In priority: (1) execute the Anthropic DPA and close the AI-egress question; (2) SOC 2 Type I — the attestation most buyers ask for first; (3) ISO 27001, which reuses much of the same control evidence; (4) IRAP / Essential Eight, only where a Commonwealth engagement justifies the cost. We deliberately attach no date to any item here until the engagement is booked and paid — a date we cannot keep is worse than none — and when one is committed it appears in the table above with the auditor named, not as a "ready" badge. If you need a specific standard by a specific quarter, raise it in the sale and we will tell you honestly whether the timeline is real.

We also want to be straight about a document you may be given: THREAT_MODEL.md was written before the current deployment and describes infrastructure (a Cloudflare/Render front end) that is not what we run. We are correcting it. Where it and this page disagree, this page is current.

---

5. Incident and breach

If we become aware of a breach affecting your data, we will tell you without undue delay and in any case within 72 hours. We will tell you what we know, what we do not yet know, and what we are doing. We will not wait for our assessment to finish before telling you it is happening.

Where the incident may be an eligible data breach under the Notifiable Data Breaches scheme (Part IIIC, Privacy Act 1988 (Cth)):

• we will carry out a reasonable and expeditious assessment and complete it within the 30 days required by s 26WH, sooner where we can;
• where there are reasonable grounds to believe an eligible data breach has occurred, we will notify the Commissioner as soon as practicable under s 26WK — there is no 30-day grace period on that step — and notify affected individuals under s 26WL;
• where you are the entity carrying the notification obligation, we will give you what you need to make it, and we will not notify your people without coordinating with you first.

What we can honestly promise about response. The Foundry has a three-person business team, but incident investigation and technical response are led by Thomas and there is no 24/7 staffed incident-response function. We will not claim one. David and Shirley support customer communication and business relationships; they are not represented as substitute production engineers. What we do have is an append-only audit log with the actor recorded on every entry, which means that after an incident we can tell you what was accessed and by whom rather than guessing.

What we do not have yet: a published incident runbook. It is being written, and we would rather tell you that than let you assume one exists.

To report a suspected vulnerability or incident, email thomas@thetjmethod.com.au with "SECURITY" in the subject line. We will acknowledge within one business day.

---

6. Your data rights

We handle personal information in accordance with the Australian Privacy Principles. We do not claim to be "fully compliant with the Privacy Act" — compliance is an ongoing obligation, not a certificate.

One thing worth stating plainly, because customers often assume otherwise: the employee-records exemption does not cover us. That exemption applies to an organisation handling records about its own employees. When your workforce data reaches The Foundry, we are handling information about other people's employees, and the APPs apply to our handling of it in full.

We do not make automated decisions about individuals. The AI features draft communications and plans for a practitioner to review and edit. Nothing in the product scores, ranks, or decides anything about a named person.

• Access and correction — you can ask what we hold and get a copy; you can correct your own profile in the product.
• Export — change content, plans, stakeholder data, survey results and governance packs export to CSV, XLSX, DOCX and PPTX from within the product. Your work leaves with you.
• Deletion — deleting inside the product moves content to trash with a published permanent-deletion date, 30 days by default. A privacy-law erasure request is honoured without waiting for that window and is not recoverable.
• A limit on erasure, stated rather than buried — measurement figures that have already been published at k ≥ 5 are aggregates that cannot be traced to an individual and are not withdrawn when one respondent erases. Respondent hashes are recomputed at the edge from the identifier the person supplies, so we can find and remove their responses without ever holding a reversible identifier.
• Complaints — tell us first. If you are not satisfied, you can complain to the Office of the Australian Information Commissioner at oaic.gov.au.

The in-product pages are the authoritative detail: Data Rights (/#/data-privacy-rights) and Privacy Policy (/#/privacy-policy).

---

7. How to ask

Email: thomas@thetjmethod.com.au — this reaches Thomas directly for development, support, privacy and security handling. Shirley supports the business relationship and David supports the commercial process; neither is presented as a substitute technical or privacy-response channel.

If you are sending a security questionnaire, please send:

1. the questionnaire itself — SIG Lite, CAIQ, VSAQ or your own template all work; 2. the deadline; 3. the deal size or user count, so we can tell you honestly whether the gaps in §4 are likely to block it before either of us spends a week on the paperwork.

We answer questionnaires in the vendor's own format and we answer "no" where the answer is no. Expect a response within five business days for a standard instrument.

Documents available on request under NDA: our threat model and remediation plan (with its stale sections flagged), the DPIA input and Record of Processing Activities for the engagement and measurement features, the migration files implementing any control on this page, and the verification scripts.

If you are assessing us for a Commonwealth or state government engagement, tell us at the start. The Anthropic egress described in §2 is the item that has to be closed for that market, and we would rather scope that conversation honestly on day one than discover it at contract.

---

This page describes The Foundry as at 22 August 2026. If a statement here is wrong, we want to know: thomas@thetjmethod.com.au.