DRAFT — INTERNAL. Chưa duyệt; không phân phối. Decision-forward plan for

review-hub Idea 02 (Hai pháp nhân song song) and Idea 03 (Trang Pháp lý

& Quản trị). Source: hmt-media-review-3dv.pages.dev/ideas-roadmap/

(#idea-02, #idea-03). Both ideas stem from one fact — the workspace runs

two separately registered foundations — so they are planned together and

cross-referenced; they can still ship independently.

This plan does not lock a calendar. It locks the shape, grounds it in the

live schema/tools/hub, and surfaces the decisions that gate the build. No code

is written until §A9 / §B7 are answered. Companion to

donor-and-finance-subplan.md (Areas 3 & 4),

beneficiary-care-subplan.md (Area 1), and the

hub-access pattern in hub-access-accounts-subplan.md.

Last updated: 2026-06-13. Owner (drafting): Editor + Finance trustee. To be reviewed by: the Foundation's legal adviser / Account Custodian (entity boundaries), Coordinator, Safeguarding lead (eligibility data posture).

0. The two entities — grounded in the charters (no longer an assumption)

The legal-boundary confirmation the earlier note flagged as a planning gate (memory project_two-foundations-hmt-thanhnhan: "confirm legal boundaries from charters before planning") is now done, read from the registration papers the administrator provided (Dropbox/Document Sharing - Hieu/HMT/, read into the workspace only — not copied into the repo by this plan). The facts below come straight off the BNV-stamped charters and tax certificates.

The routing rule, restated from the charters (not invented):

• A charity fund (HMT) exists to help **disadvantaged individuals and

households. Its charter names people in hardship as the beneficiaries; it does not** name schools, programmes, or projects as recipients.

• A social fund (Thanh Nhân) exists to promote education broadly and

explicitly funds programmes and projects — the legal mechanism for school-direct disbursement and for supporting students not formally recognised as poor.

So the operator's framing — school-direct → Thanh Nhân; non-poor → Thanh Nhân; recognised-poor individual/household → HMT — is a faithful operating interpretation of the two charter purposes. ⚠️ One nuance to confirm with the legal adviser (carried as D0): the HMT charter does not contain an explicit "may not grant to schools" prohibition; it simply doesn't list institutions as beneficiaries. The routing rule is therefore a scope-fit interpretation, not a quoted prohibition. The plan treats it as the working rule and flags any benefit that contradicts it, rather than hard-blocking on a clause that isn't literally in the text.

What is unchanged. Shared ops team, one management hub, Phase A, and the data firewall all stay exactly as they are. Only the money + legal layer splits into two books.

PART A — Idea 02 · Dual legal entities in parallel

"Hai pháp nhân song song — tách dòng tài trợ theo đúng tổ chức."

Status: Ý TƯỞNG → this plan moves it to designed, decisions pending.

### ⛔ SCOPE DECISION (2026-06-13, administrator): money-in side only — **do

not touch the student/care side yet.**

The entity split, for now, applies **only to governance (Part B) + donors +

finance** (the so-tai-chinh.sqlite registry: donor, contribution,

inkind_contribution, operating_cost + receipts/QR/reports/hub-finance UI).

The student/care side is deferred to a later phase and is **out of current

scope**: no entity on benefit / register_entry, no child.poverty_status

eligibility field, no write-time routing guard on benefits, no school-funding

(BB-tài-trợ) entity tagging, no care-bucket backfill, no /care UI change. The

142+ live student records and the sensitive poverty-recognition data are **not

touched. The care-side design below is kept but parked** (marked

DEFERRED) so it's ready when the student side is in scope.

Consequence to keep in mind: with the outflow (care) side parked, the books

track money IN per entity (and per-entity receipts/reports) but **not yet

money OUT per entity**. Full per-entity reconciliation (matching disbursements

to contributions) and the compliance routing guard arrive in the deferred

care-side phase. The school-funding bridge stays attributed to "Quỹ Thành Nhân"

in prose as it is today, just not yet modelled with an entity column.

A0. What's there today — the honest baseline

The codebase treats the operation as one implicit fund (HMT). Concretely (from the live tools/schema):

• Finance registry (tools/finance_registry_migrate.py,

07_Quan-tri/Tai-chinh/so-tai-chinh.sqlite): tables donor, contribution, inkind_contribution, inkind_disposal, operating_cost, update_recipient, sponsorship_match. None carries an entity field.

• Care registry (tools/beneficiary_registry_migrate.py,

…/so-dang-ky.sqlite): benefit has funding_source (→ nguon-tai-tro.yaml) and register_entry kind='funding' for school-level totals. No entity field; no beneficiary-eligibility (poverty-recognition) field.

• The only existing trace of the second entity: tools/care_benefit_extract.py

defaults a funding agreement's funder to the literal "Quỹ Thành Nhân" when the BB-tài-trợ doc leaves it blank (the school-funding bridge is, in practice, already a Thanh Nhân flow — it just isn't modelled as one).

• Donor code / transfer rail is single: HMT-D<NNNN> donor codes, one NCB

account (QUY HOA MAT TROI · [NCB account]), one VietQR via qr_donor.

• Receipts / reports / letterhead are all single-entity

(contribution_receipt.py, finance_report_*, the document-chrome letterhead asset is HMT-only).

So the substrate is clean and consistent — it just has no concept of which fund. Adding that concept is an additive migration, not a rebuild.

A1. The core design decision — where entity lives

A contribution arrives before it is allocated to any beneficiary, and a disbursement leaves after. Money must not cross between the two books. So entity is a first-class field on both the inflow and the outflow, and the two are reconciled per entity (not joined by FK):

   INFLOW (entity set at receipt)                OUTFLOW (entity set at disbursement)
   ──────────────────────────────               ─────────────────────────────────────
   contribution.entity        ─┐                 benefit.entity              ─┐
   inkind_contribution.entity  ├─ per-entity ───  register_entry(funding).entity├─ per-entity
   operating_cost.entity      ─┘   books          (no benefit crosses entities)─┘   books

• entity is on each money-flow row, not (only) on the donor. A single

person can give to both funds, so the canonical entity lives on the contribution / inkind / operating_cost / benefit row. donor.entity exists only as a default hint (primary_entity, like the existing primary_intent), never as a silent router.

• Cash entity is inferred from the bank account, automatically. Each fund has

its own NCB account (charter Điều 3: separate tài khoản riêng). The bank-statement import already runs per-account CSV — so the entity of a cash contribution = the entity of the account whose statement it came from. No human tagging on the common path.

• Disbursement entity must match the eligibility + recipient. The routing

rule (§A3) is enforced at benefit_record / care_benefit_extract write time.

• Per-entity reconciliation, no cross-entity transfer. "Opening + in − out =

closing" runs once per entity. A benefit funded by entity X must trace to a contribution in entity X's book (funding_source already carries the donor/ source ref; entity is added alongside).

This is the "separate books per entity, shared ops" model the charters require (each fund files its own annual BNV/BTC report — HMT charter Điều 6.9 and Thanh Nhân charter Điều 6.9 both: report before 31/12, publish contributions before 31/3).

Scope now: only the inflow half (contribution / inkind_contribution

/ operating_cost + the donor hint) is built in this phase. The outflow

half (benefit / register_entry on the care side) and the cross-entity

reconciliation are DEFERRED with the student side (scope banner above).

A2. Data-model changes (additive, idempotent migrations)

Two enum values, fixed: hoa-mat-troi and thanh-nhan (ASCII kebab, per naming-convention.md). A shared loader/validator in tools/_finance_common.py (finance side; the care-side validator is part of the deferred phase); the canonical entity registry is a new small file _system/config/entities.yaml (display name, legal type, MST, bank account label, letterhead asset, QR prefix, receipt-number prefix — one block per fund).

Finance registry (finance_registry_migrate.py)

Migration is the existing idempotent ALTER TABLE … ADD COLUMN pattern (ensure_* style); add indexes idx_contribution_entity, idx_inkind_entity, idx_operating_cost_entity. receipt-number becomes a per-entity sequence (today it's implicit/global) — a small receipt_seq table or a per-entity counter in entities.yaml-driven state.

Care registry (beneficiary_registry_migrate.py) — ⏸ DEFERRED (student side)

Out of current scope (scope banner). The rows below are the parked target

for the later care-side phase; not built now. No change to

so-dang-ky.sqlite, benefit_record.py, care_benefit_extract.py, or the

child schema in this phase.

Why the care-side default would be thanh-nhan, not hoa-mat-troi (for

when this is built): today's only populated outflow at scale is the **BB-tài-trợ

school-funding bridge**, which care_benefit_extract already attributes to "Quỹ

Thành Nhân". A blanket default of hoa-mat-troi would mis-tag the live

school-funding benefits. Confirm in D2 when the care phase opens.

Funding-source file (cloud/care/seed/nguon-tai-tro.yaml) — ⏸ DEFERRED

Care-side. Adding entity: to each funding-source ref and the

benefit.entity == funding_source.entity cross-check belong to the deferred

care phase (D3). Not touched now.

A3. The routing rule + mismatch guard — ⏸ DEFERRED (the compliance crux)

Out of current scope. The routing guard is enforced where outflows are

written (benefit_record.py / care_benefit_extract.py), which is the parked

student side. The rule is documented here so it's ready, and remains a faithful

reading of the charters (pending D0); it is not enforced in this phase.

Until the care side is built, entity attribution stops at the inflow books.

RULE (working interpretation of the charter purposes, pending D0):
  recipient is a school / programme / project       → MUST be  thanh-nhan
  beneficiary is a recognised-poor individual/hhld   → MAY be   hoa-mat-troi
  beneficiary is NOT recognised-poor (individual)    → MUST be  thanh-nhan
GUARD (write-time):
  benefit.entity == 'hoa-mat-troi' AND child.poverty_status NOT IN
        (recognised-poor set)                        → BLOCK + finding
  register_entry(funding, school-direct).entity == 'hoa-mat-troi'
                                                      → BLOCK + finding
  contribution disbursed from entity X funds a benefit in entity Y
                                                      → reconciliation finding (§A8)

• Block vs warn: a clear scope violation (HMT funding a non-poor child or a

school) is a block with a finding the Coordinator must resolve (re-tag the entity or correct the eligibility), mirroring the QC blocking-finding pattern. An unknown eligibility (poverty_status null) is a warning, routed to triage — never a silent pass (matches care-data's "no fact without a source" posture).

• The guard is light, like claim-checker: it only fires on an outflow that

asserts an entity + recipient; a benefit with entity=thanh-nhan (the broad fund) is always in scope and needs no eligibility check.

A4. Beneficiary eligibility data (sensitive — care-data §3) — ⏸ DEFERRED

Out of current scope. This adds a sensitive field to the live student

records and is explicitly parked by the scope decision. The design below is the

target for the care phase; **nothing about poverty-recognition is collected,

stored, or surfaced in this phase.**

The routing input is the child's poverty-recognition status (hộ nghèo / cận nghèo / hộ có hoàn cảnh khó khăn có xác nhận, etc.). This is sensitive (beneficiary-care-subplan §3, care-data.md Hard prohibitions):

• Store the source, scope the fact. The poverty-certificate document (giấy

xác nhận hộ nghèo / sổ hộ nghèo) is filed as a source_doc (doc_type candidate: giay-to/hoan-canh), but the precise circumstance detail is not copied into the profile body — only the scoped fact poverty_status + poverty_cert_source_ref (pointer to the doc + issuing authority + valid-until).

• Gated audience. poverty_status surfaces only in the gated §7 "Theo dõi an

toàn"-class audience of the handbook and in the entity-routing guard — not in any published report, not in donor-facing output.

• No egress, no new gate on consent — eligibility is care data inside the

firewall; consent/legal stays external (workspace-ethics §3).

• A new intake field on the candidate survey / admission flow captures

poverty_status at case-selection; a backfill pass (§A7) sets it for the current cohort from existing hardship docs where present, else leaves null (→ warning, not block).

A5. Per-entity artefacts (receipts, letterhead, bank, QR, reports)

Each fund is a distinct legal person, so its outward artefacts must be its own. Driven by _system/config/entities.yaml:

A6. Hub UI changes — finance only (app/finance_dashboard.py)

In current scope, finance pages only — /care is untouched.

• Entity badge (hoa-mat-troi / thanh-nhan chip) on every contribution,

in-kind, and operating-cost row in the finance pages.

• Entity filter on /finance/contributions, /finance/donors,

/finance/inkind.

• Segregated reporting. /finance/monthly/{month} gains an entity selector;

the home tile shows two cash totals, one per fund, never summed into a single headline (the same discipline as cash-vs-in-kind never summing).

• No new module gate needed — entity lives inside the existing finance

module.

• ⏸ Deferred (care side): entity badges on the child benefit list, the

/care/analytics funding split, and inline routing-guard findings.

A7. Historical re-tagging — finance only (one-time backfill)

The idea page's open question "historical re-tagging if currently commingled." The books are not commingled in practice (different accounts) — so the backfill is a tagging pass, not an untangling. In scope now (finance only):

• Cash contributions → entity from the account each statement came from

(if only the HMT account has history, all existing cash = hoa-mat-troi).

• In-kind + operating costs → entity from the same evidence; default

hoa-mat-troi where unambiguous.

• --dry-run first, idempotent, backed up before any finance-DB write. The

finance registry (so-tai-chinh.sqlite) is small; no gcsfuse care-bucket write here.

⏸ DEFERRED (care side): benefit / register_entry entity tagging and poverty_status backfill — these touch the live care bucket (gcsfuse quiesce + backup discipline, care-data.md rule 5) and are parked with the student phase.

A8. Build phases (Idea 02) — current scope = finance + donors

In scope now:

• A-P0 · Decisions. Resolve D0, D1, D4, D5 (§A9). D0 (legal-adviser

confirmation) gates the routing rule, which is itself deferred — so D0 does not block the finance-side build; D1/D4/D5 do.

• A-P1 · Schema + config. entities.yaml; additive migrations on the

finance registry only; enum loader/validator in _finance_common. Tests + selftest.

• A-P2 · Write-path (inflow). entity set/inferred in

contribution_import_statement, donor_register, inkind_record, operating_cost_record. No care write-path, no guard.

• A-P3 · Backfill (finance only). §A7 steps 1–3, dry-run → apply.
• A-P4 · Artefacts. Per-entity receipts + numbering + bank/QR

(entities.yaml-driven); Thanh Nhân letterhead (D4).

• A-P5 · Hub UI (finance). Badges, filters, segregated totals (§A6).
• A-P6 · Reports. --entity on monthly + published; one transparency report

per fund. (Per-entity reconciliation across in/out waits on the care phase.)

⏸ DEFERRED — care/student phase (separate go-ahead): care-registry migration (benefit/register_entry/poverty_status), the write-time routing guard (§A3), care-bucket backfill, BB-tài-trợ entity tagging, and /care UI. Re-opens D2/D3 and the full §A3/§A4 design.

A9. Decisions for the administrator (Idea 02)

In scope now (finance + donors):

• D1. Does the donor choose the entity at gift time, or does the

Foundation allocate (default: inferred from which account the money lands in)?

• D4. Thanh Nhân brand assets (logo, letterhead, seal image, bank/QR) —

where do they come from? (HMT brand-identity zip exists; Thanh Nhân's does not in-workspace yet. Charter Điều 1: Thanh Nhân has a registered logo.)

• D5. Two separate NCB accounts confirmed live, and the transfer-note

prefix scheme (HMT- / TN-)?

⏸ Deferred to the care/student phase (do not need answering now):

• D0. Legal-adviser confirmation of the §A3 routing interpretation (the

"HMT not to schools" scope-fit reading + edge cases). Gates the routing guard, which is itself deferred.

• D2. Care-side benefit.entity default — thanh-nhan vs hoa-mat-troi.
• D3. nguon-tai-tro.yaml general — split per entity, or entity on the row.

PART B — Idea 03 · Legal & Governance surface

"Trang Pháp lý & Quản trị — hồ sơ nền tảng, đăng ký, hội đồng & thành viên."

Status: Ý TƯỞNG → this plan moves it to designed, decisions pending.

B0. Baseline + what we already hold

There is no governance surface in the hub today. But the source documents are now filed on the Shared Drive — ✅ done 2026-06-13 (B-P1 file step): all 11 registration documents are in 5_Quan-tri-thuong-hieu/Quan-tri/Dang-ky-va-giay-phep/<entity>/, renamed to convention (the two brand-asset zips were excluded by request — they feed Idea 04 / D4). The HMT subset was already on the Drive under its original field names; this pass renamed + moved it into hoa-mat-troi/ and added the four Thanh Nhân docs into thanh-nhan/. As filed:

…/Dang-ky-va-giay-phep/hoa-mat-troi/ (HMT — quỹ từ thiện)

…/Dang-ky-va-giay-phep/thanh-nhan/ (Thanh Nhân — quỹ xã hội)

Excluded by request (brand assets, → Idea 04 / D4):

Bộ nhận diện thương hiệu Quỹ HMT-…zip and Mô hình 8 cánh -…zip remain in

the administrator's Dropbox; the Drive already has a Tai-san/ brand band

(Logo, Mau-sac-va-kieu-chu, Mau-thiet-ke, Phong-chu) if/when they land.

This is exactly the content Idea 03 displays. With the docs filed, the remaining build is plumbing + a viewer + the catalog/governance.yaml, not new doctrine.

B1. Storage — the governance Drive band + a light catalog

• Human-readable store (✅ live): the existing governance band

5_Quan-tri-thuong-hieu/Quan-tri/Dang-ky-va-giay-phep/<entity>/ (the lean-bands successor to legacy 07_Quan-tri/Dang-ky-va-giay-phep/; memory project_drive-reorg-lean-bands). The plan's earlier proposed Phap-ly-quan-tri/ band was dropped in favour of the existing Quan-tri/Dang-ky-va-giay-phep/ ("registration & licences") folder, which is the correct semantic home and already held the HMT docs. One subfolder per entity: hoa-mat-troi/, thanh-nhan/ (created 2026-06-13). Docs renamed per naming-convention.md (ASCII kebab, diacritics dropped). A sibling Bao-cao-thuong-nien/ (annual reports) already exists under Quan-tri/.

• Catalog: a small YAML — _system/config/governance/chi-muc.yaml (repo

config the hub reads, like entities.yaml; not on Drive) — one row per doc: entity, kind (charter | establishment-decision | board-resolution | tax-cert | director-decision | seal | other), title, doc_no, issued_on, valid_until (nullable), drive_path / drive_file_id, notes. This is not beneficiary data — no two-space machine-extraction discipline required; it's a reference library, so a flat catalog + the Drive files is enough. Remaining B-P1 step (the files are filed; the catalog is not yet authored).

• Governance facts (the structured "who/what" the page shows) live in a

second small file governance.yaml per entity: legal name, English name, legal type, MST, establishment decision, charter version, registered office, legal representative, board members (name, role, term, appointment_doc_ref), Ban Kiểm soát members, Giám đốc. Seeded from the charters + board resolutions already read (see §0 + the board lists: Thanh Nhân HĐQL 2023–2028 = Nguyễn Thị Hương Lan (CT), Nguyễn Việt Sơn (PCT), Bùi Thị Bảo Anh, Nguyễn Thị An, Nguyễn Thị Cao Liên; HMT board from the NQ HDQL resolution, to be read in B-P1).

B2. The hub surface

A new hub section /phap-ly ("Pháp lý & Quản trị"), or nested under the existing admin area as /quan-tri/phap-ly (the /quan-tri/* paths are already hub-own + admin-gated — the natural home; D6). Pattern follows the existing care school-doc viewer exactly:

• Page: a tab per entity. Each tab renders the governance.yaml facts

(identity card: legal name, type, MST, establishment, office, legal rep) + the board/members table + a document list from _chi-muc.yaml.

• Side-panel viewer (reuse, don't reinvent): the care module already serves

path-guarded PDFs and renders a side-by-side viewer (/care/children/{id}/school-doc/pdf + school_doc_review.html). Lift that pattern: a GET /phap-ly/doc?path=… path-guarded server (restricted to the governance band) + a side panel, so a board member or auditor opens the charter inline without leaving the page — exactly the "documents display in a side panel similar to student file viewing" the idea asks for.

• Templates: app/templates/hub/phap_ly.html (+ a small viewer partial),

inheriting hub/base.html.

B3. Access control

• Default: admin-only, mirroring /quan-tri/nguoi-dung. Governance/legal

records are institutional, not per-area operational data.

• If broader read is wanted (board members, an auditor), introduce a **new module

governance in care_auth.VALID_MODULES + the user-permission UI, gated read-only — same fail-closed pattern as the care/content/finance modules. D7** decides admin-only vs role-based.

• Consistent with the hub-access subplan's **Option B (hub-mediated)

recommendation**: documents are surfaced through the hub (path-guarded server), not by granting Drive ACLs — tightest firewall, nothing to revoke in Drive when a person leaves.

B4. Spin-off domains — designed-for, deferred

The idea names HR and NGO-partnerships as adjacent. Defer both; design the catalog generic enough that they slot in without rework:

• HR / staff — staff & coordinator profiles, roles, stipend/volunteer

agreements. A future /quan-tri/nhan-su section reusing the same catalog+viewer; would intersect the hub-access account lifecycle (hub-access-accounts-subplan). Deferred.

• NGO partnerships — partner directory, MOUs, collaboration history (e.g.

Hope School Đà Nẵng). A future /quan-tri/doi-tac. Deferred.

Phased scope (idea's own steer): start with registration + governance; defer HR and partnerships. This plan honours that.

B5. Build phases (Idea 03)

• B-P0 · Decisions. D6 (URL/nesting), D7 (access scope).
• B-P1 · Seed the store.
• ✅ Done 2026-06-13 — all 11 registration PDFs filed + renamed into

…/Quan-tri/Dang-ky-va-giay-phep/<entity>/ (§B0). Firewall note honoured: Foundation-owned docs copied into the Foundation Drive, no egress; brand zips excluded.

• Remaining — read the NQ HDQL board/director resolutions to complete

the board/director facts; author _system/config/entities.yaml + _system/config/governance/{governance.yaml, chi-muc.yaml} per entity.

• B-P2 · Page + viewer. /phap-ly (or /quan-tri/phap-ly), identity card +

board table + doc list, path-guarded PDF side-panel (lift the school-doc viewer).

• B-P3 · Access. Admin-only or new governance module per D7.
• B-P4 (deferred). HR + partnerships scaffolds.

B6. Decisions for the administrator (Idea 03)

• D6. Section URL — standalone /phap-ly or nested /quan-tri/phap-ly

(recommended: nested under the existing admin area)?

• D7. Access — admin-only (recommended for v1) or a new read-only

governance module for board/auditor accounts?

• D8. ✅ Resolved 2026-06-13 — the registration PDFs were copied into the

Foundation Drive governance band (…/Quan-tri/Dang-ky-va-giay-phep/<entity>/) on the administrator's instruction. (Brand-asset zips deliberately excluded.)

Cross-idea sequencing & shared dependencies

• Idea 03 is the lighter, lower-risk build and a natural first step — it

touches no live financial/care data, just adds a reference surface, and it publishes the entity identities (legal names, MSTs, seals, letterheads) that Idea 02's per-entity artefacts (§A5) then consume. Recommended order: Idea 03 B-P1/B-P2 first, then Idea 02.

• _system/config/entities.yaml is the shared seam — authored once (from

§0 + B-P1), read by both Idea 02 (receipts/QR/reports) and Idea 03 (identity card). Build it in B-P1.

• Current scope = governance (Part B) + donors + finance only. The

student/care side of Idea 02 is parked (scope decision, top of Part A). So D0 does not block this phase — the routing guard it gates is deferred. Idea 03 proceeds immediately (descriptive); the finance-side of Idea 02 needs only D1/D4/D5.

• Idea 04 (branded templates) supplies the Thanh Nhân letterhead/brand

assets that A-P4 needs (D4); track the dependency, don't block — a plain-rule masthead degrades gracefully (document-chrome.md).

• Phase A, the firewall, dignity, and consent-is-external are untouched by

either idea. Neither publishes outward; both stay behind the hub login.

Next steps for the coordinator / Editor

Scope is now governance + donors + finance; the student/care side of Idea 02 is parked (scope decision, top of Part A).

• Answer the in-scope decisions: D1/D4/D5 (Idea 02 finance side); D6/D7

(Idea 03). D8 resolved. D0/D2/D3 are deferred with the care phase — no need to answer now.

• B-P1 file step done (registration docs filed + renamed on the Drive,

§B0). To finish B-P1: author _system/config/entities.yaml + governance/{governance.yaml, chi-muc.yaml} — low-risk, unblocks both ideas and gives an immediate visible result (the Legal & Governance page).

• ✅ Plan published to the review hub (Plans section); consider updating

the plans doc-map (_system/plans/README.md).

• Idea 02 (finance only) starts at A-P1 (finance-registry schema); Idea 03

starts at B-P2 (page) now that B-P1's store is seeded. The care/student phase is a separate, later go-ahead.