Scola Golden School — deterministic Golden Tenant specification

Status: Proposed QA contract; not yet implemented or runtime-certified. Fixture values below are test inputs, not approved school business rules and not user documentation.

Metadata	Value
Target baseline	Scola V1 Production Baseline
Primary tenant	GT-T1 — Scola Golden School
Isolation tenant	GT-T2 — Scola Isolation School
Last static verification	2026-08-08 UTC
Mode / workspace	Server development / /home/scola/odoo
Frontend evidence	scola-fe-v2 develop @ 68b77d88f78b3d32f0ede3a54b665e067b014062
Backend evidence	custom_addons_scola/gcgscola main @ 2ff6ac7cb41810bbc3b66821cdad004b52d1658a
Runtime result	NOT RUN — no database, installed-module state, served bundle, seed checksum, or role session is certified by this document
Application-code changes	None; this file specifies future seed/reset and evidence requirements only
Related gates	QG-04, QG-06, QG-07, QG-08, QG-09, QG-13, QG-14, and QG-17 in docs/release-readiness/09-release-quality-gate.md:132-149

The backend moved after the prior planning baseline: e749832 relocated several module-owned elevated operations and added ACLs, then 2ff6ac7 synchronized topology tests. Those commits are static hardening evidence, not a passing runtime result. In particular, the import-job poll now checks requester and allowed company in the model (../custom_addons_scola/gcgscola/scola_core/models/student_import_job.py:70-93), while pickup/transport ACL changes are outside the Core fixture unless their product overlay is enabled. This specification therefore uses the current backend SHA and requires fresh-account regression tests; it does not retroactively mark any blocker closed.

1. Contract boundary and fixture rules

1.1 What the Golden Tenant proves

The Golden Tenant is a deterministic, synthetic, resettable runtime on which a release candidate can prove:

1. the approved package and entitlement boundary;
2. fresh role provisioning without inherited technical-admin authority;
3. company, school-unit, class, assignment, self, and parent-child scope;
4. upstream master data consumed by downstream workflows;
5. positive, denial, retry, recovery, and cross-role propagation outcomes; and
6. reproducibility against an immutable FE/BE/database/module/fixture manifest.

It does not decide who may approve, correct, publish, or view sensitive data. Those remain product/security/SME decisions. The proposed product contract explicitly limits Core V1 to SC-CORE and keeps W05 write/complete/correct as a Controlled Pilot (docs/release-readiness/01-product-contract.md:19-35,238-261). Authorization still requires active-role capability, record scope, company/school scope, and domain ownership (docs/release-readiness/04-authorization-readiness.md:20-36).

1.2 Non-negotiable fixture rules

Rule	Required behavior	Evidence / reason
Stable logical identity	Every object has a logical key from the GT-* families below. Tests never depend on auto-increment database IDs, “first row,” newest record, display-order coincidence, or human-created data.	Current restore chooses the latest dump by timestamp, which is not an immutable identity (scripts/qa/db/restore.sh:30-38).
Synthetic data only	Names, emails, phone numbers, NISN/NIK/NPSN-like values, files, and content are reserved test values approved by DPO; no production copy or real person is permitted.	Student, parent, and attendance proof are privacy boundaries; QG-11 requires DPO/security evidence (docs/release-readiness/09-release-quality-gate.md:142).
No normal superadmin	Normal UI/API E2E uses fresh school-role accounts only. The database seed executor is non-interactive and its technical credential is neither cached nor used as a workflow actor.	base.group_system is deliberately separated from scola_core.group_scola_admin (../custom_addons_scola/gcgscola/scola_core/security/scola_security.xml:63-78).
Exact groups	Seed replaces, rather than appends to, each account's intended role/group set. Any unexpected or legacy group fails verification.	Current ensure_user only adds missing internal groups, so reused accounts may retain extra rights (scripts/qa/seed/seed_lms.py:63-92).
Explicit company context	Every company-aware master and transaction is created with its intended company_id; every normal user has an explicit primary and allowed-company set.	Student, faculty, course, subject, batch, classroom, and enrollment are company-aware (../custom_addons_scola/gcgscola/scola_core/models/student.py:29-39; ../custom_addons_scola/gcgscola/scola_core/models/faculty.py:11-30; ../custom_addons_scola/gcgscola/scola_core/models/academic_scope.py:6-64; ../custom_addons_scola/gcgscola/scola_core/models/batch.py:20-79; ../custom_addons_scola/gcgscola/scola_core/models/classroom.py:7-17).
Fixed clock	Fixture dates derive from a declared reference clock, never implicit today, now, random, or newest. The clock value is part of the release manifest.	Current seed uses date.today() and fields.Datetime.now() (scripts/qa/seed/seed_lms.py:203-234,273-278,374-375,417-446).
Strict tests	Release runs set E2E_AUTH_STRICT=true; a required skip, quarantine, missing credential, or fallback session is not PASS.	Current setup may call test.skip() when strict mode is disabled (tests/e2e/setup-auth.spec.ts:10-24,33-64).
One overlay at a time	Every test run starts at Core pristine, then applies exactly one named optional/pilot/fault overlay. Tests cannot inherit data from a previous workflow.	Package availability is install + entitlement + UI access, three separate layers (docs/modular/product-tier-and-feature-flags.md:17-31).
Fixture is not policy	Dates, counts, grade levels, subject names, status examples, and actor assignments exist to exercise scope. They must never be copied into product defaults or documentation as school rules.	Product/state/ownership decisions remain open in docs/documentation-planning/decision-workshop.md:31-127.

1.3 Fixture families shared with the release test matrix

Family	Purpose	Persisted in Core pristine?
GT-T1	Primary tenant/company topology for Scola Golden School	Yes
GT-T2	Separate tenant used only for cross-tenant denial and existence-leak tests	Yes
GT-AUTH	Fresh single-persona, structural multi-role, conflict-role, view-only, and unrelated accounts	Yes, except decision-gated roles
GT-ACA	Fixed academic year, terms, units, courses, batches, classrooms, lesson slots, sessions, and teaching assignments	Yes
GT-STU	Assigned/unassigned students plus linked/unlinked parent-child relationships	Yes
GT-TXN	Pristine state and isolated workflow, fault, retry, and recovery overlays	Core pristine marker only; other packs are applied per run

2. Package, module, and entitlement profile

2.1 Core pristine profile

GT-T1 and GT-T2 start with the same SC-CORE commercial profile. The explicit bundle contract contains scola_core, scola_parent, scola_portal, scola_news, scola_lesson_hours, scola_timetable, and scola_attendance (../custom_addons_scola/gcgscola/scola_bundle_core/__manifest__.py:1-21; docs/modular/plan/package-catalog.yaml:126-143). Static manifest closure also installs scola_hr through scola_attendance, brings the scola_platform_support dependency, and makes scola_identity_admin, scola_observability, scola_leadership_hub, and scola_platform eligible for auto-install once their dependencies are present (../custom_addons_scola/gcgscola/scola_attendance/__manifest__.py:24-36; ../custom_addons_scola/gcgscola/scola_core/__manifest__.py:23-32; ../custom_addons_scola/gcgscola/scola_identity_admin/__manifest__.py:10-17; ../custom_addons_scola/gcgscola/scola_observability/__manifest__.py:10-16; ../custom_addons_scola/gcgscola/scola_leadership_hub/__manifest__.py:10-17; ../custom_addons_scola/gcgscola/scola_platform/__manifest__.py:10-20). Installed technical dependency is not SC-PEOPLE entitlement. Seed verification records the observed full install closure; all People and leadership user surfaces stay disabled/denied unless separately approved and entitled, internal platform/observability addons remain non-user-facing, and every additional Odoo/OpenEduCat transitive is captured from runtime rather than guessed.

Profile ID	Installed/entitled intent	Feature flags / SKU state	Allowed use
GT-PKG-CORE	scola_bundle_core plus its exact transitive dependencies; no optional bundle installed solely to make a Core test pass	scola_enabled_addon_skus=''; trial SKUs empty; every frontend managed add-on flag false; license active for a non-expiring test tenant	W00, W01, W02 manual onboarding, Core portal reads, W16 only after its audience/publish contract is approved; W05 mutation excluded
GT-PKG-W05	Same SC-CORE modules; no RFID, face, geofence, pickup, employee attendance, or analytics addon	No invented W05 feature flag. Apply only named GT-TXN-W05-* data/test overlay after pilot entry gates close	Controlled Pilot only
GT-PKG-OPTIONAL-<SKU>	Target: one approved optional SKU plus its approved dependency closure; currently BLOCKED wherever STAB-024 finds undeclared peer-package coupling	Only that company's SKU entitlement and mapped flags on; technically installed peer addons remain unentitled and their user surfaces denied	Package-specific certification only after fresh-database closure matches the approved topology; never Core evidence
GT-PKG-DECISION-<ID>	Module/role/surface whose contract remains undecided	Disabled by default; no normal menu/account acceptance	Decision workshop or exploratory audit only; never release PASS

The managed frontend add-on vocabulary currently contains 19 flags, from scola_admission through scola_report_card (src/config/entitlements.js:29-49). Core fixture verification must assert all 19 are false in the auth payload, not merely the three currently checked by the helper test. The existing SC-CORE helper does reset managed flags, but its tests explicitly assert only LMS, CBT, and library (tests/helpers/provisionedTenant.js:10-25,27-62; tests/unit/helpers/provisionedTenant.spec.js:8-34).

2.2 Optional and pilot overlays

Optional overlays are created from Core pristine, in separate reset runs:

Overlay	Package boundary	Required extra fixture	Isolation assertion
GT-OVL-SC-ADM	SC-ADM	synthetic applicant/application only after SPMB state/owner decisions	SC-ADM menus/APIs absent for GT-T2 and for unentitled GT-T1 roles
GT-OVL-SC-FEES	SC-FEES	synthetic schedule/enrollment; no real payment instrument	no invoice/payment data crosses GT-T1/GT-T2
GT-OVL-SC-REPORT	SC-REPORT	approved standalone grade/report source with SC-LEARN absent/off	Core does not gain report-card menus merely because addon is DB-installed; standalone W07 must pass without SC-LEARN
GT-OVL-SC-LEARN	SC-LEARN	current LMS dataset may be adapted only here; SC-REPORT SKU entitlement/UI/API surface is off while its currently hard-required module is recorded	Standalone SC-LEARN certification is BLOCKED by STAB-024 until the coupling is removed or approved; seed_lms.py is not allowed in Core because it requires LMS models and publishes LMS content (scripts/qa/seed/seed_lms.py:493-505,601-655)
GT-OVL-SC-ASSESS, GT-OVL-SC-LIB, GT-OVL-SC-FIN, GT-OVL-SC-OPS, GT-OVL-SC-STUDENT, GT-OVL-SC-PEOPLE, GT-OVL-SC-ATTEND+, GT-OVL-SC-FOUND	Corresponding Optional Supported package, only after its product gate	Exact fresh-role accounts from §12 plus package-owned synthetic data, added to a separately versioned overlay manifest	unrelated package flags, menus, routes, API capabilities, accounts, and data remain absent
GT-OVL-SC-DAP, GT-OVL-SC-BOS	Controlled Pilot	approved tenant allowlist, owner, kill switch, recovery snapshot	no pilot visibility/action outside named tenant/accounts

Odoo module installation is database-wide while entitlement is company-specific. An optional-overlay database may therefore have the addon installed globally, but GT-T2 and every non-entitled company must still receive the feature disabled and be denied at menu, route, and API. A Core certification run uses a Core-only database manifest so a hidden installed optional module cannot become an accidental dependency.

2.3 W05 cannot be represented as “module off”

Manual attendance belongs to the Core bundle, while W05 write/complete/correct is a Controlled Pilot. The company model defaults per-lesson attendance to enabled; if all attendance modes are false, the settings payload still falls back to per-lesson enabled (../custom_addons_scola/gcgscola/scola_attendance/models/res_company.py:18-47,317-324). Therefore:

• Core pristine contains attendance prerequisites but no op.attendance.sheet, op.attendance.line, proof, correction, or notification output;
• Core release results must label W05 mutation NOT IN CORE RUN, not “flag off” or PASS;
• GT-TXN-W05-* may run only after BLK-A19–BLK-A23, BLK-B04, BLK-B05, and ATT-D01–ATT-D17 are closed and runtime-reverified; and
• if Product requires pilot pages hidden before entry, a real product kill-switch/navigation decision is needed. The seed must not invent one.

3. Tenant and school-unit topology

All names and identifiers below are proposed synthetic QA values. DPO must approve the reserved identifier range before implementation. The topology exercises same-tenant cross-unit scope and separate-tenant scope; it is not a commercial claim that every school must use multiple companies.

Fixture	Parent / relationship	Name and purpose	School profile	Runtime contract
GT-T1	Independent tenant root and primary active company	Scola Golden School	SMP, synthetic NPSN 99000001, timezone Asia/Jakarta, locale id_ID, currency IDR	Core SKU only; normal users have explicit GT-T1 allowed companies; no GT-T2 company
GT-T1-U2	Child school unit of GT-T1	Scola Golden School — SD Unit	SD, synthetic NPSN 99000002, timezone Asia/Jakarta	same-tenant/other-school-level negative fixture; only explicitly cross-unit account may read it
GT-T2	Separate root, never child/sibling of GT-T1	Scola Isolation School	SMP, synthetic NPSN 99000003, timezone Asia/Jakarta, locale id_ID, currency IDR	Core SKU only; no user shared with GT-T1; same logical academic codes intentionally reused to expose missing company filters

The profile model accepts canonical paud, tk, sd, smp, sma, smk, slb, and pkbm levels and enforces unique eight-digit NPSN (../custom_addons_scola/gcgscola/scola_core/models/school_profile.py:20-39,114-136). The company timezone is an explicit required selection (../custom_addons_scola/gcgscola/scola_core/models/res_company.py:19-79). Batch codes are unique per company, and batch-family checks traverse a root and its children (../custom_addons_scola/gcgscola/scola_core/models/batch.py:20-40,160-200). Reusing codes between GT-T1 and GT-T2 is therefore intentional negative-test pressure, not duplicate master data within a company.

Required topology assertions:

1. GT-T1 accounts cannot list, count, search, browse, export, mutate, or infer GT-T2 records.
2. A GT-T1 primary actor without U2 scope cannot operate on U2 records even though both are in one tenant family.
3. A payload mixing a GT-T1 record with any GT-T2 foreign key is rejected atomically.
4. Switching active company does not expand company_ids; a forged company ID is ignored/denied.
5. Denial response and timing expose neither record existence nor sensitive field/count.

4. Fixed clock and academic topology (GT-ACA)

4.1 Clock contract

Key	Proposed fixed value	Use
GT-CLOCK-TZ	Asia/Jakarta	school-local schedule and W05 date boundary
GT-CLOCK-DATE	2026-08-10 (Monday)	canonical “today” only in a clock-controlled test runtime
GT-CLOCK-INSTANT	2026-08-10T00:00:00Z = 07:00:00+07:00	deterministic start instant
GT-CLOCK-VERSION	v1	included in fixture/release manifests and checksum

Backend attendance resolves today using the school timezone (../custom_addons_scola/gcgscola/scola_core/utils/datetime_utils.py:50-92,178-183), and the faculty W05 endpoint searches sessions in the resulting local-day UTC range (../custom_addons_scola/gcgscola/scola_attendance/controllers/attendance_api_mixin.py:4056-4071). A fixed row dated 2026-08-10 is therefore insufficient unless the runtime clock is also controlled. Until a supported test-clock mechanism exists, W05 “today” cases are Blocked by runtime determinism gap; using the real current date without recording it is prohibited. A temporary run may resolve an explicit anchor date only if it is written into a new release manifest and cannot be called a reproduction of the fixed v1 fixture.

4.2 Academic periods and school levels

Fixture	Company	Proposed record	Fixed values	Why present
GT-ACA-AY1	GT-T1	Academic year 2026/2027	start 2026-07-13, end 2027-06-18, two-term structure	active W01/W02/W05 dependency
GT-ACA-AY1-T1	GT-T1	Term Semester 1	2026-07-13 through 2026-12-18	reference-date term
GT-ACA-AY1-T2	GT-T1	Term Semester 2	2027-01-04 through 2027-06-18	term boundary/future prerequisite
GT-ACA-U2-AY1	GT-T1-U2	same label and dates	separate company-owned record	same-tenant other-level scope
GT-ACA-T2-AY1	GT-T2	same label and dates	separate tenant-owned record	cross-tenant collision test

These dates are QA fixtures, not an Indonesian academic-calendar policy. Product/School SME must separately decide edit/lock ownership and real school calendar rules.

4.3 Courses, subjects, classrooms, batches, and membership

Fixture	Company	Type / fixed key	Relationships
GT-ACA-C-SMP7	GT-T1	course/program GT-SMP-7	owns GT-T1 SMP subjects/batches
GT-ACA-S-MTK	GT-T1	subject code GT-MTK, Mathematics	assigned to Teacher A for 7A
GT-ACA-S-BIN	GT-T1	subject code GT-BIN, Bahasa Indonesia	assigned to Teacher B for 7B
GT-ACA-R-7A, GT-ACA-R-7B	GT-T1	classrooms GT-R7A, GT-R7B	one room per regular batch
GT-ACA-B-7A	GT-T1	regular SMP batch GT-7A	AY1; classroom R-7A; homeroom H; Students S1/S2
GT-ACA-B-7B	GT-T1	regular SMP batch GT-7B	AY1; classroom R-7B; homeroom B; Student S3
GT-ACA-U2-C-SD4, GT-ACA-U2-S-MTK, GT-ACA-U2-B-4A	GT-T1-U2	SD course, same subject code, regular batch GT-4A	tests other-level scope within tenant
GT-ACA-T2-C-SMP7, GT-ACA-T2-S-MTK, GT-ACA-T2-B-7A	GT-T2	same display/code pattern as GT-T1	tests whether code/name lookup leaks across tenant

The fixture always writes company_id; it cannot rely on env.company defaults. Course and subject codes are company-unique (../custom_addons_scola/gcgscola/scola_core/models/academic_scope.py:6-50), batch owns company/academic year/classroom/homeroom/student membership (../custom_addons_scola/gcgscola/scola_core/models/batch.py:20-99), and classroom is company-owned (../custom_addons_scola/gcgscola/scola_core/models/classroom.py:7-17).

4.4 Lesson hours, teaching assignments, and timetable

Fixture	Local time/date	Actor and scope	Expected use
GT-ACA-LH-P1	07:00–07:45	stable lesson-hour slot	timetable input
GT-ACA-LH-P2	07:45–08:30	stable lesson-hour slot	overlap/order test
GT-ACA-TA-7A-MTK	effective in AY1/T1	Teacher A → Batch 7A → GT-MTK	assigned-teacher positive scope
GT-ACA-TA-7B-BIN	effective in AY1/T1	Teacher B → Batch 7B → GT-BIN	other-batch denial and second valid assignment
GT-ACA-SES-7A-MTK-P1	2026-08-10, P1	Teacher A, 7A, R-7A	W01 downstream and W05 pristine entry
GT-ACA-SES-7B-BIN-P1	2026-08-10, P1	Teacher B, 7B, R-7B	peer-session denial
GT-ACA-SES-7A-MTK-P2	2026-08-10, P2	Teacher A, 7A, R-7A	ordered multi-session read
GT-ACA-SES-PAST, GT-ACA-SES-FUTURE	fixed dates on either side of anchor	same declared assignment	date-boundary and “today only” denial
GT-ACA-U2-SES, GT-ACA-T2-SES	same local date/time and display pattern	U2 and GT-T2 actors only	same-tenant and cross-tenant collision tests

Session company_id is stored from its batch, timetable conflict checks compare overlapping batch/faculty/classroom, and local display derives from school timezone (../custom_addons_scola/gcgscola/scola_timetable/models/session.py:15-57,94-164). Seed creation must use the repository timezone conversion helper rather than manually treating local time as UTC.

Combined sessions, substitute sessions, holidays, and schedule overrides are not Core-pristine prerequisites. Add them as versioned workflow overlays only after simple canonical sessions pass.

5. People, role, and identity fixtures

5.1 Faculty and school operators

Fixture	Login (stable, synthetic)	Company/assignment	Role intent	Baseline status
GT-AUTH-SCHOOL-ADMIN	gt.school_admin	GT-T1 primary only	school_admin; school business group only, never base.group_system	Required Core account; exact capability snapshot awaits AUTH-013 closure
GT-AUTH-TEACHER-A	gt.teacher.assigned	faculty in GT-T1; teaching assignment 7A/MTK	teacher	Required Core positive actor
GT-AUTH-TEACHER-B	gt.teacher.other_batch	faculty in GT-T1; teaching assignment 7B/BIN	teacher	Required record-scope negative/positive actor
GT-AUTH-TEACHER-U	gt.teacher.unassigned	faculty in GT-T1; no active teaching or homeroom assignment	teacher	Required denial actor
GT-AUTH-HOMEROOM	gt.homeroom.7a	homeroom member of 7A	assigned roles teacher + homeroom; switch to active homeroom for persona tests	Required Core actor, but not single-role by current model design
GT-AUTH-T2-ADMIN	gt2.school_admin	GT-T2 only	school_admin	Cross-tenant unrelated actor
GT-AUTH-T2-TEACHER	gt2.teacher.assigned	GT-T2 batch/session only	teacher	Cross-tenant assignment actor

Assigning a homeroom faculty currently forces both teacher and homeroom roles and resets the active role to teacher (../custom_addons_scola/gcgscola/scola_core/models/batch.py:380-415). The Golden manifest must expose this honestly: GT-AUTH-HOMEROOM is a structural multi-role fixture, then the role-switch flow activates homeroom. A fictitious homeroom-only account would not represent current provisioning.

The school-admin account uses the business group contract: code comments state group_scola_admin must not imply Odoo Settings/System access, and base.group_system must not imply that business role (../custom_addons_scola/gcgscola/scola_core/security/scola_security.xml:63-78). The current LMS seed instead provisions its admin with base.group_system (scripts/qa/seed/seed_lms.py:508-514), so that account is not acceptable evidence for a normal Scola workflow.

5.2 Students and parents (GT-STU)

Fixture	Company / enrollment	Portal account	Parent relationship	Test purpose
GT-STU-S1	GT-T1, running enrollment in 7A/AY1/T1	gt.student.7a.1	linked to P1	assigned student self and linked-child positive
GT-STU-S2	GT-T1, running enrollment in 7A/AY1/T1	gt.student.7a.2	linked to P1	second child and exact-roster member
GT-STU-S3	GT-T1, running enrollment in 7B/AY1/T1	gt.student.7b.1	linked to P2	other-batch and unrelated-child denial
GT-STU-S4-UNASSIGNED	GT-T1 student identity, no batch/course enrollment	gt.student.unassigned	no parent link	missing-prerequisite and no implicit roster
GT-STU-U2-S1	GT-T1-U2, batch 4A	gt.u2.student.4a.1	linked only to U2 parent	same-tenant other-unit denial
GT-STU-T2-S1	GT-T2, batch 7A	gt2.student.7a.1	linked only to GT-T2 parent	cross-tenant guessed-ID denial
GT-STU-P1	GT-T1	gt.parent.linked	S1 + S2	multi-child positive and S3 denial
GT-STU-P2	GT-T1	gt.parent.other	S3 only	unrelated child denial for S1/S2
GT-STU-P0-UNLINKED	GT-T1	gt.parent.unlinked	no children	fail-closed missing relation
GT-STU-T2-P1	GT-T2	gt2.parent.linked	GT-STU-T2-S1 only	cross-tenant parent denial

Student, faculty, batch, course, subject, classroom, and enrollment records use explicit company ownership. Parent-child checks must resolve relationships server-side; the proposed authorization contract forbids arbitrary peer/child IDs (docs/release-readiness/04-authorization-readiness.md:47-55,109-121). No fixture assumes an “expired relationship” field that the inspected model contract did not prove; unlink/relink recovery is tested by snapshot transitions instead.

5.3 Authorization variants (GT-AUTH)

Fixture	Composition	Use	Gate
GT-AUTH-SINGLE-*	each supported actor above, with exact expected groups and one persona; homeroom exception recorded explicitly	positive and unauthorized-role cases	always required for approved Core roles
GT-AUTH-VIEW	logical alias to an approved existing role that has view but not target mutation for the tested resource; never a new invented role	prove viewer direct-API mutation is denied	binding remains unresolved until RP-02 capability matrix is signed
GT-AUTH-MULTI-NONCONFLICT	structural teacher+homeroom account	active-role switch, menu/persona, assignment continuity	required because provisioning creates this combination
GT-AUTH-MULTI-CONFLICT	dedicated synthetic account assigned two intentionally conflicting approved roles, proposed default school_admin + teacher	prove active role narrows authority, forged role is denied, and audit identifies acting role	decision fixture only until RP-01 is signed; never a normal happy-path actor
GT-AUTH-UNRELATED	matching role from GT-T2, or Teacher B/P2 within GT-T1 depending scope under test	other tenant/company/batch/child negative cases	required
GT-AUTH-LEADERSHIP-DECISION	fresh principal and only the VP roles Product explicitly approves	read/approve/correction checks after package/ownership decision	disabled in Core pristine because current product contract classifies leadership shells Requires Product Decision (docs/release-readiness/01-product-contract.md:114-148)
GT-AUTH-TECHNICAL-EXECUTOR	non-interactive seed/upgrade identity; no FE storage state, no normal API workflow	provisioning only	excluded from every product E2E result

Credentials are secret references, not fixture values. Stable usernames may be committed; passwords/tokens may not. Every required role receives a nonempty secret such as GT_E2E_SCHOOL_ADMIN_PASS, injected at run time, redacted from logs, and rotated independently of the data checksum. Current E2E defaults include admin/admin, teacher1/teacher123, and other committed fallback passwords, while admin-staff/principal/VP credentials default empty (tests/e2e/helpers/auth.ts:66-110). Golden release runs must fail preflight when a required secret is absent; they must not fall back to these values.

6. Representative transaction and scenario packs (GT-TXN)

6.1 Core pristine

GT-TXN-PRISTINE is the reset point for every test selection. It contains the tenant, accounts, masters, assignments, roster, and timetable above, plus only approved read fixtures. It contains:

• zero attendance sheets/lines, proof files, corrections, or attendance notifications;
• zero queued/running import jobs;
• zero optional-package records;
• no browser storage state or server session from a previous run;
• one synthetic canonical-news read fixture and one calendar read fixture only if W16/calendar audience contracts are approved; otherwise neither is seeded; and
• a fixture manifest row proving every expected count/link and proving prohibited counts are zero.

“Pristine” means no output of the workflow currently under test. It does not mean an empty school.

6.2 Core workflow overlays

Pack	Starting state and proposed records	Purpose / expected downstream	Status
GT-TXN-W00-SESSION	fresh, uncached role sessions only	login, session refresh, active company/role, navigation; logout destroys state	Required Core after auth contract closes
GT-TXN-W01-ACADEMIC	clone pristine; one isolated draft candidate master created by test	create/edit validation, timetable consumption, no cross-company FK; cleanup via reset	Required Core; master lock/owner decisions still gate mutations
GT-TXN-W02-MANUAL	clone pristine; one new synthetic student + parent candidate	identity linkage, enrollment, student/parent visibility	Required Core after ownership/collision criteria close
GT-TXN-W02-IMPORT	clone pristine; deterministic two-row synthetic import and fixed idempotency key GT-W02-I1	queued/running/done-or-failed transition, progress, retry, exact company, no duplicate identity	Import subflow remains conditional on BLK-B03/runtime acceptance
GT-TXN-W16-NEWS	clone pristine; one draft and one publish candidate only after canonical audience/approval decision	cross-role visibility and notification behavior asserted, not assumed	Core candidate, decision-gated

The import job stores a company, requester, idempotency key, progress, result, and one of queued, running, done, or failed; its uniqueness is per company (../custom_addons_scola/gcgscola/scola_core/models/student_import_job.py:9-34). Current get_visible_for_user() is static evidence of requester/company filtering, but Golden tests must prove a GT-T1 requester cannot poll a GT-T2 job, a different non-admin cannot poll it, duplicate key has one job, and denied polls reveal no payload (../custom_addons_scola/gcgscola/scola_core/models/student_import_job.py:70-93; ../custom_addons_scola/gcgscola/scola_core/controllers/admin_import_api.py:210-253).

6.3 W05 Controlled Pilot overlays

The following are specified for later test implementation, not enabled now:

Pack	Fixture delta	Required assertion before it may count
GT-TXN-W05-FIRST-SAVE	pristine session/roster, no sheet/register output	fresh assigned teacher can create exactly one complete sheet through supported API without technical-admin or legacy extra group; unassigned actor denied
GT-TXN-W05-READ-DONE	one code-created synthetic completed sheet only after status glossary is approved	authorized operator/student/linked parent projections agree; unrelated child/batch/tenant sees nothing
GT-TXN-W05-CORRECT	clone of approved done state plus fixed prior version	only approved actor/window/state can correct; reason/approver/audit and downstream propagation exact
GT-TXN-W05-ROSTER-FAULT	request payloads, not persisted corrupt rows: missing S2, duplicate S1, S3 from another batch, GT-T2 student, empty list	every invalid request rejected atomically with unchanged sheet/line counts
GT-TXN-W05-RETRY	same valid request and stable key/correlation input delivered twice, plus interrupted-response simulation	one business effect, recoverable response, no duplicate lines or conflicting terminal state
GT-TXN-W05-PROOF	tiny synthetic allowlisted and disallowed file samples	enabled only after DPO/file contract; MIME/size/signature/access/retention/audit tests pass

Current combined-session save checks duplicate, foreign, and incomplete rosters, while the regular save path still iterates supplied rows after creating/finding a sheet; this remains a runtime/code acceptance target, not a fixture behavior to normalize (../custom_addons_scola/gcgscola/scola_attendance/controllers/attendance_api_mixin.py:4218-4252,4276-4334). Current code also writes sheet state directly to done; the seed must not teach or bless this as the approved completion/correction policy (../custom_addons_scola/gcgscola/scola_attendance/controllers/attendance_api_mixin.py:4335-4337).

6.4 Generic fault and retry packs

Pack	Mechanism	Constraint
GT-TXN-FAULT-AUTH	direct API as unrelated/view-only/forged-role account	denial has zero persistent side effect and no existence leak
GT-TXN-FAULT-SCOPE	valid own-tenant record mixed with U2/GT-T2 IDs	invalid data is sent as a request; seed does not persist impossible cross-owner rows
GT-TXN-FAULT-VALIDATION	missing/invalid/boundary fields derived from each route contract	backend rejection authoritative; frontend message checked separately
GT-TXN-FAULT-DEPENDENCY	approved controllable provider/job failure	no uncontrolled external network dependency; recovery outcome explicit
GT-TXN-RETRY-IDEMPOTENT	stable scenario key + repeated/concurrent request	exact one-effect assertion and deterministic response/conflict contract
GT-TXN-RECOVERY	restore pristine, reproduce failure, invoke only approved compensation/retry	never direct database edit as product recovery

7. Privacy and data minimization

1. All identities use synthetic names such as Golden Student 01; emails use a non-deliverable reserved test domain controlled by QA. External mail/SMS/WhatsApp/push providers are disabled or routed to a local sink.
2. NISN, NIK, NPSN, phone, and address-like values use a DPO-approved reserved range. The proposed 99000001–99000003 NPSNs must be changed before implementation if DPO cannot verify that range as safe.
3. No face template, photograph of a real person, GPS trace, RFID credential, health data, counseling case, payroll value, complaint, or production attachment appears in Core pristine.
4. W05 proof fixtures are excluded until MIME/signature/size/scanning/viewer/retention policy is approved. Raw proof bytes must not appear in list/summary snapshots.
5. Test artifacts redact passwords, session cookies, tokens, raw attachments, and sensitive payload. Database evidence contains fingerprints/counts/logical keys, not a distributable PII dump.
6. GT-T2 data is deliberately similar to GT-T1 so tests detect missing company filters, but no identifier is reused where a model enforces global uniqueness.

8. Seed, reset, and verification design

8.1 Target lifecycle

immutable empty/core database input
  -> install/upgrade exact SC-CORE module set
  -> seed GT-T1 + GT-T2 + GT-AUTH + GT-ACA + GT-STU + GT-TXN-PRISTINE
  -> verify logical links, zero-prohibited counts, groups, entitlements, and scope
  -> emit canonical fixture manifest + SHA-256
  -> create immutable Core-pristine dump + SHA-256
  -> restore that exact dump for each test selection
  -> apply exactly one named GT-TXN or package overlay
  -> run strict tests and archive before/after manifest

The current Makefile exposes backup/reset/seed/run targets (Makefile:15-30), and the scripts refuse destructive operations on any database except scola_test (scripts/qa/db/backup.sh:15-23; scripts/qa/db/restore.sh:15-21; scripts/qa/reset_and_run.sh:15-20). Those are useful safeguards to retain. They are not yet the Golden implementation.

8.2 Required reset behavior

Step	Target requirement	Existing gap
Preflight	require exact database scola_test, explicit Golden sentinel, expected server/config, no production host, and explicit destructive-reset acknowledgement	current check verifies DB name only
Input selection	require exact QA_BACKUP_FILE and expected SHA-256; never auto-select newest	restore currently picks latest timestamped dump (scripts/qa/db/restore.sh:30-38)
Database reset	terminate only target DB connections, drop/recreate/restore, then prove DB identity	current mechanism does this safely by fixed name (scripts/qa/db/restore.sh:45-67) but has no Golden sentinel/checksum
Module state	install/upgrade exact module manifest from release candidate; fail on unexpected supported-package module	current seed orchestration defaults to updating only scola_lms (scripts/qa/reset_and_run.sh:50-61)
Seed	apply versioned Core Golden seed, then optional named overlay	current orchestration runs only seed_lms.py (scripts/qa/reset_and_run.sh:22-25,70-83)
Verify	assert every logical key/link, exact role groups, flags, companies, prohibited zero-count, time anchor, and synthetic-data policy	current seed prints IDs/count hints but has no machine-verifiable Golden health result (scripts/qa/seed/seed_lms.py:656-670)
Session hygiene	delete cached .auth states and authenticate every fresh account after reset	current Playwright helper creates reusable storage files (tests/e2e/helpers/auth.ts:54-64,66-110)
Strict execution	fail on missing credentials, setup failure, skip, flaky quarantine, or wrong build	setup can skip roles when E2E_AUTH_STRICT=false (tests/e2e/setup-auth.spec.ts:10-24)

The active seed-contract document says reset initializes Odoo, installs modules, and seeds data, while the implementation's --reset-only branch only restores a dump (docs/qa/seed-contract.md:377-394; scripts/qa/reset_and_run.sh:72-75). Golden implementation must make the actual command and evidence agree; this plan does not treat the prose as runtime proof.

8.3 Idempotency and three-run proof

For one exact release manifest:

1. full reset + seed + verify runs three consecutive times;
2. every run produces the same fixture logical keys, relationship graph, normalized values, row counts, installed-module list, entitlement payload, and capability snapshots;
3. seed is then run a second time without restore and produces no new row, group, relation, or changed normalized checksum;
4. auto-generated database IDs, password hashes, session tokens, audit timestamps, create_date/write_date, and transient job timestamps are excluded from the logical checksum but checked for prohibited duplicates; and
5. the immutable dump checksum, canonical fixture-manifest checksum, and release-manifest checksum are archived for all three runs.

8.4 Canonical manifest

The seed verifier emits ordered JSON (or equivalent machine-readable data) containing at least:

Manifest section	Required fields
Build	FE SHA, BE SHA, clean-tree assertion, served bundle/version hash, Odoo/Python/Node/PostgreSQL versions
Database	DB name, sanitized database fingerprint, dump SHA-256, schema/module-upgrade run ID
Modules	installed module technical name/state/version, bundle/SKU mapping, transitive dependency list, unexpected-module result
Tenants	GT-T1/GT-T1-U2/GT-T2 logical keys, company hierarchy, timezone/locale/currency, license/addon/trial states
Clock	timezone, fixed local date/instant, clock mechanism and version
Accounts	logical key, login, active/assigned roles, exact direct/implied group XML IDs, company IDs, faculty/student/parent link; never password/hash
Masters	every GT-ACA and GT-STU key, normalized values, company and relation keys
Transactions	active overlay ID, initial/final state counts, idempotency/correlation keys with sensitive values redacted
Tests	matrix revision, command, run IDs, pass/fail/skip counts, failure list, artifact hashes

Canonical checksum input sorts objects by logical key, resolves relations to logical keys rather than numeric IDs, normalizes UTC/local datetime representations, and excludes unordered display artifacts. The release gate requires exact reproducibility inputs rather than unresolved environment defaults (docs/release-readiness/09-release-quality-gate.md:216-235).

9. Current tooling assessment and implementation backlog

Gap ID	Confirmed finding	Release consequence	Required implementation/decision
GT-GAP-01	Seed is LMS-specific and requires LMS models; SC-LEARN is optional, not Core (scripts/qa/seed/seed_lms.py:493-505; docs/modular/product-tier-and-feature-flags.md:37-83).	Core test can silently depend on an optional package.	Create a separate Core Golden seed and retain LMS data only as GT-OVL-SC-LEARN.
GT-GAP-02	Academic and LMS dates use today/now (scripts/qa/seed/seed_lms.py:203-234,273-278,374-375,417-446).	Same seed produces different data; W05 today-route cannot be reproduced later.	Approved test-clock mechanism + fixed clock manifest; no implicit runtime date.
GT-GAP-03	Current seed does not create named companies and does not write explicit company ownership for its masters (scripts/qa/seed/seed_lms.py:203-346,508-603).	No same-unit, cross-unit, or cross-tenant proof.	Implement GT-T1/GT-T1-U2/GT-T2 and explicit company on every record.
GT-GAP-04	Current admin is base.group_system; reused internal users only gain groups and never lose extras (scripts/qa/seed/seed_lms.py:63-92,508-514).	Superadmin/legacy rights can produce false-positive E2E.	Exact replacement role/group provisioning; technical executor excluded from workflows.
GT-GAP-05	Current seed covers admin, two teachers, two students, and two parents only; E2E principal/admin-staff/VP credentials default empty (scripts/qa/seed/seed_lms.py:508-568; tests/e2e/helpers/auth.ts:92-110).	Supported-role and negative matrix incomplete.	Fresh accounts for every approved role; decision accounts disabled; strict secret preflight.
GT-GAP-06	Restore may select latest dump automatically (scripts/qa/db/restore.sh:30-38).	Two runs can use different input without visible config change.	Require exact dump path + SHA-256 + Golden sentinel.
GT-GAP-07	Orchestrator updates scola_lms by default, then seeds LMS (scripts/qa/reset_and_run.sh:50-64).	Schema/package state does not represent SC-CORE.	Release-manifest-driven install/upgrade list and per-package overlays.
GT-GAP-08	Auth setup can skip failures when strict mode is false (tests/e2e/setup-auth.spec.ts:10-24).	Missing roles can yield a superficially green subset.	Mandatory E2E_AUTH_STRICT=true; zero required skip; fail missing secret/session.
GT-GAP-09	Active seed contract calls a health endpoint a future enhancement (docs/qa/seed-contract.md:424-440).	Printed seed summary is not machine-verifiable evidence.	Offline verifier/manifest is mandatory; an HTTP health endpoint is optional and must not expose secrets/PII.
GT-GAP-10	W05 Core settings fall back to per-lesson enabled even when modes are false (../custom_addons_scola/gcgscola/scola_attendance/models/res_company.py:317-324).	Pilot cannot honestly be represented by a fabricated off flag.	Keep mutation overlay absent and label out-of-run; Product decides real kill switch/navigation contract if required.
GT-GAP-11	Homeroom assignment forces teacher+homeroom and active teacher (../custom_addons_scola/gcgscola/scola_core/models/batch.py:380-415).	“Single-role homeroom” would be false evidence; active-role union issue remains testable.	Record structural multi-role fixture and close RP-01/AUTH-001 before certification.
GT-GAP-12	Import poll was hardened at current BE HEAD to requester/company filtering, but no Golden runtime proof exists (../custom_addons_scola/gcgscola/scola_core/models/student_import_job.py:70-93).	W02 import can be overclaimed from source review alone.	GT-T1/GT-T2 requester/company/idempotency/poll tests tied to BE 2ff6ac7; keep BLK-B03 until acceptance.
GT-GAP-13	Current fixture uses committed fallback credentials and database-generated IDs in one LMS grade-event key (tests/e2e/helpers/auth.ts:66-110; scripts/qa/seed/seed_lms.py:642-648).	Secret hygiene and logical reproducibility are weak.	Secret-only credentials and stable logical-key-based idempotency/checksum design.
GT-GAP-14	No current three-run manifest/checksum evidence exists; QG dashboard says Golden Tenant NOT RUN (docs/release-readiness/09-release-quality-gate.md:272-281).	QG-04/QG-17 remain RED.	Implement, run, and archive three deterministic resets on exact release candidate.

The e749832 pickup/transport, counseling portal, privacy/visitor, and audit hardening must receive fresh ACL/scope regression fixtures only when their module/role is approved in the product/overlay contract. They are not silently added to Core because code changed. Student-import polling is retained in the W02 conditional overlay because it belongs to the Core onboarding subflow.

10. Golden Tenant acceptance criteria

ID	Acceptance criterion	Required evidence	Gate result until proven
GT-READY-01	Product/Commercial approves Core, optional, pilot, decision, legacy, and internal boundary; every enabled package has owner and prerequisites.	signed 01-product-contract.md + package manifest	RED
GT-READY-02	Exact SC-CORE install/upgrade succeeds from declared input; no unexplained optional application addon or feature flag is active.	module list/version, upgrade log, auth entitlement snapshots	RED
GT-READY-03	Fixed clock, timezone, AY, terms, lesson slots, and sessions reproduce exactly.	clock mechanism/version and three equal logical checksums	RED
GT-READY-04	GT-T1, U2, and GT-T2 relationships and synthetic identifiers reproduce; no production data exists.	tenant/fixture manifest + DPO synthetic-data approval	RED
GT-READY-05	Every approved Core role logs in fresh with exact assigned/active role, groups, company scope, and expected capability snapshot; no normal path uses base.group_system.	auth/capability/group snapshots and no-extra-group verifier	RED
GT-READY-06	Assigned/unassigned teacher, class/batch, student self, linked/unlinked child, same-tenant other-level, and cross-tenant scope tests all pass without data/count/existence leak.	GT-AUTH, GT-ACA, GT-STU positive/negative results with before/after DB assertions	RED
GT-READY-07	Core pristine has exact expected records and prohibited zero-counts; seed-again is idempotent.	canonical manifest before/after second seed	RED
GT-READY-08	Full reset/seed/verify succeeds three consecutive times from exact dump/module inputs with equal logical checksums.	three run IDs/logs, dump and fixture SHA-256	RED
GT-READY-09	Required suites run with strict auth and zero required skips/quarantines/fallback credentials.	machine-readable pass/fail/skip report	RED
GT-READY-10	Each optional/pilot overlay starts from Core pristine, provisions every supported role in §12 with exact group/capability scope, enables only the declared package/company, and cannot leak to GT-T2 or unrelated roles.	per-overlay module/entitlement/account/group/capability/menu/route/API matrix	RED
GT-READY-11	W05 remains excluded until pilot blockers/decisions close; once enabled, first-save, exact roster, state/correction, retry, propagation, and proof privacy packs pass.	blocker/decision closure + GT-TXN-W05-* results	RED / pilot blocked
GT-READY-12	Exact release manifest binds FE/BE/DB/module/seed/test artifacts, and no code/schema/module drift occurred after the run.	signed immutable manifest and artifact hashes	RED

No criterion can be waived as an Accepted Limitation when it concerns superadmin dependency, cross-tenant/record scope, sensitive data, data integrity, required skips, or a false package claim. Completion of this specification means the Golden Tenant is designed; only the evidence above can make it release-ready.

11. Ownership and run handoff

Responsibility	Accountable owner	Required handoff
Product/package boundary	Product Owner + Commercial owner	approved package/role/tenant catalog
Role/group/capability fixtures	Identity/RBAC Owner + Security	exact fresh-role and active-role snapshots
Academic/student fixtures	Core Product Owner + School SME + Data Steward	approved synthetic topology; confirmation that values are QA-only
Privacy/synthetic identifiers	DPO + Security	reserved ranges, field minimization, artifact policy
Seed/reset implementation	QA Automation + Platform Operations	versioned scripts, safeguards, manifest/checksum verifier
Module/schema baseline	Backend/Release Operations	install/upgrade logs and exact module versions
Test evidence	QA Lead	strict result set mapped to GT-* and RT-* IDs
Final release sign-off	Release Owner with Product/Security/Operations	all GT-READY-* and applicable QG gates GREEN on one manifest

The Golden Tenant must be rebuilt—not manually repaired—when fixture logic, product package, role catalog, company scope, schema/module version, or fixed clock changes. Any such change increments the seed/manifest version and invalidates prior certification evidence.

12. Optional and pilot fresh-role account ledger

This ledger closes the wildcard GT-AUTH-SINGLE-* for every currently proposed supported role outside Core. It is a fixture contract, not evidence that the accounts exist or that the roles are approved. Current role vocabulary and app composition come from src/config/roles.js:10-42 and src/config/apps/roleApps.js:105-951; package ownership remains proposed in 01-product-contract.md. A role name absent from those sources is not invented here.

All accounts below are absent or disabled in Core pristine and are materialized only with their named overlay. Login values are stable synthetic identifiers; passwords follow the secret-only rule in §5.3. Each supported operator fixture also has a deterministic negative mirror <fixture>-T2 with login prefix gt2. and company GT-T2; the mirror is unentitled unless that exact package is the isolation profile under test.

Package overlay	Stable fixture and login	Company / record scope	Intended current role binding	Activation and decision gate
GT-PKG-CORE	Existing GT-AUTH-SCHOOL-ADMIN, teacher A/B/U, homeroom, GT-STU-*, and GT-T2 accounts in §5.1–§5.2	Exact GT-T1/GT-T1-U2/GT-T2 academic, assignment, self, and child scopes	school_admin, teacher, homeroom, student, parent	Always required for approved Core; W05 mutation still uses its separate pilot overlay
GT-OVL-SC-ADM	GT-AUTH-ADM-APPLICANT / gt.adm.applicant; operator reuses fresh GT-AUTH-SCHOOL-ADMIN	Applicant self-record; operator GT-T1 admissions scope only	pendaftar; school_admin	Enable only after SC-ADM contract/state/ownership decisions; committee/VP persona remains excluded
GT-OVL-SC-FEES and GT-OVL-SC-FIN	GT-AUTH-FIN-TREASURER / gt.finance.treasurer; existing student/parent self accounts	GT-T1 billing/accounting company; student/selected-child self scope	treasurer; student; parent	Run each package overlay separately; finance-VP and cashier are not silently created
GT-OVL-SC-REPORT, GT-OVL-SC-LEARN, and GT-OVL-SC-ASSESS	Reuse fresh school-admin, teacher A/B/U, homeroom, student, and parent accounts from Core	GT-T1 assignment/class/self/child; optional entitlement differs per overlay	Existing school_admin, teacher, homeroom, student, parent	No separate “proctor”, “question author”, or curriculum-owner role is invented; add one only after Product/Security maps it to an approved role/capability contract
GT-OVL-BRIDGE-LEARN-REPORT	Reuse the exact fresh accounts from the two standalone overlays	GT-T1 only; both package entitlements on and all unrelated optional/pilot entitlements off	Existing approved roles only	Named composite integration overlay, admitted only after standalone SC-REPORT and SC-LEARN package gates; reset before/after and never use it as standalone certificate evidence
GT-OVL-SC-LIB	GT-AUTH-LIB-LIBRARIAN / gt.library.librarian	GT-T1 library collection/circulation; no cross-company inventory	librarian	Enable only for SC-LIB; reader self-scope reuses existing student/parent/teacher accounts
GT-OVL-SC-OPS	GT-AUTH-OPS-INVENTORY / gt.ops.inventory	GT-T1 stock/location/assets assigned to the operator	inventory_officer	Enable only for SC-OPS; VP-infrastructure approval persona remains decision-gated
GT-OVL-SC-STUDENT	GT-AUTH-STUDENT-COUNSELOR / gt.student_services.counselor; GT-AUTH-STUDENT-COACH / gt.student_services.coach	Assigned GT-T1 counseling caseload or extracurricular activity/batch only	counselor; extracurricular_coach	Sensitive projection/DPO and assignment policies must close before positive mutation evidence
GT-OVL-SC-PEOPLE	GT-AUTH-PEOPLE-FOUNDATION-HR / gt.people.foundation_hr plus existing teacher as employee self-service	Approved GT-T1/foundation company and employee scope only	foundation_hr_admin; existing teacher self persona	Enable only for SC-PEOPLE; payroll reviewer/approver separation remains a signed capability decision, not an invented role
GT-OVL-SC-ATTEND+	Reuse fresh school-admin, teacher, and student accounts; device event uses a non-user GT-TXN-DEVICE-* credential fixture	GT-T1 assigned person/device/company only	Existing approved human roles; no new device-operator role	RFID/face/geofence/privacy and manage/retry authority must be approved before overlay execution
GT-OVL-SC-FOUND	GT-AUTH-FOUND-AUDITOR / gt.foundation.auditor; GT-AUTH-FOUND-CHAIR / gt.foundation.chair	Explicit approved foundation-company set; auditor read-only	foundation_auditor; foundation_chairman	Requires a separately certified SC-FIN profile and exact enabled prerequisite; generic foundation role remains excluded until catalog and scope decision closes
GT-OVL-SC-DAP	GT-AUTH-DAP-OPERATOR / gt.dapodik.operator	GT-T1 only, named source/tenant mapping and pilot allowlist	dapodik_operator	Controlled Pilot: owner, kill switch, preview/diff, recovery, and identity decisions required
GT-OVL-SC-BOS	GT-AUTH-BOS-ADMIN / gt.bos.admin; maker/approver capability variants derive from this fixture only after approval	GT-T1 BOS/RKAS company, budget, and procurement scope	bos_admin	Controlled Pilot with SC-FIN + SC-OPS; no self-approval assumption

Each overlay also reserves the following stable data families. A reserved family is BLOCKED and is not seeded until its named state, ownership, amount/value, approval, correction, retention, and recovery decisions are approved. The final values live in the versioned overlay manifest; they are synthetic test inputs, not school policy or defaults.

Package / workflow	Stable master and transaction families	Deterministic starting records	Contract still required before materialization	Required propagation/integration proof
SC-ADM / W03	GT-TXN-W03-APPLICANT, GT-TXN-W03-APPLICATION, GT-TXN-W03-ENROLL	One self applicant, one application candidate, one collision/retry input, and one enrollment handoff candidate keyed to GT-ACA/GT-STU	Applicant/application states, committee/owner, rejection/reopen, identity collision, and rollback	Approved enrollment creates exactly one W02 identity/enrollment; rejected/failed input creates none
SC-FEES / W10	GT-TXN-W10-SCHEDULE, GT-TXN-W10-ENROLLMENT, GT-TXN-W10-INVOICE, GT-TXN-W10-PAYMENT	One synthetic fee schedule/enrollment, unpaid/partial/full candidates, duplicate callback/retry input; no real payment credential	Charge ownership, amount/currency/date, adjustment/refund/reversal, receipt, and provider recovery	Authorized student/selected parent sees only own result; accounting bridge only when separately approved
SC-REPORT / W07	GT-TXN-W07-GRADE, GT-TXN-W07-REPORT, GT-TXN-W07-PUBLISH	One assigned class/subject grade source, one report candidate, one correction/version candidate	Grade source, lock, approval, publish/correction/reversal, and audience	Published/corrected result reaches only authorized student/parent and approved Dapodik bridge
SC-LEARN / W07 dependency	GT-TXN-LEARN-COURSE, GT-TXN-LEARN-ASSIGNMENT, GT-TXN-LEARN-SUBMISSION	One entitled course/class, assigned and unassigned teacher/student, content/assignment/submission candidates	LMS ownership, visibility dates, late/retry, grading source, retention, and W07 bridge ownership	Entitled actors see one assignment/result; Core-only and unassigned actors see none
SC-ASSESS / W04	GT-TXN-W04-EXAM, GT-TXN-W04-QUESTIONSET, GT-TXN-W04-ATTEMPT, GT-TXN-W04-SUBMISSION	One exam/question-set candidate, assigned/unassigned examinees, fresh/interrupted/retried attempt inputs	Author/proctor role mapping, open/close/late/reopen, attempt limit, scoring/result publication, and recovery	One authorized submission/result; optional admissions/report bridges consume only when entitled
SC-LIB / W14	GT-TXN-W14-MEMBER, GT-TXN-W14-TITLE-COPY, GT-TXN-W14-LOAN, GT-TXN-W14-QUEUE	Synthetic members, one title with distinct copies, available/loan/return/queue/concurrent-attempt candidates	Loan/renew/overdue/fine/lost states, queue priority, payment ownership, and recovery	Copy/member state and permitted reader view converge; finance effect exists only by approved bridge
SC-FIN / W11	GT-TXN-W11-ACCOUNT, GT-TXN-W11-JOURNAL, GT-TXN-W11-ENTRY, GT-TXN-W11-REVERSAL	Synthetic chart/journal references, balanced draft/post/reconcile/reversal candidates with manifest-fixed non-production values	Account/journal ownership, posting/reconcile/approve SoD, period lock, correction/reversal, and audit	One balanced company-scoped ledger effect; optional fee/BOS/inventory producer reconciles exactly once
SC-OPS / W13	GT-TXN-W13-PRODUCT, GT-TXN-W13-LOCATION, GT-TXN-W13-COUNT, GT-TXN-W13-ADJUSTMENT	Synthetic product/location/opening quantity, counted/mismatch/concurrent/retry candidates	Freeze/cutoff, lot/location scope, tolerance/approval, posting/reversal, valuation bridge	One approved stock adjustment; finance valuation only when SC-FIN contract is enabled
SC-STUDENT / W15	GT-TXN-W15-CASE, GT-TXN-W15-PERMIT, GT-TXN-W15-ACTIVITY, GT-TXN-W15-RECOVERY	Synthetic assigned/unassigned counseling case plus permit/activity/discipline request candidates with no real sensitive narrative	Case purpose/projection, points/effects, approval/close/reopen, parent/student visibility, retention, and break-glass	Only approved downstream attendance/report effects and authorized self/child projection appear
SC-PEOPLE / W09	GT-TXN-W09-EMPLOYEE, GT-TXN-W09-CONTRACT, GT-TXN-W09-INPUT, GT-TXN-W09-PAYSLIP	Synthetic employee/contract and draft/compute/approve/cancel/retry candidates with manifest-fixed non-production amounts	Salary components, maker-checker, effective dates, confirm/cancel/refund, self projection, retention, and recovery	Employee sees own approved projection only; one company-scoped accounting effect when integrated
SC-ATTEND+ / W06/W20	GT-TXN-W06-EMPLOYEE-ATTENDANCE, GT-TXN-W20-DEVICE, GT-TXN-W20-CARD, GT-TXN-W20-EVENT	Synthetic assigned/unassigned person, device/card, accepted/duplicate/failed/retry event inputs; no face template or real GPS	Mode/package boundary, device authority, school-day/timezone, correction, retry/dead-letter, biometric/GPS basis and retention	One authorized attendance effect and audit; W05, pickup, and employee flows never cross-consume accidentally
SC-FOUND / coverage gap	GT-TXN-FOUND-COMPANYSET, GT-TXN-FOUND-AGGREGATE, GT-TXN-FOUND-AUDIT	Synthetic two-company aggregate/read-only/audit inputs with deliberate unrelated-company records	Supported outcome/workflow ID, company aggregation rule, read/approve split, confidentiality, and export retention	Auditor/chairman see only approved aggregate/detail; no mutation or unrelated company leakage
SC-DAP / W19	GT-TXN-W19-SOURCE, GT-TXN-W19-MAPPING, GT-TXN-W19-DIFF, GT-TXN-W19-CONFLICT	Offline synthetic source snapshot, same-looking T1/T2 identifiers, preview/write/retry/conflict/recovery inputs	Identifier/matching authority, source of truth, destructive conflict policy, rollback, and external-integration contract	Preview equals committed change; one tenant-scoped effect; repeat/recovery does not duplicate identities
SC-BOS / W12	GT-TXN-W12-BUDGET, GT-TXN-W12-REQUEST, GT-TXN-W12-ATTACHMENT, GT-TXN-W12-COMMITMENT	Synthetic budget/plan/purchase request, maker/approver, valid/invalid file, duplicate/concurrent approval candidates	Approval matrix, budget/amount/date, attachment policy, commitment/posting, correction/reversal, and recovery	One approved commitment/procurement/accounting effect; invalid/self/cross-company action changes nothing

The following current roles receive no supported-product account in a release overlay until their contract changes: principal, all vice-principal roles, admin_staff, head_admin, pickup_officer, dpo, security_officer, school_committee, alumni, generic foundation, and lab_technician. platform_operator and technical admin are internal identities and cannot be used as normal workflow proof. If Product approves any excluded role, the change must update 01/02/04/06/07 together and add fresh positive, negative, record-scope, tenant, and active-role cases before the role becomes supported.

12.1 Certified jenjang and timezone profile candidates

The current persistent topology exercises only non-early-years (sd/smp) in Asia/Jakarta; it cannot certify PAUD/TK navigation or WITA/WIT date boundaries. Code defines early-years versus non-early-years branches and offers three school timezones (src/config/schoolJenjang.js:5-13; src/config/apps/appFragments/teacherPortalApp.js:129-177; ../custom_addons_scola/gcgscola/scola_core/models/res_company.py:21-61). Product must close DEC-013 before deciding whether the candidates below are retained, combined as proven equivalence classes, or out of V1.

Profile ID	Candidate deterministic profile	Required proof if retained	Current certification meaning
GT-PROFILE-NON-EARLY-WIB	Existing GT-T1/GT-T1-U2/GT-T2 with smp/sd, Asia/Jakarta	W00 menu/route branch; W01 school-day schedule; W05/W06/W20 boundary parameters; cross-unit/tenant denial	Only this named equivalence class may be claimed after runtime PASS; it is not proof for all six non-early codes without an approved equivalence argument
GT-PROFILE-EARLY-WIB	One Product-selected paud or tk unit, Asia/Jakarta, with the same synthetic identity/academic topology	Early-years teacher menu/routes, arrival/departure flow, optional report leaves, negative access to non-early-only surfaces	Decision fixture; not seeded until Product selects PAUD, TK, or both and defines whether they are equivalent
GT-PROFILE-NON-EARLY-WITA	Product-selected non-early unit, Asia/Makassar, fixed clock straddling local midnight	All date-default, timetable/session, attendance, report, retry, and downstream school-day assertions	Decision fixture; cannot be replaced by a WIB run
GT-PROFILE-NON-EARLY-WIT	Product-selected non-early unit, Asia/Jayapura, fixed clock straddling local midnight	Same boundary set as WITA with independent expected local day	Decision fixture; cannot be replaced by a WIB run
GT-PROFILE-MATRIX-DECISION	Every additional jenjang × timezone combination retained by the signed product matrix	Full cartesian cases unless Product/QA documents and approves a code-backed equivalence partition	BLOCKED by DEC-013; no general “all Indonesian schools” claim is permitted

The release manifest lists the exact retained profile IDs and excluded values. Adding a profile after freeze invalidates W00 navigation plus every date-sensitive workflow certificate until its positive, negative, scope, tenant, UI, and school-day boundary parameters pass on the same build.

13. Install-topology qualification for seed/reset

The overlay IDs in this specification are target certification profiles, not proof that current manifests can install every SKU independently. Before any seed run, tooling resolves and records the full dependency/auto-install closure and compares it with the approved manifest. Current contradictions are BLOCKED by STAB-024 and enumerated in 01 §8.

For Core, technically installed scola_hr never enables SC-PEOPLE entitlement or user surface. SC-ATTEND+ is a target composite of the separately installed student-smart and employee-attendance bundles until DEC-001 approves one package or splits it. For SC-ADM, SC-REPORT, SC-LEARN, SC-ASSESS, SC-DAP, SC-BOS, and SC-FOUND, a peer addon pulled by the current closure remains unentitled and must fail menu, route, capability, direct-API, and data-access tests. That denial evidence is containment only; it does not make an undeclared composition a valid package. The package certificate remains blocked until the coupling is removed, split, or explicitly approved and represented as a named composite profile.

Every reset manifest therefore records: requested SKU, resolved installed addon set and versions, auto-installed bridges, company entitlements/flags, expected visible surface, expected denied peer surface, seed checksum, and exact teardown. A closure diff from the signed topology aborts the run before domain fixtures are materialized.