Atlas Partner Binder — Section 00

Front Matter, Document Control, and Navigation

Status: DRAFT-APPLIED MASTER · STAGING ONLY · NOT PARTNER-CONFIGURED

Executor: Codex

Section ID: SEC-00

Section metadata

Field	Controlled value
Owner	[ATLAS CONFIG: PARTNER ADMINISTRATOR]; Atlas delivery owner until accepted handoff: [ATLAS CONFIG: ATLAS PROJECT OWNER]
Model	Core — Clinic and Platform
Scope state	[ATLAS CONFIG: INCLUDED / CONDITIONAL / EXCLUDED / NOT APPLICABLE]
Version	v0.1
Last review	2026-07-24
Prerequisite	Signed Build Specification, selected model, named administrators, and issued binder edition
Done when	Cover fields resolve; selected model and scope match the signed Build Specification; every included section appears in the contents map; current Vault and escalation routes open; no unresolved secret or personal-contact value appears in print
Escalation route	[ATLAS CONFIG: PARTNER-CONTROLLED ESCALATION ROUTE]; issue procedure: HO-05 support guide
Live-system link	Vault manifest; fallback path: _staging/ATLAS_PARTNER_BINDER/VAULT_MANIFEST.md

Partner-edition cover record

Field	Partner-edition value
Public business brand	[ATLAS CONFIG: PUBLIC BRAND NAME]
Partner legal entity	[ATLAS CONFIG: PARTNER LEGAL ENTITY]
Selected model	[ATLAS CONFIG: CLINIC / PLATFORM]
Build Specification	[ATLAS CONFIG: BUILD SPEC ID / VERSION]
Binder edition	[ATLAS CONFIG: BINDER EDITION / VERSION]
Issue date	[ATLAS CONFIG: ISSUE DATE]
Partner administrator	[ATLAS CONFIG: ROLE / NAME]
Atlas delivery owner	[ATLAS CONFIG: ROLE / NAME]
Current Vault entry	[ATLAS CONFIG: LIVE VAULT URL]
Human-readable fallback	[ATLAS CONFIG: VAULT FALLBACK PATH]

This binder is an operating index for the work selected in the signed Build Specification. It does not add deliverables, change ownership, replace the final agreement, or certify external readiness.

Use this binder

1. Start in Section 01 — Launch Command Center to identify the next action, current blocker, accountable owner, and escalation route.
2. Confirm the selected model in Section 02 — Operating Map before using a mode-specific module.
3. Use the printed pages for stable instructions, decision maps, checklists, and fallback paths.
4. Use the Digital Vault for changing records, current files, evidence, external text, system status, and acceptance evidence.
5. Treat [ATLAS CONFIG] as unresolved. An unresolved value is not permission to infer, publish, activate, purchase, or promise anything.
6. Report a defect or access problem through the configured route. Do not place customer data, payment information, passwords, recovery codes, keys, or tokens in a binder note or issue description.

Print versus Digital Vault

Printed binder contains	Digital Vault contains or links to	Never copied into either binder content or a printed page
Stable operating instructions	Current approved files and configured system locations	Passwords
Section map and model branch	Version and supersession history	MFA or recovery codes
Role-based escalation map	Acceptance and dependency evidence	API keys, tokens, private keys, or session values
Stable checklists and decision rules	Current vendor, account, contact, catalog, price, rights, and source records	Full payment credentials
Human-readable fallback paths	Restricted-record reference and authorized owner, where needed	Unnecessary customer or sensitive information

The controlling rule is maintained in BINDER_CONTROL.md. If print and a current live record disagree, stop at the affected step and use the source hierarchy in that control file.

Status meanings

State	Meaning	Operator action
INCLUDED	Scheduled in the signed Build Specification	Follow the current section and acceptance test
CONDITIONAL	Scheduled, but a named dependency controls completion or activation	Use only the documented safe subset; keep the affected item held
EXCLUDED	Outside signed scope	Do not use; route through written change control
NOT APPLICABLE	Intentionally absent from the selected model	Skip without replacing it with another module
READY FOR REVIEW	Exact version and acceptance evidence are available	Review against the written test
ACCEPTED	The delivered version meets the signed criterion	Use the accepted version until formally superseded
BLOCKED	The required dependency or test is unresolved	Do not label complete or activate
SUPERSEDED	Replaced by a named later version	Follow the supersession link; do not use this version

Final acceptance and dependency status remains in the HO-04 register, not in handwritten binder notes.

Dynamic contents map

Configure one row for every section. A partner edition includes the shared Core, exactly one selected model branch, and only the optional modules scheduled in writing.

Sec.	Section	Edition rule	Scope state	Current location / fallback
00	Front Matter, Document Control, and Navigation	Core	INCLUDED	Current master · _staging/ATLAS_PARTNER_BINDER/SEC_00_FRONT_MATTER.md
01	90-Day Launch Command Center	Core	[ATLAS CONFIG]	Current master · _staging/ATLAS_PARTNER_BINDER/SEC_01_LAUNCH_COMMAND_CENTER.md
02	Business Model and Operating Map	Core with one selected branch	[ATLAS CONFIG]	Current master · _staging/ATLAS_PARTNER_BINDER/SEC_02_OPERATING_MAP.md
03	Brand, Naming, Messaging, and Production Rules	Core	[ATLAS CONFIG]	[ATLAS CONFIG: CURRENT VAULT LOCATION / FALLBACK]
04	Website, Funnel, and Conversion Path	Core with configured route	[ATLAS CONFIG]	[ATLAS CONFIG: CURRENT VAULT LOCATION / FALLBACK]
05	Digital Accounts, Security, and Technology Stack	Core	[ATLAS CONFIG]	[ATLAS CONFIG: CURRENT VAULT LOCATION / FALLBACK]
06	Lead Capture, Phone, Booking, and Follow-Up	Core with configured channels	[ATLAS CONFIG]	[ATLAS CONFIG: CURRENT VAULT LOCATION / FALLBACK]
07	Marketing and Area Demand Generation	Core with eligible local modules	[ATLAS CONFIG]	[ATLAS CONFIG: CURRENT VAULT LOCATION / FALLBACK]
08	Customer Consultation and Written Decision Playbook	Core	[ATLAS CONFIG]	[ATLAS CONFIG: CURRENT VAULT LOCATION / FALLBACK]
09	Operations and Customer Experience	Core with selected-mode workflow	[ATLAS CONFIG]	[ATLAS CONFIG: CURRENT VAULT LOCATION / FALLBACK]
10	Ordering, Payments, Inventory, and Fulfillment	Conditional system module	[ATLAS CONFIG]	[ATLAS CONFIG: CURRENT VAULT LOCATION / FALLBACK]
11	Team, Hiring, Role Training, and Employment Controls	Role-dependent	[ATLAS CONFIG]	[ATLAS CONFIG: CURRENT VAULT LOCATION / FALLBACK]
12	Clinic Configuration Playbook	Clinic only	[ATLAS CONFIG: INCLUDED / NOT APPLICABLE]	[ATLAS CONFIG: CURRENT VAULT LOCATION / FALLBACK]
13	Platform Configuration Playbook	Platform only	[ATLAS CONFIG: INCLUDED / NOT APPLICABLE]	[ATLAS CONFIG: CURRENT VAULT LOCATION / FALLBACK]
14	Claims, Evidence, Supplier, and Customer-Education Control	Core; submodules conditional	[ATLAS CONFIG]	[ATLAS CONFIG: CURRENT VAULT LOCATION / FALLBACK]
15	Activation, Handoff, Stabilization, and Continuity	Core	[ATLAS CONFIG]	[ATLAS CONFIG: CURRENT VAULT LOCATION / FALLBACK]
16	Template Vault, Registers, and Appendices	Core; role-based visibility	[ATLAS CONFIG]	Vault manifest · _staging/ATLAS_PARTNER_BINDER/VAULT_MANIFEST.md

Quick escalation card

This card stores roles and controlled routes, not permanent personal details.

Need	Accountable role	Configured route	Source record
Scope, decision, or change request	Partner decision-maker	[ATLAS CONFIG: PROJECT ROUTE]	Build Specification
Binder access, version, or broken link	Partner administrator	[ATLAS CONFIG: ADMIN ROUTE]	Vault manifest
Included Atlas-controlled defect	Atlas delivery/support owner	[ATLAS CONFIG: SUPPORT ROUTE]	HO-05 support guide
Customer communication or customer issue	Partner customer-support owner	[ATLAS CONFIG: PARTNER SUPPORT ROUTE]	OPS-02 journey map
Account, access, privacy, or security concern	Partner administrator / named incident owner	[ATLAS CONFIG: RESTRICTED INCIDENT ROUTE]	OPS-04 inventory
External vendor, adviser, or professional dependency	Owner named in current dependency record	[ATLAS CONFIG: EXTERNAL ROUTE]	HO-04 dependency register

Atlas does not become the partner's customer-contact route by appearing in this binder.

Assembly and release check

• ☐ Public brand, legal entity, model, Build Specification, edition, issue date, and owners resolve.
• ☐ Core plus exactly one selected model branch is present.
• ☐ Excluded and not-applicable modules are absent without breaking section numbering.
• ☐ Every included section has a current location and human-readable fallback.
• ☐ Every changing record is linked rather than copied into print.
• ☐ Quick escalation routes are configured and tested.
• ☐ No secret, credential value, unnecessary personal detail, or customer data appears.
• ☐ Printed version and Vault manifest identify the same edition.
• ☐ All unresolved fields remain visibly marked [ATLAS CONFIG].

Build Specification relationship

Section 00 navigates to Build Specification lines 01-06, 08-03, and 08-04 but does not become their primary acceptance record. Primary accountability remains in Sections 01, 15, and 16 and in the linked source records.

Atlas Partner Binder — Section 01

90-Day Launch Command Center

Status: DRAFT-APPLIED MASTER · STAGING ONLY · NOT PARTNER-CONFIGURED

Executor: Codex

Section ID: SEC-01

Section metadata

Field	Controlled value
Owner	[ATLAS CONFIG: PARTNER PROJECT OWNER]; Atlas build owner: [ATLAS CONFIG: ATLAS PROJECT OWNER]
Model	Core — Clinic and Platform
Scope state	[ATLAS CONFIG: INCLUDED / CONDITIONAL / EXCLUDED / NOT APPLICABLE]
Version	v0.1
Last review	2026-07-24
Prerequisite	Signed Build Specification; completed readiness inputs; selected model; named decision-maker and administrators
Done when	Every included or conditional Build Specification line has an owner, state, dependency, evidence link, acceptance test, and next action; the next action, current blocker, responsible party, and escalation route can be found in under two minutes; no blocked item is labeled complete
Escalation route	[ATLAS CONFIG: PROJECT ESCALATION ROUTE]; unresolved scope or status routes to the partner decision-maker
Live-system link	HO-04 acceptance/dependency register; fallback path: _staging/PHASE1_HO-01_to_HO-06_2026-07-21/HO-04_Deliverable_Acceptance_Register_v0.1_STAGING.md

Command-center authority

This section is a linked operating view. It does not create a second acceptance register, dependency register, issue queue, or activation decision.

Record	Authority	Current system link / fallback
Signed scope and acceptance tests	Signed Build Specification	D07 Build Specification master · _staging/DIRECTIVE07_BUILD_SPEC_MASTER_2026-07-23.md
Deliverable and dependency state	HO-04	Acceptance/dependency register · _staging/PHASE1_HO-01_to_HO-06_2026-07-21/HO-04_Deliverable_Acceptance_Register_v0.1_STAGING.md
Activation state	HO-01	Activation record · _staging/PHASE1_HO-01_to_HO-06_2026-07-21/HO-01_Activation_Go_NoGo_Master_v0.1_STAGING.md
Stabilization issues	HO-05	Support and issue register · _staging/PHASE1_HO-01_to_HO-06_2026-07-21/HO-05_Thirty_Day_Support_Guide_Issue_Form_v0.1_STAGING.md
Day 7 and Day 30 reviews	HO-06	Review agendas · _staging/PHASE1_HO-01_to_HO-06_2026-07-21/HO-06_Day7_Day30_Review_Agendas_v0.1_STAGING.md
First-30-days marketing actions	Current launch calendar	Launch calendar · _staging/PARTNER_MARKETING_SYSTEM/LAUNCH_CALENDAR_30DAY_v1.md

If a summary below differs from an authority record, correct the authority record first and refresh this view.

Two-minute operator view

Question	Current answer	Authority / evidence
What milestone are we in?	[ATLAS CONFIG: M0 / M1 / M2 / M3 / M4 / M5]	[ATLAS CONFIG: BUILD SPEC MILESTONE RECORD]
What is the next action?	[ATLAS CONFIG: ACTION / OWNER / DUE OR RECHECK DATE]	[ATLAS CONFIG: SOURCE ID / LINK]
What is the current blocker?	[ATLAS CONFIG: NONE / DEPENDENCY ID / CONSEQUENCE]	[ATLAS CONFIG: HO-04 DEPENDENCY LINK]
Who owns the blocker?	[ATLAS CONFIG: ACCOUNTABLE OWNER]	[ATLAS CONFIG: RESPONSIBILITY SOURCE]
What is safe to do now?	[ATLAS CONFIG: ACTIVE OR TESTABLE SUBSET]	[ATLAS CONFIG: EVIDENCE / LIMIT]
What remains held?	[ATLAS CONFIG: HELD OUTPUT / ROUTE / MODULE]	[ATLAS CONFIG: HO-04 OR HO-01 LINK]
Where does an exception go?	[ATLAS CONFIG: ESCALATION ROUTE]	[ATLAS CONFIG: ISSUE OR DEPENDENCY RECORD]
When is the next review?	[ATLAS CONFIG: DATE / EVENT]	[ATLAS CONFIG: REVIEW RECORD]

No target date in this view is a guaranteed launch, completion, response, market, or business-result promise.

Milestone and next-five-actions board

Priority	Action	Related Build Spec ID	State	Accountable owner	Dependency / evidence	Next action	Due or recheck	Escalation
1	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
2	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
3	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
4	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
5	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]

Refresh this view from the source record. Do not use it as a shadow task system.

Partner inputs due

Input ID	Required input or decision	Related line	Accountable partner owner	State	Consequence if missing	Safe fallback	Source record / next action
[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	OPEN / CLEARED / DEFERRED / BLOCKED	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]

Atlas deliverables ready for review

Signed ID	Exact version	Written acceptance test	Evidence link	Review owner	Review state	Consolidated response route
[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	READY FOR REVIEW / ACCEPTED / DEFICIENCY / CHANGE REQUEST	[ATLAS CONFIG]

The final status is entered once in HO-04. A new preference or added quantity routes through written change control rather than being labeled a deficiency.

External dependencies

Dependency ID	External fact, action, account, or approval	Affected output / activation	Owner	State	Consequence	Safe fallback	Next action / recheck	HO-04 link
[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	OPEN / CONDITIONAL / BLOCKED / CLEARED	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]

An external dependency remains external even when Atlas documents it. Documentation does not convert it into an Atlas-controlled result.

P0/P1 daily launch board

Work item	Priority	Model	Scope state	Current state	One owner	Evidence / dependency	Next action	Escalation
[ATLAS CONFIG]	P0 / P1	CORE / CLINIC / PLATFORM	INCLUDED / CONDITIONAL	NOT STARTED / IN PROGRESS / READY FOR REVIEW / ACCEPTED / BLOCKED	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]

Rules:

• P0 work configures, tests, or safely holds activation.
• P1 work supports the first 30 days of operation and demand generation.
• BLOCKED is a controlled state, not a failure to be hidden.
• No row is complete without its written test and evidence.
• Mode-mismatched items are NOT APPLICABLE, not deferred.

Included-line control view

Populate one row for every INCLUDED or CONDITIONAL Build Specification line. The signed Build Specification remains the source.

Signed ID	Section / live asset	Scope state	Accountable owner	Dependency	Acceptance test	Evidence	Current state	Next action
[ATLAS CONFIG]	[ATLAS CONFIG]	INCLUDED / CONDITIONAL	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]

Decision, issue, and change queues

Queue	What belongs here	Canonical source	Current count / oldest open	Owner / next action
Decisions	Missing partner choice or factual confirmation	[ATLAS CONFIG: DECISION REGISTER]	[ATLAS CONFIG]	[ATLAS CONFIG]
Dependencies	External input or condition controlling work or activation	HO-04	[ATLAS CONFIG]	[ATLAS CONFIG]
Included defects	Reproducible failure against an included signed criterion	HO-04 / HO-05 during stabilization	[ATLAS CONFIG]	[ATLAS CONFIG]
Stabilization issues	Access, how-to, defect, routed external issue, or incident reference during configured support	HO-05	[ATLAS CONFIG]	[ATLAS CONFIG]
Change requests	New preference, changed fact, feature, quantity, architecture, or output	[ATLAS CONFIG: CHANGE REGISTER]	[ATLAS CONFIG]	[ATLAS CONFIG]

Sensitive incident facts remain in the configured restricted route; this view contains only the safe case reference, owner, state, and next action.

Day 7 and Day 30 controls

Review	Trigger / configured date	Required input	Output	Canonical link
Day 7	[ATLAS CONFIG]	Current access, defects, workflows, training, dependencies, and issue IDs	One review record with owners and next actions	HO-06 review agendas
Day 30	[ATLAS CONFIG]	Current issue closure, access, continuity, open changes, and remaining dependencies	Closeout or documented continuation under written terms	HO-06 review agendas

Reviews do not create scope or convert an external condition into an Atlas obligation.

Primary Build Specification coverage

Build Spec ID	Deliverable	Section 01 operating record	Done-when control
01-01	Partner intake and readiness profile	Partner inputs due + source-linked readiness record	Required fields complete; missing items have owner and state
01-02	Operator Requirements Brief	Current milestone / decision source	Brief acknowledged; unresolved facts labeled
01-05	Responsibility matrix	Owner fields link to OPS-01	Every critical responsibility has one accountable owner
01-06	Dependency, decision, and milestone register	Two-minute view + boards linked to canonical records	Every open item has state, owner, consequence, and next action

Operational references used here without changing their primary binder home: 05-07, 07-05, 08-01, 08-04, and 08-06.

Acceptance test

• ☐ Every included or conditional Build Specification line appears once in the linked control view.
• ☐ Every displayed row has one accountable owner, state, dependency, evidence link, test, and next action.
• ☐ Final acceptance and dependency states agree with HO-04.
• ☐ Activation state agrees with HO-01.
• ☐ Day 7/30 actions link to HO-06 and issues link to HO-05.
• ☐ The next action, blocker, owner, and escalation route are identifiable in under two minutes.
• ☐ No blocked item is labeled complete.
• ☐ No static vendor, price, catalog, personal-contact, account, or external-text value is duplicated here.
• ☐ Every live link has a readable fallback path.
• ☐ Omitting a not-applicable or optional module does not break this operating view.

Atlas Partner Binder — Section 02

Business Model and Operating Map: Clinic vs Platform

Status: DRAFT-APPLIED MASTER · STAGING ONLY · NOT PARTNER-CONFIGURED

Executor: Codex

Section ID: SEC-02

Section metadata

Field	Controlled value
Owner	[ATLAS CONFIG: PARTNER DECISION-MAKER]; configuration owner: [ATLAS CONFIG: ATLAS PROJECT OWNER]
Model	Core with exactly one selected branch — Clinic or Platform
Scope state	[ATLAS CONFIG: INCLUDED / CONDITIONAL / EXCLUDED / NOT APPLICABLE]
Version	v0.1
Last review	2026-07-24
Prerequisite	Acknowledged Operator Requirements Brief; intended area and context inputs; one-model decision or an explicit documented hold
Done when	One model is selected or explicitly held; rationale and limits are visible; Core plus the selected branch maps to the signed scope; other-model modules are NOT APPLICABLE; every critical workflow has an accountable owner and escalation path
Escalation route	[ATLAS CONFIG: MODEL / SCOPE DECISION ROUTE]; unresolved model choice routes to the partner decision-maker
Live-system link	OPS-01 responsibility map; fallback path: _staging/PHASE1_OPS-01_to_OPS-08_2026-07-21/OPS-01_Operating_Responsibility_Map_v0.1_STAGING.md

Configuration decision record

Field	Controlled entry
Build Specification ID/version	[ATLAS CONFIG]
Selected model	[ATLAS CONFIG: CLINIC / PLATFORM / HELD]
Decision date	[ATLAS CONFIG]
Partner decision-maker	[ATLAS CONFIG]
Intended operating area	[ATLAS CONFIG]
Primary audience	[ATLAS CONFIG]
Operating goals and constraints	[ATLAS CONFIG: REQUIREMENTS-BRIEF LINK]
Model rationale	[ATLAS CONFIG: FACTUAL RATIONALE]
Key assumptions and source dates	[ATLAS CONFIG: CONTEXT-BRIEF LINK]
Included optional modules	[ATLAS CONFIG]
Explicit exclusions	[ATLAS CONFIG]
Unresolved decision / hold	[ATLAS CONFIG: NONE / OWNER / CONSEQUENCE / NEXT ACTION]
Partner acknowledgment	[ATLAS CONFIG: RECORD / DATE]

The decision record documents a configuration; it is not a feasibility, legal, tax, site-selection, market-demand, launch-date, revenue, or outcome opinion.

Model-selection decision path

1. Confirm the Operator Requirements Brief is acknowledged.
2. Confirm the intended area, audience, team, workflow, account, and location facts are current.
3. Compare each model only against written requirements and actual dependencies.
4. Select one model for this Build Specification: Clinic or Platform.
5. If a controlling fact is missing, record HELD, its owner, consequence, and next action.
6. Mark the other branch NOT APPLICABLE.
7. Any hybrid, second model, additional location, or added architecture enters written change control unless expressly scheduled.

Core and branch assembly map

Layer	Included content	Assembly state	Source
Core	Sections 00–11 and 14–16, limited by signed scope	[ATLAS CONFIG]	Binder control
Clinic branch	Section 12 and Clinic-only inserts in shared sections	[ATLAS CONFIG: INCLUDED / NOT APPLICABLE]	[ATLAS CONFIG: CLINIC EDITION LOCATION]
Platform branch	Section 13 and Platform-only inserts in shared sections	[ATLAS CONFIG: INCLUDED / NOT APPLICABLE]	[ATLAS CONFIG: PLATFORM EDITION LOCATION]
Optional modules	Only named modules expressly included or conditionally scheduled	[ATLAS CONFIG]	[ATLAS CONFIG: SIGNED-LINE / VAULT LINK]
Excluded modules	No render and no implied replacement	EXCLUDED	Signed Build Specification

Exactly one model branch may render in a single-model partner edition.

Audience separation

Audience	Relationship	Permitted system purpose	Primary owner	Must not be confused with
Atlas prospect	Person or organization evaluating an Atlas partner build	Atlas recruitment, diligence, Fit Call, proposal, written Build Specification	Atlas	Partner customer
Partner operator	Organization receiving and operating the configured business system	Build decisions, account ownership, staff workflows, marketing, customer operations, ordering, handoff	Partner decision-maker / administrator	Atlas prospect after signing or partner customer
Partner customer	Person interacting with the partner's public business	Partner-controlled inquiry, booking, payment, ordering, service, and support routes as configured	Partner	Atlas customer-support responsibility

Atlas may build systems and templates, but the partner owns and serves the partner-customer relationship. Atlas is not the default customer-contact or fallback route.

Responsibility map

The OPS-01 responsibility map is authoritative. Configure it rather than copying assignments here.

Role class	Responsibility in this decision map	Configuration field
Atlas	Builds and tests included Atlas-controlled outputs; documents status and handoff within signed scope	[ATLAS CONFIG: ATLAS PROJECT OWNER]
Partner	Owns business decisions, accounts, operation, staff, customer communication, and activation authorization	[ATLAS CONFIG: PARTNER PROJECT OWNER / DECISION-MAKER]
Vendor/platform	Performs only the function and responsibilities controlled by its current agreement	[ATLAS CONFIG: OPS-03 RECORD LINK]
Adviser	Supplies retained review or advice within the adviser's role	[ATLAS CONFIG: ADVISER RECORD LINK]
Staff	Performs documented partner-assigned workflows under partner supervision	[ATLAS CONFIG: ROLE / TRAINING LINK]
Qualified external role	Handles the expressly identified matter when required and engaged	[ATLAS CONFIG: ROLE / ROUTE / SOURCE RECORD]

Every critical workflow must have exactly one accountable owner. Missing assignments stay gated; they do not become Atlas tasks by default.

Shared customer-journey map

The OPS-02 journey and escalation map is authoritative.

Journey phase	Core requirement	Selected-mode route	Accountable owner	Record / escalation
Discovery	Approved public information and active CTA state	[ATLAS CONFIG]	Partner	[ATLAS CONFIG]
Inquiry	Business-only intake, source, owner, and fallback	[ATLAS CONFIG]	Partner customer-support owner	[ATLAS CONFIG]
Booking or next-step selection	Approved route, time zone or availability rule, change/cancel fallback	[ATLAS CONFIG]	Partner	[ATLAS CONFIG]
Partner onboarding	Minimum necessary approved information and named record	[ATLAS CONFIG]	Partner	[ATLAS CONFIG]
Written decision	Configured explanation, written offer, questions, accept/decline path	[ATLAS CONFIG]	Partner	[ATLAS CONFIG]
Payment / ordering / service	Only an active, configured path with named owners	[ATLAS CONFIG]	Partner / named external owner	[ATLAS CONFIG]
Support and exception	Partner-controlled case and escalation route	[ATLAS CONFIG]	Partner customer-support owner	[ATLAS CONFIG]
Relationship close	Record closure, retention, access, and follow-up rule	[ATLAS CONFIG]	Partner	[ATLAS CONFIG]

Unresolved supplier, product, payment, professional, account, or fulfillment dependencies keep the affected stage held.

Platform-only branch

Branch state: [ATLAS CONFIG: INCLUDED / NOT APPLICABLE]

Platform-only decision	Required controlled record
Remote workspace, device, connection, and continuity	[ATLAS CONFIG: SECTION 13 / CONTINUITY LINK]
Public contact/address configuration	[ATLAS CONFIG: VERIFIED PUBLIC-IDENTITY RECORD]
Digital discovery, inquiry, meeting, written decision, and support routes	OPS-07 Platform addendum
Account ownership, access, recovery, billing, and export	[ATLAS CONFIG: SECTION 05 / OPS-04 / OPS-08 LINKS]
Distributed roles and service windows	[ATLAS CONFIG: RESPONSIBILITY / OPERATING-HOURS RECORD]
Online-only local-profile eligibility decision	[ATLAS CONFIG: SECTION 07 / ELIGIBILITY RECORD]
Remote supplier, ordering, and customer-support handoffs	[ATLAS CONFIG: SECTION 10 / JOURNEY RECORD]

Platform-only content cannot appear in a Clinic edition and does not certify a physical facility.

Model-specific asset disposition

Asset or module ID	Core / Clinic / Platform / Optional	Scope state	Current version / location	Why included or N/A	Owner	Acceptance evidence
[ATLAS CONFIG]	[ATLAS CONFIG]	INCLUDED / CONDITIONAL / EXCLUDED / NOT APPLICABLE	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]

When one branch is NOT APPLICABLE, omit it without renumbering Core sections or breaking a link. The manifest records the omitted state.

Primary Build Specification coverage

Build Spec ID	Deliverable	Section 02 record	Done-when control
01-03	Clinic / Platform decision record	Configuration decision record + branch assembly state	One configuration selected or explicitly held
01-04	Market and context brief	Intended area, source dates, assumptions, and limits	Sources, dates, assumptions, and limits visible; partner acknowledges

Operational references used here without changing their primary binder home: 01-02, 01-05, 06-01, and 06-02.

Acceptance test

• ☐ One model is selected or explicitly held with owner, consequence, and next action.
• ☐ The intended area/context record shows sources, dates, assumptions, and limits.
• ☐ Core plus exactly one model branch compiles for a single-model edition.
• ☐ Clinic-only language is absent from the Platform edition.
• ☐ Platform-only language is absent from the Clinic edition.
• ☐ The unselected branch and unscheduled optional modules are NOT APPLICABLE or EXCLUDED.
• ☐ Every critical workflow has exactly one accountable owner and a partner-controlled escalation path.
• ☐ The audience map keeps Atlas prospect, partner operator, and partner customer distinct.
• ☐ Every live link has a readable fallback or configured path.
• ☐ No static vendor, price, catalog, contact, account, credential, or external-text value is duplicated.

Section 03 — Brand, Naming, Messaging, and Production Rules

Metadata field	Controlled value
Binder asset ID	APB-SEC-03
Owner	[ATLAS CONFIG: PARTNER BRAND OWNER]
Model	Core — Clinic and Platform
Scope state	[ATLAS CONFIG: INCLUDED / CONDITIONAL / EXCLUDED / NOT APPLICABLE]
Version	v0.1
Last review	2026-07-24
Prerequisite	Signed Build Specification; selected operating model; verified partner identity and audience facts; named decision-maker; rights-cleared source assets
Done when	Every scheduled line 02-01 through 02-08 has a scope state, owner, current asset, acceptance evidence, and disposition; every delivered file opens and matches its accepted direction
Escalation route	[ATLAS CONFIG: BRAND / MESSAGE / RIGHTS ESCALATION ROUTE]
Live-system link	[ATLAS CONFIG: DIGITAL VAULT URL / 02_BRAND]
Human-readable fallback	Digital Vault → 02_BRAND → APB-SEC-03

Purpose

This section tells the partner where the current brand system lives, which record controls each decision, how to request a change, and how to verify delivery. It does not duplicate brand files, changing contact details, license terms, or factual statements.

The signed Build Specification controls what is included. A master, example, or downstream marketing asset does not add scope by itself.

Source-of-truth rules

1. The current accepted brand file or register row controls; a printout, screenshot, exported preview, or older attachment does not.
2. Public identity facts come from the configured partner record. Message text comes from the current message architecture and its linked source/status record.
3. The brand guide assembles accepted decisions; it does not create new facts, rights, or scope.
4. Digital and print production use only the selected identity direction, current design tokens, rights-cleared media, and scheduled formats.
5. Atlas methods and reusable masters remain distinct from partner-specific final files and third-party materials under the signed Build Specification.
6. No password, recovery code, secret key, full payment credential, private personal record, or license key belongs in this section or any printed binder page.

Brand operating sequence

Step	Operator action	Current system	Exit evidence
1	Confirm audience, business identity, model, constraints, and one decision-maker	BR-01 and Build Specification	Completed intake; unresolved facts have owners
2	Run the naming process and record the selected working/final name plus unresolved rights items	BR-02, BR-03, BR-12	Selection record; dated screening observations; registrant-of-record decision
3	Select one identity direction and complete production files	BR-04, BR-05, BR-06	Accepted direction; export inventory; token handoff test
4	Configure the message hierarchy, audience separation, voice, factual forms, and escalation boundaries	BR-07, BR-08, KB-42	Message architecture record; current source/status links
5	Produce only scheduled digital, print, and attribution materials	BR-09, BR-10, BR-11	Render/preflight evidence for the counted files
6	Deliver the configured package and record acceptance, open dependencies, and replacements	BR-08, Build Specification, Vault manifest	Accepted/Conditional/Blocked record and supersession links

Current-system link index

Every digital link below has a readable fallback path. These are staging masters or control records until a configured partner edition is accepted.

Asset	Function	Current state / operating rule	Link	Human-readable fallback
BR-01	Brand and naming intake	Structure ready; partner facts must be configured	Open BR-01	Digital Vault → 02_BRAND → BR-01
BR-02	Naming workshop	Working process only; no rights conclusion	Open BR-02	Digital Vault → 02_BRAND → BR-02
BR-03	Preliminary name-screening record	Records dated observations; not an availability opinion	Open BR-03	Digital Vault → 02_BRAND → BR-03
BR-04	Visual identity presentation	Two directions, one recorded selection	Open BR-04	Digital Vault → 02_BRAND → BR-04
BR-05	Logo production and export	Controls scheduled variants, formats, QA, and rights record	Open BR-05	Digital Vault → 02_BRAND → BR-05
BR-06	Brand design tokens	Handoff contract into WEB-01; licenses stay live-linked	Open BR-06	Digital Vault → 02_BRAND → BR-06
BR-07	Messaging architecture	Organizes facts, copy, messages, sources, and escalation; does not supply product statements	Open BR-07	Digital Vault → 02_BRAND → BR-07
BR-08	Brand guide master	Assembles accepted BR-01 through BR-07 decisions	Open BR-08	Digital Vault → 02_BRAND → BR-08
BR-09	Digital starter-kit templates	Scheduled sizes only; no posting or ongoing production implied	Open BR-09	Digital Vault → 02_BRAND → BR-09
BR-10	Print starter-kit templates	Conditional; printing and fabrication are outside the file delivery	Open BR-10	Digital Vault → 02_BRAND → BR-10
BR-11	Atlas attribution kit	Optional; include only when expressly scheduled	Open BR-11	Digital Vault → 02_BRAND → BR-11
BR-12	Domain and social acquisition	Partner-controlled registrant/account ownership; no credentials stored here	Open BR-12	Digital Vault → 02_BRAND → BR-12
BR register	Stable content-slot and source traceability	Use current row status; never infer approval from a populated mockup	Open BR register	Digital Vault → 02_BRAND → BR_CONTENT_SLOT_REGISTER
KB-42	Governing factual-form boundary	Controls Atlas-facing claims used in the build and sales process	Open KB-42	Knowledge Base → 42_CALL_CLAIMS_PACK
Sales Kit index	Current document layer and configured Build Specification route	Atlas-prospect system; do not repurpose as partner-customer copy	Open Sales Kit index	Digital Vault → 01_SCOPE_AND_DECISIONS → ATLAS_SALES_KIT
Build Specification	Scope, ownership classes, exclusions, and acceptance tests	Configure and version-lock before delivery	Open Build Specification	Digital Vault → 01_SCOPE_AND_DECISIONS → D07_BUILD_SPEC
Partner Marketing System	Downstream uses of the accepted brand	Section 07 controls activation, routes, and campaign use	Open Marketing System index	Digital Vault → 05_MARKETING_AND_EDUCATION → PARTNER_MARKETING_SYSTEM

Controlled configuration record

The values below belong in live records. The print edition shows the asset ID and status, not volatile values or private account details.

Record	Required live fields	Owner	Current state	Live location
Legal/public identity	Legal entity, public brand, approved display form, source, effective date	[ATLAS CONFIG: OWNER]	[ATLAS CONFIG: STATE]	[ATLAS CONFIG: VAULT LINK / 02_BRAND / IDENTITY]
Naming decision	Selected name, decision date, unresolved rights items, adviser route	[ATLAS CONFIG: OWNER]	[ATLAS CONFIG: STATE]	[ATLAS CONFIG: VAULT LINK / 02_BRAND / NAMING]
Domain/social record	Partner-owned accounts, registrant, administrator, recovery role, renewal owner; no secret values	[ATLAS CONFIG: OWNER]	[ATLAS CONFIG: STATE]	[ATLAS CONFIG: VAULT LINK / 09_EXTERNAL_RECORDS / ACCOUNTS]
Audience/positioning	Intended audience, category, differentiation, tone, message boundary, accepted version	[ATLAS CONFIG: OWNER]	[ATLAS CONFIG: STATE]	[ATLAS CONFIG: VAULT LINK / 02_BRAND / POSITIONING]
Identity system	Accepted direction, logo package, design tokens, imagery rules, rights records	[ATLAS CONFIG: OWNER]	[ATLAS CONFIG: STATE]	[ATLAS CONFIG: VAULT LINK / 02_BRAND / IDENTITY_SYSTEM]
Messaging system	Message hierarchy, CTA rules, audience separation, source/status references, escalation owner	[ATLAS CONFIG: OWNER]	[ATLAS CONFIG: STATE]	[ATLAS CONFIG: VAULT LINK / 02_BRAND / MESSAGING]
Production package	Included files, format, dimensions/specification, final version, preflight evidence	[ATLAS CONFIG: OWNER]	[ATLAS CONFIG: STATE]	[ATLAS CONFIG: VAULT LINK / 02_BRAND / PRODUCTION]
Rights/license record	Source, use-right class, channel, term, restrictions, owner, renewal/review date	[ATLAS CONFIG: OWNER]	[ATLAS CONFIG: STATE]	[ATLAS CONFIG: VAULT LINK / 09_EXTERNAL_RECORDS / RIGHTS]

Message and audience operating rules

Decision	Rule	Evidence
Audience	Keep Atlas prospects, partner operators, and partner customers separate. Copy written for one audience is not automatically usable for another.	Accepted audience record and page/channel map
Facts	Use only verified partner administrative facts from the current configured record.	Source, owner, status, review date
Messaging	Pull from BR-07/BR-08 and the current linked source/status record. Never improvise unsupported product, clinical, earnings, outcome, superiority, or credential statements.	Current register row and asset hash/version
CTA	A CTA appears only when its destination, owner, route state, and fallback are configured and tested.	Route test in Section 04
Change	A copy or design change is a controlled revision. It must identify affected channels, files, models, and acceptance tests.	Change-request record
External review	Where an adviser or rights holder controls the decision, keep the item Conditional or Blocked until that dependency is recorded.	Dependency and decision record

Model-branching rules

Shared Core

• Public name, visual identity, message hierarchy, production rules, and source/status controls use one shared Core.
• Model selection may change examples, contact facts, CTA routes, photography, or channel use, but it does not create a second unmanaged brand system.

Clinic insert

• Physical address, directions, facility photography, signage, walk-in language, local profile details, and on-site customer-path references appear only when the Clinic model is selected and each fact is verified.
• Clinic production files use only the configured facility/contact record and the scheduled local assets.

Platform insert

• Digital discovery, remote meeting, online support, public contact, and area descriptions appear only when the Platform model is selected and routes are active.
• A Platform edition must not imply an unverified storefront, walk-in access, staffed local office, facility, or on-site equipment.

Branch verification

• ☐ Selected model is recorded.
• ☐ Shared Core asset IDs remain unchanged.
• ☐ Clinic-only rows are omitted or marked Not Applicable in a Platform edition.
• ☐ Platform-only rows are omitted or marked Not Applicable in a Clinic edition.
• ☐ Omitted optional/model modules do not break numbering, links, or the production sequence.

Production and file-use checklist

Digital

• ☐ Required asset and dimensions are listed in the signed Build Specification.
• ☐ Final brand tokens match BR-06 and pass the intended display checks.
• ☐ Rights-cleared media and fonts have live source/license records.
• ☐ Text and CTA states point to the current message and route records.
• ☐ Editable source and export formats match the configured delivery package.
• ☐ Final files open correctly and have recorded versions and replacement links.

Print

• ☐ BR-10 is expressly included or conditionally scheduled.
• ☐ Printer specifications and proof owner are configured.
• ☐ Content is stable enough to print; changing facts use a controlled live destination plus a readable fallback.
• ☐ No credentials, secrets, private personal data, dynamic price/catalog data, or unpublished account details appear.
• ☐ Visual QA and print preflight evidence are attached to the asset row.
• ☐ Printing, fabrication, shipping, installation, and unscheduled corrections remain outside file delivery unless separately written.

Change request and supersession

Every brand change records:

1. change-request ID and requesting owner;
2. current asset ID/version and requested replacement;
3. source of the changed fact or creative decision;
4. affected Build Specification lines, models, channels, and file formats;
5. rights, route, or external-review dependency;
6. acceptance test and evidence;
7. accepted/conditional/blocked disposition;
8. new version and supersession link; and
9. Vault-manifest update.

No old file is silently overwritten. Superseded files move to 99_ARCHIVE_SUPERSEDED and point to the current version.

Build Specification coverage ledger — primary home

D07 line	Deliverable	Scope state	Current system	Partner/Atlas owner	Acceptance evidence	Current readiness
02-01	Audience and positioning brief	[ATLAS CONFIG]	BR-01, BR-07	[ATLAS CONFIG]	[ATLAS CONFIG: ACCEPTED BRIEF / VERSION]	Master structure available; partner decision pending
02-02	Naming decision support	[ATLAS CONFIG]	BR-02, BR-03, BR-12	[ATLAS CONFIG]	[ATLAS CONFIG: SELECTION / OPEN-RIGHTS RECORD]	Master structure available; selection and rights record pending
02-03	Logo system	[ATLAS CONFIG]	BR-04, BR-05	[ATLAS CONFIG]	[ATLAS CONFIG: ACCEPTED DIRECTION / EXPORT QA]	Master structure available; configured production pending
02-04	Color, typography, imagery, and layout system	[ATLAS CONFIG]	BR-06, BR-08	[ATLAS CONFIG]	[ATLAS CONFIG: GUIDE / TOKEN / RIGHTS QA]	Master structure available; configured values and rights pending
02-05	Core messaging architecture	[ATLAS CONFIG]	BR-07, KB-42	[ATLAS CONFIG]	[ATLAS CONFIG: ACCEPTED MESSAGE MAP / SOURCE-STATUS CHECK]	Architecture available; partner facts and accepted forms pending
02-06	Brand guide and production-file package	[ATLAS CONFIG]	BR-08, BR register	[ATLAS CONFIG]	[ATLAS CONFIG: FILE INVENTORY / OPEN-FILE TEST / ACCEPTANCE]	Master structure available; assembled final package pending
02-07	Digital starter-template set	[ATLAS CONFIG]	BR-09, Marketing System	[ATLAS CONFIG]	[ATLAS CONFIG: COUNT / DIMENSION / EDITABILITY QA]	Masters available; counted partner renders pending
02-08	Print-ready starter materials	[ATLAS CONFIG]	BR-10, Print Kit	[ATLAS CONFIG]	[ATLAS CONFIG: VISUAL QA / PRINT PREFLIGHT / PROOF]	Conditional master assets available; scope and configured output pending

Wave acceptance evidence

This section applies approved Phase 2 tests 3, 5, 6, 7, and 10.

Test	Section 03 evidence	Result
3 — Included line traceability	Eight primary rows map 02-01 through 02-08 to asset, owner, state, and evidence	PASS at master level; partner fields remain [ATLAS CONFIG]
5 — Volatile truth stays live	Identity, accounts, rights, contacts, destinations, and external terms are Vault records, not duplicated here	PASS
6 — Readable fallback for every link	Every current-system link names its Digital Vault fallback	PASS
7 — Print pages expose no secrets	No credential, secret, payment credential, private personal data, or recovery value is stored	PASS
10 — Optional modules can be omitted	BR-10 and BR-11 are conditional/optional; model branches can be omitted without breaking Core flow	PASS

Operator closeout

• ☐ All eight D07 lines have explicit states.
• ☐ One decision-maker accepted the configured brief and identity direction.
• ☐ Every delivered file is inventoried, opens, and matches the accepted version.
• ☐ Rights and license dependencies are live-linked with owners and review dates.
• ☐ Message and CTA sources are current.
• ☐ Clinic/Platform branch check passed.
• ☐ Optional files are included only when scheduled.
• ☐ Superseded assets point to their replacements.
• ☐ Final acceptance evidence is linked in the Vault manifest.

Section 04 — Website, Funnel, and Conversion Path

Metadata field	Controlled value
Binder asset ID	APB-SEC-04
Owner	[ATLAS CONFIG: WEBSITE / ROUTE OWNER]
Model	Core with Clinic and Platform branches
Scope state	[ATLAS CONFIG: INCLUDED / CONDITIONAL / EXCLUDED / NOT APPLICABLE]
Version	v0.1
Last review	2026-07-24
Prerequisite	Signed Build Specification; selected model; accepted brand system; verified business facts; configured CTA purpose; owned destination accounts; supplied/authorized external text
Done when	Every scheduled line 03-01 through 03-10 has a scope state, owner, active/held/fallback route, current asset, test evidence, and disposition; no blocked route is described as active
Escalation route	[ATLAS CONFIG: WEBSITE / FORM / BOOKING / ROUTING ESCALATION]
Live-system link	[ATLAS CONFIG: DIGITAL VAULT URL / 03_WEB_AND_ROUTES]
Human-readable fallback	Digital Vault → 03_WEB_AND_ROUTES → APB-SEC-04

Purpose

This section is the operator's live index for the partner website, CTA path, inquiry form, booking route, confirmation state, external text, analytics plan, QA evidence, and any counted campaign path. It links to the current system; it does not reproduce pages, screenshots, destinations, account details, legal text, or analytics settings as static binder truth.

The presence of a page master, campaign asset, or lead magnet does not mean it is included, approved, configured, active, or public. The signed Build Specification and route-state record control.

Audience firewall

Three audiences use separate routes:

Audience	Intended system	Must not inherit automatically
Atlas prospect	Atlas recruitment pages, Atlas lead magnets, Atlas Sales Kit and written document layer	Partner-customer business identity, partner CRM, or partner-customer statements
Partner operator	Digital Vault, acceptance records, system guides, and administrative routes	Public marketing copy or Atlas prospect pressure language
Partner customer	Configured partner website, business inquiry/booking path, confirmation, and support route	Atlas fees, Atlas proposal documents, Build Specification, adviser pack, or internal operating records

Every new page or campaign path identifies its audience before production. Cross-audience reuse requires a new scope decision, source review, destination, and acceptance test.

Website operating sequence

Step	Operator action	Current system	Exit evidence
1	Confirm selected model, audience, page count, page map, owners, facts, and content dependencies	Build Specification; WEB manifest; configuration matrix	Accepted map or documented open items
2	Bind the accepted brand tokens and configured content sources to the page masters	WEB-01; BR-06; WEB content register	Token test and content/source traceability
3	Configure one primary CTA path and route state for every CTA instance	WEB-02 through WEB-07; route matrix below	Active destination test or visible held/fallback state
4	Configure business-only inquiry, booking, and confirmation paths	WEB-06; WEB-07; CRM/booking system links	Fictional submit/booking/confirmation results
5	Install supplied/authorized external text and record its version source	WEB-08 layouts	Rendered-version match and link test
6	Configure approved analytics events only after account owner and privacy decision are recorded	Event plan below	Fictional events appear in the selected tool
7	Run WEB-09 against desktop, mobile, links, forms, routes, metadata, model branches, and accessibility baseline	WEB-09 and QA evidence	Passes or defects/holds with owner and re-test
8	Activate Atlas-controlled routes or preserve documented holds and rollback	Activation record in Section 15	Go/Conditional/Blocked/N/A record

Current-system link index

Asset	Function	Current state / operating rule	Link	Human-readable fallback
WEB package manifest	Current master inventory and package status	Staging masters; configure per partner before release	Open WEB manifest	Digital Vault → 03_WEB_AND_ROUTES → WEB_MANIFEST
WEB-01 design specification	Component, token, layout, and model-display contract	Bind accepted BR-06 tokens; do not hand-edit per-page identity values	Open WEB-01 specification	Digital Vault → 03_WEB_AND_ROUTES → WEB-01_SPEC
WEB-01 tokens	Current CSS master	Render asset; not a source for business facts	Open WEB-01 tokens	Digital Vault → 03_WEB_AND_ROUTES → WEB-01_TOKENS
WEB-02	Home page master	Shared Core plus selected-model block	Open WEB-02	Digital Vault → 03_WEB_AND_ROUTES → WEB-02
WEB-03	How-it-works master	Steps use configured source/status records	Open WEB-03	Digital Vault → 03_WEB_AND_ROUTES → WEB-03
WEB-04	Education/FAQ master	Product or clinical material remains source-dependent	Open WEB-04	Digital Vault → 03_WEB_AND_ROUTES → WEB-04
WEB-05	About page master	Verified partner facts only	Open WEB-05	Digital Vault → 03_WEB_AND_ROUTES → WEB-05
WEB-06	Contact/booking master	Destination, owner, hours, and fallback must be configured	Open WEB-06	Digital Vault → 03_WEB_AND_ROUTES → WEB-06
WEB-07	Business inquiry-form master	Business-only fields unless a separately designed workflow is scheduled	Open WEB-07	Digital Vault → 03_WEB_AND_ROUTES → WEB-07
WEB-08 disclosures	External-text layout	Install current supplied/authorized text; layout is not the text source	Open disclosure layout	Digital Vault → 03_WEB_AND_ROUTES → WEB-08_DISCLOSURES
WEB-08 privacy	External-text layout	Source version and authorization must be recorded	Open privacy layout	Digital Vault → 03_WEB_AND_ROUTES → WEB-08_PRIVACY
WEB-08 terms	External-text layout	Source version and authorization must be recorded	Open terms layout	Digital Vault → 03_WEB_AND_ROUTES → WEB-08_TERMS
WEB-09	Website QA test master	Run per configured partner edition and model before activation	Open WEB-09	Digital Vault → 03_WEB_AND_ROUTES → WEB-09
WEB-12	Services-page master	Include only when counted in page scope and supported by current sources	Open WEB-12	Digital Vault → 03_WEB_AND_ROUTES → WEB-12
WEB-13	Area-page master	Include only when counted; configured geography facts and routes required	Open WEB-13	Digital Vault → 03_WEB_AND_ROUTES → WEB-13
Model matrix	Clinic/Platform display contract	Governs branch selection; actual partner render still requires QA	Open model matrix	Digital Vault → 03_WEB_AND_ROUTES → MODEL_MATRIX
Variable matrix	Registered variable coverage	No unregistered variable or unresolved public token	Open variable matrix	Digital Vault → 03_WEB_AND_ROUTES → VARIABLE_MATRIX
WEB register	Content/source/version traceability	Populated render does not establish current approval by itself	Open WEB register	Digital Vault → 03_WEB_AND_ROUTES → WEB_CONTENT_REGISTER
QA evidence	Package-level QA record	Use partner-specific evidence for acceptance; this file is not a substitute	Open current QA evidence	Digital Vault → 03_WEB_AND_ROUTES → QA_EVIDENCE
Sales Kit index	Atlas prospect path and written document layer	Atlas-only audience; never expose inside a partner-customer journey	Open Sales Kit index	Digital Vault → 01_SCOPE_AND_DECISIONS → ATLAS_SALES_KIT
Build Specification	Controls page count, path quantity, dependencies, exclusions, ownership, and acceptance	Configure and version-lock before production; a master page does not add scope	Open Build Specification	Digital Vault → 01_SCOPE_AND_DECISIONS → D07_BUILD_SPEC
Red-flag field guide	Atlas recruitment lead magnet	Atlas prospect only; not a partner-customer asset	Open lead magnet	Digital Vault → 05_MARKETING_AND_EDUCATION → ATLAS_LEAD_MAGNETS → RED_FLAG_GUIDE
Ten-year cost sheet	Atlas recruitment lead magnet	Atlas prospect only; not evidence of a partner outcome	Open lead magnet	Digital Vault → 05_MARKETING_AND_EDUCATION → ATLAS_LEAD_MAGNETS → COST_SHEET
Build-Spec demonstration	Atlas recruitment lead magnet	Atlas prospect only; actual partner scope comes from the signed Build Specification	Open demonstration	Digital Vault → 05_MARKETING_AND_EDUCATION → ATLAS_LEAD_MAGNETS → BUILD_SPEC_DEMO

Configured page and content-owner map

Complete one row per included page. Additional pages require a counted Build Specification line or change record.

Page ID	Purpose / audience	Content owner	Current source assets	Scope state	Model	Acceptance evidence
WEB-02	[ATLAS CONFIG]	[ATLAS CONFIG]	WEB-02 + BR-07 + WEB register	[ATLAS CONFIG]	Both with branch	[ATLAS CONFIG]
WEB-03	[ATLAS CONFIG]	[ATLAS CONFIG]	WEB-03 + configured process facts	[ATLAS CONFIG]	Both	[ATLAS CONFIG]
WEB-04	[ATLAS CONFIG]	[ATLAS CONFIG]	WEB-04 + current source/status records	[ATLAS CONFIG]	Both	[ATLAS CONFIG]
WEB-05	[ATLAS CONFIG]	[ATLAS CONFIG]	WEB-05 + verified partner facts	[ATLAS CONFIG]	Both	[ATLAS CONFIG]
WEB-06	[ATLAS CONFIG]	[ATLAS CONFIG]	WEB-06 + destination/owner/hours record	[ATLAS CONFIG]	Both with branch	[ATLAS CONFIG]
WEB-07	[ATLAS CONFIG]	[ATLAS CONFIG]	WEB-07 + field/route/permission decisions	[ATLAS CONFIG]	Both with branch	[ATLAS CONFIG]
WEB-08 disclosure	[ATLAS CONFIG]	[ATLAS CONFIG]	WEB-08 layout + supplied/authorized source version	[ATLAS CONFIG]	Both	[ATLAS CONFIG]
WEB-08 privacy	[ATLAS CONFIG]	[ATLAS CONFIG]	WEB-08 layout + supplied/authorized source version	[ATLAS CONFIG]	Both	[ATLAS CONFIG]
WEB-08 terms	[ATLAS CONFIG]	[ATLAS CONFIG]	WEB-08 layout + supplied/authorized source version	[ATLAS CONFIG]	Both	[ATLAS CONFIG]
WEB-12	[ATLAS CONFIG]	[ATLAS CONFIG]	WEB-12 + current source/status records	[ATLAS CONFIG]	Both	[ATLAS CONFIG]
WEB-13	[ATLAS CONFIG]	[ATLAS CONFIG]	WEB-13 + verified area facts	[ATLAS CONFIG]	Configured	[ATLAS CONFIG]

CTA and route-state matrix

No CTA may dead-end, silently switch audiences, or appear active while its destination is held.

Route ID	Audience	Source page(s)	Intended action	Destination	Destination owner	State	Human-readable fallback	Test evidence
ROUTE-PRIMARY	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG: INQUIRY / BOOKING]	[ATLAS CONFIG: LIVE DESTINATION]	[ATLAS CONFIG]	[ATLAS CONFIG: ACTIVE / HELD / FALLBACK]	[ATLAS CONFIG: READABLE PATH / CONTACT METHOD]	[ATLAS CONFIG]
ROUTE-SECONDARY	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG: ACTIVE / HELD / FALLBACK / N/A]	[ATLAS CONFIG]	[ATLAS CONFIG]
ROUTE-EDUCATION	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG: ACTIVE / HELD / FALLBACK / N/A]	[ATLAS CONFIG]	[ATLAS CONFIG]

Route-state rules

• Active: destination resolves, route owner is named, expected action completes, confirmation is accurate, and fallback is recorded.
• Held: the CTA is suppressed or visibly described as unavailable; the dependency, owner, and next action are recorded.
• Fallback: the primary destination is unavailable and the configured readable alternative has passed its own test.
• Not Applicable: the route is not part of the signed configuration and is omitted without leaving a dead control.

Inquiry, booking, and confirmation path

Path component	Configuration required	Fictional test	Current evidence
Business inquiry form	Purpose, business-only field set, validation, permission decisions, recipient, route owner, error state	Valid and invalid submissions; record creation; owner notification; accurate confirmation	[ATLAS CONFIG: EVIDENCE LINK]
Booking	Owned account, meeting owner, hours, event type, reschedule/cancel rules, notifications, fallback	Book, reschedule, cancel, unavailable-state, owner receipt	[ATLAS CONFIG: EVIDENCE LINK]
Confirmation	Trigger, exact next step, active destination, reply/support route	Confirmation appears only after the configured success event; all actions resolve	[ATLAS CONFIG: EVIDENCE LINK]
Outage/fallback	Failure owner, visible held state, readable alternate route, recovery test	Simulated unavailable destination reaches the alternate route without false success	[ATLAS CONFIG: EVIDENCE LINK]

External-text source-version map

The binder and WEB-08 layouts do not become the source of external text.

Page / element	Source owner	Source ID / version	Authorization record	Installed version/hash	Review date	State
Privacy	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Terms	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Disclosures	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Form notice/consent	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Footer facts	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]

Analytics event plan

No tracking configuration is copied into print. Account identifiers and implementation details remain in the controlled live record.

Event ID	Business question	Trigger	Data minimized to	Account owner	Privacy decision	Fictional test	State
EVT-PAGE	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
EVT-CTA	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
EVT-FORM	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
EVT-BOOK	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]

Model branches

Clinic insert

• The selected Clinic edition may render a verified physical location, directions, parking, facility contact, and on-site route only when those facts and destinations are configured.
• Clinic-only labels and blocks must be absent from the Platform edition.
• A functioning Clinic page does not establish facility, external, or commercial readiness; Section 15 records those dependencies.

Platform insert

• The selected Platform edition may render configured digital discovery, remote meeting, support, and area language without implying an unverified storefront or walk-in route.
• Platform-only labels and blocks must be absent from the Clinic edition.
• An online route must identify its actual owner, hours/rules, and readable fallback.

Model verification

• ☐ Selected model matches the Build Specification.
• ☐ Correct model key renders on every page.
• ☐ Wrong-model blocks are absent rather than merely visually covered.
• ☐ Contact and inquiry options match the selected model.
• ☐ Omitted mode pages/modules do not break navigation, numbering, metadata, or routes.

Website QA and acceptance evidence

Run WEB-09 against the configured partner edition. Record each exception with page, severity, evidence, owner, next action, fix version, and re-test.

Required result set

• ☐ Desktop/mobile rendering at configured breakpoints.
• ☐ Keyboard path, focus visibility, headings, labels, errors, and reduced-motion behavior.
• ☐ Color contrast and rights-linked image handling.
• ☐ Internal/external link results.
• ☐ Form, booking, confirmation, held, and fallback route results.
• ☐ Metadata completion and configured canonical destination.
• ☐ Selected-model branch result and wrong-model absence.
• ☐ Current source/status traceability for installed text.
• ☐ External-text source/version match.
• ☐ Approved fictional analytics-event test where analytics is scheduled.
• ☐ Pre-activation snapshot and rollback location.
• ☐ Open defects/holds classified with owners; nothing blocked labeled complete.

Print-versus-live rule

The print binder may show:

• page/route IDs and the accepted page map;
• stable operating sequence and test checklist;
• route owner roles;
• current state as of a printed date; and
• a configured Vault link plus readable fallback.

The print binder must not serve as:

• a copy of the public website;
• a screenshot-based acceptance record;
• the current destination, vendor, account, contact, analytics, or external-text record;
• a credential/recovery store;
• an evergreen statement that a held route is active; or
• a replacement for current QA evidence.

Additional page, lead magnet, or campaign path

Line 03-10 is included only when its quantity and components are expressly scheduled. For each counted path, record:

1. intended audience and purpose;
2. page/form/asset IDs;
3. source content and current status;
4. destination, owner, route state, and fallback;
5. model and channel;
6. analytics/privacy decision where scheduled;
7. display, route, form, metadata, and accessibility-baseline tests; and
8. acceptance evidence.

The three files in ATLAS_LEAD_MAGNETS are Atlas-prospect assets. They remain separate from partner-customer funnels unless a future written scope expressly creates and tests a partner-specific asset.

Change request and rollback

Every website/funnel change records:

1. request ID, requester, reason, and source;
2. affected Build Specification line, page, route, model, and audience;
3. current and proposed asset versions;
4. content, factual, external-text, account, and integration dependencies;
5. acceptance test and rollback point;
6. owner and disposition;
7. re-test evidence; and
8. new Vault-manifest and supersession links.

Build Specification coverage ledger — primary home

D07 line	Deliverable	Scope state	Current system	Partner/Atlas owner	Acceptance evidence	Current readiness
03-01	Site map and content plan	[ATLAS CONFIG]	WEB manifest, page/content-owner map above	[ATLAS CONFIG]	[ATLAS CONFIG: ACCEPTED MAP / CONTENT SCHEDULE]	Masters inventoried; partner map and facts pending
03-02	Responsive core website	[ATLAS CONFIG]	WEB-01, WEB-02 through WEB-08	[ATLAS CONFIG]	[ATLAS CONFIG: PARTNER RENDER / DESKTOP-MOBILE-LINK QA]	Masters available; configured partner render pending
03-03	Primary funnel / CTA path	[ATLAS CONFIG]	CTA and route-state matrix; WEB-02, WEB-06	[ATLAS CONFIG]	[ATLAS CONFIG: ACTIVE/HELD/FALLBACK TEST]	Route framework available; live destination and owner pending
03-04	Business inquiry form and confirmation	[ATLAS CONFIG]	WEB-07, inquiry path table above	[ATLAS CONFIG]	[ATLAS CONFIG: VALIDATION / ROUTING / CONFIRMATION TEST]	Master available; real route decisions pending
03-05	Booking integration	[ATLAS CONFIG]	WEB-06, booking path table above	[ATLAS CONFIG]	[ATLAS CONFIG: BOOK / RESCHEDULE / CANCEL / OWNER TEST]	Master available; partner-owned calendar and rules pending
03-06	Confirmation / thank-you experience	[ATLAS CONFIG]	WEB-06, WEB-07	[ATLAS CONFIG]	[ATLAS CONFIG: TRIGGER / NEXT-STEP / DEAD-ACTION TEST]	Master states available; actual workflow pending
03-07	External-text installation	[ATLAS CONFIG]	WEB-08 layouts, source-version map above	[ATLAS CONFIG]	[ATLAS CONFIG: INSTALLED-VERSION / LINK / AUTHORIZATION TEST]	Layouts available; source/version authorization pending
03-08	Baseline website QA	[ATLAS CONFIG]	WEB-09, current package evidence	[ATLAS CONFIG]	[ATLAS CONFIG: PARTNER QA RECORD / DEFECT LOG / RETEST]	QA master available; partner-specific cycle pending
03-09	Analytics event plan and configuration	[ATLAS CONFIG]	Analytics event plan above; WEB-09 analytics checks	[ATLAS CONFIG]	[ATLAS CONFIG: ACCOUNT / PRIVACY DECISION / FICTIONAL EVENT TEST]	Planning schema available; account and approved events pending
03-10	Additional landing page, lead magnet, or campaign funnel	[ATLAS CONFIG]	WEB-12, WEB-13, Atlas lead magnets	[ATLAS CONFIG]	[ATLAS CONFIG: COUNTED PATH / DISPLAY / ROUTE / METADATA TEST]	Conditional masters exist; no additional partner path inferred

Wave acceptance evidence

This section applies approved Phase 2 tests 3, 5, 6, 7, and 10.

Test	Section 04 evidence	Result
3 — Included line traceability	Ten primary rows map 03-01 through 03-10 to asset, owner, state, and evidence	PASS at master level; partner fields remain [ATLAS CONFIG]
5 — Volatile truth stays live	Destinations, account details, contacts, external text, analytics, facts, and route states are live records	PASS
6 — Readable fallback for every link	Every current-system link names its Digital Vault fallback; route table requires one for public paths	PASS
7 — Print pages expose no secrets	No credential, secret, account identifier, recovery value, or private personal data is stored	PASS
10 — Optional modules can be omitted	Additional pages/campaigns and wrong-model blocks can be omitted without breaking Core navigation or routes	PASS

Operator closeout

• ☐ All ten D07 lines have explicit states.
• ☐ Page map, audience, owners, model, and content sources are accepted.
• ☐ Every CTA is Active, Held, Fallback, or Not Applicable and displays accordingly.
• ☐ Inquiry, booking, confirmation, and outage branches have fictional test evidence.
• ☐ Current external-text versions match their authorized sources.
• ☐ Analytics is absent unless its account owner and privacy decision are configured.
• ☐ Partner-specific WEB-09 results and re-tests are linked.
• ☐ Clinic/Platform branch check passed.
• ☐ Optional/additional paths are counted or omitted cleanly.
• ☐ Rollback, supersession, and current-version records are linked in the Vault manifest.

Section 05 — Digital Accounts, Security, and Technology Stack

Status: DRAFT-APPLIED SECTION MASTER · STAGING ONLY · NOT A CONFIGURED PARTNER EDITION

Control metadata

Field	Controlled value
Owner	[ATLAS CONFIG: PARTNER ADMINISTRATOR]
Model	Core — Clinic and Platform
Scope state	[ATLAS CONFIG: INCLUDED / CONDITIONAL / EXCLUDED / NOT APPLICABLE]
Version	0.1
Last review	2026-07-24
Prerequisite	Signed Build Specification; selected model; named partner administrator; configured vendor and account records
Done when	Every included production system has a partner-controlled owner, administrator, billing owner, recovery route, export path, Atlas-access removal route, environment label, and recorded fictional test; no secret is stored in this binder
Escalation route	[ATLAS CONFIG: PARTNER SECURITY / TECHNOLOGY ESCALATION ROUTE]
Live-system link	[ATLAS CONFIG: DIGITAL VAULT URL — 09_EXTERNAL_RECORDS / VENDOR_AND_ACCOUNT_REGISTERS]
Human-readable fallback	Digital Vault → 09_EXTERNAL_RECORDS → Vendor and Account Registers
Build Specification ownership	04-01, 06-03, 06-04

What this section controls

This section is the operator's map to the technology stack. It does not replace the underlying build recipes, vendor register, account inventory, recovery records, or system documentation. It tells the partner:

1. which record controls each system;
2. who owns and administers it;
3. whether it is simulation, staging, or production;
4. what must be tested before it is relied on;
5. where recovery and continuity instructions live; and
6. which route to use when the normal path fails.

The binder records references and roles only. Passwords, passkeys, recovery codes, API keys, tokens, private keys, full payment credentials, secret answers, session data, and credential screenshots never belong here.

Start here — three-source control

Need	Controlling asset	What the operator does here
CRM platform and configuration sequence	CRM-01 Platform Build Recipe	Confirm the configured production account, environment, owner, and completed system tests
Vendor, payer, renewal, data, support, export, and continuity facts	OPS-03 Vendor and Technology Register	Update the live register; do not copy changing facts into the print binder
Account owner, administrators, access, recovery, and removal	OPS-04 Account and Credential Inventory	Update reference fields only; store actual secrets in the approved password manager
Data export, continuity, and offboarding	OPS-08 Data, Export, Continuity, and Offboarding	Follow the current export/recovery checklist and retain evidence
Handoff inventory	HO-03 Handoff, Access, and License Manifest	Confirm partner control and open dependencies at handoff
Ordering-system dependency	Ordering-system deploy guide and supplier integration specification	Treat as a dependency link only; ordering configuration and operating instructions belong in Section 10
Claims boundary	KB-42 Call Claims Pack	Use only the current permitted factual forms; route unsupported statements for review

Current-state rule: a staging file demonstrates structure, not a completed production account, live route, transferred ownership, paid subscription, vendor acceptance, or successful handoff.

Technology stack router

Complete the live OPS-03 and OPS-04 records for every included row. The fields below are navigation fields, not vendor selections.

System function	Required state	Primary control record	Production evidence	Current state
Domain and DNS	Partner-controlled production account with recovery and transfer route	OPS-03 + OPS-04	Ownership, administrator, MFA, recovery, DNS test, renewal owner	[ATLAS CONFIG]
Website hosting	Production environment with deploy and rollback owners	OPS-03 + OPS-04	Release ID, deployment result, rollback test, export path	[ATLAS CONFIG]
CRM and forms	Configured production account or documented held state	CRM-01 + OPS-03 + OPS-04	Fictional record test, admin control, export, suppression and recovery tests	[ATLAS CONFIG]
Booking/calendar	Configured time zone, hours, owner, notifications, and fallback	CRM-04 + OPS-03 + OPS-04	Book/reschedule/cancel/missed-meeting test and outage fallback	[ATLAS CONFIG]
Email sender	Authenticated sender, reply owner, suppression, and recovery	CRM-01 + CRM-09 + OPS-03 + OPS-04	Seed test, reply test, unsubscribe test, suppression test	[ATLAS CONFIG]
Phone/voicemail	Partner-owned number, coverage owner, callback path, outage fallback	[ATLAS CONFIG: LIVE PHONE SYSTEM RECORD]	Inbound, voicemail, callback, after-hours, and outage tests	[ATLAS CONFIG]
Analytics	Included events only, with approved data decision and account owner	OPS-03 + OPS-04 + Section 04 route/event map	Fictional event evidence, access, disable/export path	[ATLAS CONFIG]
File workspace	Partner-controlled production workspace with export and recovery	OPS-03 + OPS-04 + HO-03	Administrator access, folder map, export, recovery	[ATLAS CONFIG]
Password manager	Partner-controlled account with named recovery owner	OPS-03 + OPS-04	MFA, recovery, share, and revoke test without exposing a secret	[ATLAS CONFIG]
Payment processing	Included only when the configured payment route and responsible parties exist	OPS-03 + Section 10	Processor ownership, test-mode result, settlement/dispute owner	[ATLAS CONFIG]
Ordering access	Included only when Section 10 dependencies are resolved	Ordering-system documentation + Section 10	Fictional order and access/recovery tests	[ATLAS CONFIG]

Account lifecycle checklist

Create or accept an account

• ☐ Name the legal/partner owner.
• ☐ Name one primary administrator and one recovery owner.
• ☐ Record the legal vendor once in OPS-03 and map all functions to that row.
• ☐ Create a distinct account reference in OPS-04 for each actual account and environment.
• ☐ Mark the environment SIMULATION, STAGING, or PRODUCTION.
• ☐ Record contract, billing, renewal, support, export, termination, and continuity owners.
• ☐ Enable MFA where available or record the exception and decision owner.
• ☐ Put the secret only in the approved password manager.
• ☐ Record Atlas access purpose, permission level, start date, and removal trigger.
• ☐ Run the fictional functional test and link the evidence.

Review access

• ☐ Review privileged access at each delivery gate, role change, incident, handoff, support close, and offboarding.
• ☐ Remove unused, shared, duplicate, or excessive permissions.
• ☐ Confirm that partner operation and recovery do not depend on an Atlas-only identity.
• ☐ Confirm that billing and renewal reach a current partner-controlled route.
• ☐ Confirm that exports and backups can be retrieved without live customer data entering the evidence file.
• ☐ Log exceptions with owner, consequence, fallback, and next action.

Remove or transfer access

• ☐ Revoke the user's access in the underlying system.
• ☐ Revoke password-manager shares and rotate affected secrets where appropriate.
• ☐ Confirm partner administrator access remains functional.
• ☐ Export or transfer the configured business records.
• ☐ Record completion in OPS-04 and HO-03.
• ☐ Retest the critical workflow or document the held state.

Minimum-necessary data map

The live data decision belongs in the configured system records. This print section retains only the classification and route.

Data class	Default treatment	System-of-record link	Incident owner
Public business facts	May enter approved public assets after source and route checks	[ATLAS CONFIG: PUBLIC FACT RECORD URL]	[ATLAS CONFIG]
Business inquiry data	Collect only configured administrative fields	CRM-03 Field Dictionary	[ATLAS CONFIG]
Permission and suppression data	Preserve purpose, channel, wording version, source, timestamp, and current status	CRM-09 Consent, Unsubscribe, and Suppression	[ATLAS CONFIG]
Customer/order operational data	Limit to the configured operational purpose and role access	Section 10 live records	[ATLAS CONFIG]
Payment data	Keep within the configured processor path; do not copy full payment credentials into Atlas records	[ATLAS CONFIG: PAYMENT SYSTEM RECORD URL]	[ATLAS CONFIG]
Sensitive information submitted unexpectedly	Do not request it by default; follow the configured minimization, handling, and escalation route	[ATLAS CONFIG: SENSITIVE-DATA HANDLING RECORD URL]	[ATLAS CONFIG]
Credentials and secrets	Never store in the binder or general project workspace	Approved password manager only	[ATLAS CONFIG]

Incident and continuity quick route

Use the current OPS-08 record for full steps.

Event	Immediate operator action	Continuity action	Evidence
Administrator locked out	Stop repeated attempts; notify the recovery owner	Use the recorded recovery method; preserve partner ownership	Incident ID + recovery result
Website or form unavailable	Hold affected CTA or publication route	Use the configured human-readable inquiry fallback	Route test + hold/restore time
CRM unavailable	Preserve new inquiries through the configured minimum-data fallback	Enter recovered records only through the approved process	Fallback log + reconciliation
Booking unavailable	Hold the broken booking link	Use the configured partner-owned call or inquiry route	Link check + replacement route
Email sender unavailable	Stop automated sending	Use a configured non-bulk partner response route if approved	Hold record + recovery test
Phone unavailable	Activate the configured alternate route or status notice	Preserve callbacks in the approved fallback record	Call test + reconciliation
Suspected credential exposure	Remove affected access and notify the incident owner	Rotate through the approved system; retest critical paths	Incident record without the secret
Vendor suspension or closure	Mark dependent workflow Conditional or Blocked	Use the OPS-03 continuity/export path and assign replacement owner	Decision + export/replacement evidence

Model branches

Platform edition

• Include remote workspace, device ownership, internet fallback, remote meeting route, distributed user access, public contact configuration, and remote continuity.
• Do not render Clinic-only facility, walk-in, signage, front-desk, parking, or local-profile instructions.
• A Platform branch does not imply a physical public location or local-profile eligibility.

Print versus live

Print contains: system function, record ID, owner role, current scope state, human-readable fallback path, acceptance status, and escalation route.

Digital Vault contains: vendor names, account identifiers, URLs, billing/renewal dates, contacts, contracts, data decisions, evidence, access history, exports, incidents, and supersession records.

Neither contains: actual credentials or secrets. Those remain in the approved password manager.

If a printed vendor, account, contact, date, or URL conflicts with the live record, stop using the printed value and use the current Digital Vault record.

Acceptance evidence register

Build Spec ID	Evidence required	Evidence link	Owner	Status	Next action
04-01	Reproducible CRM configuration; fictional fixture completes the configured pipeline; production account state identified	[ATLAS CONFIG: EVIDENCE URL]	[ATLAS CONFIG]	[ATLAS CONFIG: NOT STARTED / READY FOR REVIEW / ACCEPTED / CONDITIONAL / BLOCKED / N/A]	[ATLAS CONFIG]
06-03	Every included system maps to a vendor or documented partner-owned alternative; owner, payer, renewal, support, data, export, recovery, and termination fields complete	[ATLAS CONFIG: EVIDENCE URL]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
06-04	Ownership, administrator, recovery, billing, Atlas access, MFA state, removal route, and fictional revoke/recovery tests recorded without secrets	[ATLAS CONFIG: EVIDENCE URL]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]

Wave 2 acceptance checks

• ☐ Test 3 — coverage: each owned Build Specification line above has a section, asset links, owner, status, and acceptance-evidence field.
• ☐ Test 5 — live truth: changing vendor, account, billing, renewal, recovery, contact, and technology facts remain in OPS-03/OPS-04 or configured live records, not copied into this section.
• ☐ Test 6 — fallback: every live link has the human-readable Digital Vault path shown in its control record.
• ☐ Test 7 — safe print: no password, token, key, recovery code, full payment credential, secret answer, personal customer data, or secret-bearing screenshot appears here.
• ☐ Test 10 — modularity: this Core section works with either model; each edition includes only its selected model branch without breaking the common workflow.

Operator sign-off

Role	Name	Decision	Date	Open dependency
Partner administrator	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Atlas project owner	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]

Section 06 — Lead Capture, Phone, Booking, and Follow-Up

Status: DRAFT-APPLIED SECTION MASTER · STAGING ONLY · NOT A CONFIGURED PARTNER EDITION

Control metadata

Field	Controlled value
Owner	[ATLAS CONFIG: PARTNER INQUIRY / CUSTOMER-SUPPORT OWNER]
Model	Core with Clinic and Platform route branches
Scope state	[ATLAS CONFIG: INCLUDED / CONDITIONAL / EXCLUDED / NOT APPLICABLE]
Version	0.1
Last review	2026-07-24
Prerequisite	Selected model; active website route; configured CRM account; approved business-only fields; partner-owned response routes; named users and service windows
Done when	A fictional inquiry can enter from every included source, create one correctly owned record, follow each booking and follow-up branch, honor permissions and suppression, use the correct model route, survive an outage fallback, and produce linked evidence without live customer data
Escalation route	[ATLAS CONFIG: CRM / INQUIRY ESCALATION ROUTE]
Live-system link	[ATLAS CONFIG: DIGITAL VAULT URL — 04_CRM_AND_MESSAGES / CURRENT_INSTANCE]
Human-readable fallback	Digital Vault → 04_CRM_AND_MESSAGES → Current CRM Instance
Build Specification ownership	04-02, 04-03, 04-04, 04-05, 04-06

Purpose and operating boundary

This section is the daily operating map for an inquiry from first capture through booking, response, nurture, suppression, or clean close. It links to the current CRM masters and partner instance instead of copying changing fields, timing, messages, URLs, recipients, or vendor settings into a static binder.

The default workflow collects business and administrative inquiry information only. It does not request health, medical, diagnostic, treatment, symptom, medication, biometric, or clinical information. Atlas does not contact a partner's customers directly.

Current system links

Operating need	Current master	Operator use
Rebuild/configuration order	CRM-01 Platform Build Recipe	Confirm account, sender, booking route, responsible users, and all functional tests
Pipeline stages and instrumentation	CRM-02 Core Pipeline	Apply current stage entry, exit, owner, task, and event rules
Field set and data boundaries	CRM-03 Field Dictionary	Use only configured fields; keep prohibited-by-default fields out
Booking, reminders, reschedule, cancellation, and missed-meeting branches	CRM-04 Calendar Recipe	Configure and test model-specific location, time zone, hours, owner, and messages
Website form mapping and internal notification	CRM-05 Form-to-Pipeline Workflow	Test deduplication, ownership, notification, failure handling, and consent records
Immediate confirmation	CRM-06 Confirmation Email	Use only the configured partner version and active reply route
Follow-up message 1	CRM-07 Follow-Up Email 1	Use only the configured trigger, timing, identity, and route
Follow-up message 2	CRM-08 Follow-Up Email 2	Use only the configured trigger, timing, identity, and route
Consent, unsubscribe, and suppression	CRM-09 Consent, Unsubscribe, and Suppression	Test every included permission, opt-out, reply, suppression, and re-entry path
Core inquiry and booking SOPs	OPS-05 Core SOP Pack	Follow the configured owner, trigger, steps, record, exception, and escalation
Platform route differences	OPS-07 Platform Workflow Addendum	Apply only in a Platform edition
Claims boundary	KB-42 Call Claims Pack	Keep public and spoken statements within current permitted factual forms

Message rule: the binder does not reproduce message bodies. The exact installed version, source, sender, trigger, timing, reply owner, footer facts, and suppression state remain in the live CRM record.

Inquiry route map

Complete one row per included source. Do not mark a route Active until the exact source, destination, owner, fallback, and evidence exist.

Route ID	Source	Primary destination	Record owner	Service window	Fallback	State	Evidence
IR-01	Website inquiry form	[ATLAS CONFIG: CRM ROUTE]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG: HUMAN-READABLE INQUIRY ROUTE]	[ATLAS CONFIG: DRAFT / READY / ACTIVE / HELD / N/A]	[ATLAS CONFIG]
IR-02	Public business phone	[ATLAS CONFIG: PHONE / CALL QUEUE]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG: VOICEMAIL / ALTERNATE ROUTE]	[ATLAS CONFIG]	[ATLAS CONFIG]
IR-03	Voicemail	[ATLAS CONFIG: CALLBACK QUEUE]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
IR-04	Public email or approved direct message	[ATLAS CONFIG: INBOX / CRM TASK]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
IR-05	Booking route	[ATLAS CONFIG: BOOKING URL / CALENDAR]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG: MANUAL BOOKING ROUTE]	[ATLAS CONFIG]	[ATLAS CONFIG]
IR-06	Approved campaign or referral source	[ATLAS CONFIG: SOURCE-CODED ROUTE]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]

Standard operator sequence

1. Capture

• Confirm the source is one of the included, tested routes.
• Create or merge one contact according to CRM-05; do not create a second contact when the deduplication rule applies.
• Preserve source, campaign/event code, partner code, capture route, and timestamp.
• Store the current privacy-consent record and any separate optional marketing-consent record.
• Do not infer permission for another channel or purpose.

2. Assign

• Enter the record at the configured first stage.
• Assign one owner and one next task.
• Apply the configured service window as an internal operating field, not a public response promise.
• Route missing ownership or failed notification to the exception queue.

3. Respond

• Use the current partner-approved confirmation or response asset.
• Confirm that the sender identity, reply path, business identification, and active CTA match the current route state.
• Keep unsupported facts, results, product statements, professional claims, timing assurances, and improvised answers out.
• Route questions outside the configured business/process scope to [ATLAS CONFIG: APPROVED ESCALATION ROLE].

4. Book or record another next step

• Use the configured calendar, time zone, duration, buffer, notice, and owner.
• Record the exact Clinic or Platform destination that applies.
• Confirm that book, reschedule, cancel, reminder, and missed-meeting branches use the correct recipient and message version.
• If booking is not appropriate, record the configured next step, nurture state, clean close, or escalation.

5. Follow up

• Trigger only the message assigned to the current state.
• Check current permission and suppression before every commercial message.
• Route replies to the named partner owner.
• Stop future automated contact when the suppression rule applies.
• Record hard failures, replies, opt-outs, and manual do-not-contact actions.

6. Close the loop

• Record the resulting state and next owner.
• Leave no record without an owner, next action, or valid closed state.
• Reconcile fallback records after an outage.
• Escalate defects separately from customer-service questions and new build requests.

Phone and voicemail configuration card

Changing phone facts stay in the live record at [ATLAS CONFIG: PHONE SYSTEM RECORD URL].

Field	Configured reference
Public number	[ATLAS CONFIG: REFERENCE ONLY]
Legal/partner owner	[ATLAS CONFIG]
Call owner by operating window	[ATLAS CONFIG]
After-hours route	[ATLAS CONFIG]
Voicemail asset ID/version	[ATLAS CONFIG]
Callback queue and owner	[ATLAS CONFIG]
Alternate route during outage	[ATLAS CONFIG]
Call-recording state and notice source, if used	[ATLAS CONFIG]
Last inbound/voicemail/callback/outage test	[ATLAS CONFIG]

Phone copy belongs in the controlled live asset, not this binder. Never put customer recordings, transcripts, phone-system credentials, or personal call notes in the print edition.

Daily queue control

Run this at [ATLAS CONFIG: DAILY REVIEW TIMES].

• ☐ New inquiries have one owner and one next action.
• ☐ Failed form, notification, email, phone, and booking events have owners.
• ☐ Contact-attempt tasks follow the configured service window.
• ☐ Today's bookings show the correct mode destination and responsible person.
• ☐ Reschedules, cancellations, and missed meetings are in the correct branch.
• ☐ Replies and customer-service questions are assigned to the partner.
• ☐ Opt-outs, hard failures, and manual do-not-contact records are suppressed correctly.
• ☐ No suppressed contact entered another automation.
• ☐ No record contains a requested-by-default prohibited field.
• ☐ Fallback records created during an outage are reconciled once, without duplicates.
• ☐ Closed/not-fit and nurture records have their next-review or closed-state fields.
• ☐ Defects and new requests carry separate IDs and escalation routes.

Exception queue

Exception	Hold action	Responsible route	Recovery evidence
Form submission does not create one record	Hold affected form CTA if loss/duplication continues	[ATLAS CONFIG: CRM TECH OWNER]	Fictional resubmission + dedupe result
Internal notification fails	Keep the inquiry record; assign it manually	[ATLAS CONFIG: QUEUE OWNER]	Owner receives test alert
Email delivery or authentication fails	Hold automated email	[ATLAS CONFIG: SENDER ADMIN]	Seed, reply, and suppression tests
Booking link fails	Hold the broken link; use the configured human-readable inquiry route	[ATLAS CONFIG: CALENDAR OWNER]	Book/reschedule/cancel test
Phone or voicemail fails	Activate the configured alternate route	[ATLAS CONFIG: PHONE OWNER]	Inbound/voicemail/callback test
Duplicate records	Stop the failing import/automation if necessary	[ATLAS CONFIG: CRM ADMIN]	Merge/reconciliation record
Suppression failure	Stop affected commercial automation	[ATLAS CONFIG: CRM ADMIN]	Attempted send to fictional suppressed record is blocked
Unexpected sensitive submission	Restrict access and follow the configured handling record	[ATLAS CONFIG: PRIVACY ESCALATION OWNER]	Incident/handling record without copied sensitive content
Unsupported question or statement request	Do not improvise	[ATLAS CONFIG: APPROVED FACT / QUALIFIED REVIEW ROUTE]	Current approved response or held status

Model branches

Platform edition

• Calendar destination, remote meeting link, time zone, remote support window, and meeting-link fallback are configured as digital routes.
• Do not render facility address, walk-in, parking, front-desk, signage, or on-site arrival instructions.
• Public contact configuration must not imply a physical public location that does not exist.
• Platform-specific route language does not certify a Clinic facility.

Print versus live

Print contains: route IDs, owner roles, decision sequence, daily checklist, exception categories, status vocabulary, escalation roles, and human-readable fallback paths.

Digital Vault contains: actual URLs, numbers, recipients, operating windows, field values, installed copy, consent text, message timing, account details, send logs, call evidence, customer records, test evidence, and supersession history.

If the print edition conflicts with the live CRM instance or current asset manifest, stop and use the live controlled record.

Acceptance evidence register

Build Spec ID	Evidence required	Evidence link	Owner	Status	Next action
04-02	Configured pipeline stages, owners, tasks, entry/exit rules, and a fictional full-path plus closed-branch test	[ATLAS CONFIG: EVIDENCE URL]	[ATLAS CONFIG]	[ATLAS CONFIG: NOT STARTED / READY FOR REVIEW / ACCEPTED / CONDITIONAL / BLOCKED / N/A]	[ATLAS CONFIG]
04-03	Field export/data dictionary shows only necessary configured fields; storage/display/export test passes; prohibited-by-default fields absent	[ATLAS CONFIG: EVIDENCE URL]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
04-04	Fictional submission creates one correct record, owner/task, internal alert, source record, and deduplicated repeat	[ATLAS CONFIG: EVIDENCE URL]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
04-05	Exact configured message set passes trigger, timing, personalization, reply, link, unsubscribe, and suppression tests	[ATLAS CONFIG: EVIDENCE URL]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
04-06	Fictional privacy-permission, marketing-permission, opt-out, hard-failure, suppression, reply, and re-entry scenarios route correctly	[ATLAS CONFIG: EVIDENCE URL]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]

Wave 2 acceptance checks

• ☐ Test 3 — coverage: each owned Build Specification line has current asset links, owner, state, acceptance evidence, and next action.
• ☐ Test 5 — live truth: routes, recipients, timing, message text, field values, consent text, phone facts, URLs, and customer records remain in live systems and controlled assets.
• ☐ Test 6 — fallback: every QR or short link used in the configured edition has a readable route such as Digital Vault → 04_CRM_AND_MESSAGES → Current CRM Instance.
• ☐ Test 7 — safe print: no credential, secret, personal customer record, call recording, transcript, or sensitive submission appears in print.
• ☐ Test 10 — modularity: the same Core works with either model; removing the unselected branch leaves capture, booking, follow-up, exception, and acceptance flow intact.

Operator sign-off

Role	Name	Decision	Date	Open dependency
Partner inquiry/customer-support owner	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Partner CRM administrator	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Atlas project owner	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]

Section 07 — Marketing and Area Demand Generation

Status: DRAFT-APPLIED SECTION MASTER · STAGING ONLY · NOT A CONFIGURED PARTNER EDITION

Control metadata

Field	Controlled value
Owner	[ATLAS CONFIG: PARTNER MARKETING OWNER]
Model	Core with eligible local and Platform branches
Scope state	[ATLAS CONFIG: INCLUDED / CONDITIONAL / EXCLUDED / NOT APPLICABLE]
Version	0.1
Last review	2026-07-24
Prerequisite	Selected model; approved public facts; rights-cleared brand assets; active destination routes; configured channel accounts; named owner; first-30-days start event
Done when	Every included channel has a current asset, owner, route state, source code, functional test, human-readable fallback, review cadence, and completion evidence; held or ineligible channels are not represented as active
Escalation route	[ATLAS CONFIG: MARKETING / ROUTE ESCALATION]
Live-system link	[ATLAS CONFIG: DIGITAL VAULT URL — 05_MARKETING_AND_EDUCATION / ACTIVE_CAMPAIGN]
Human-readable fallback	Digital Vault → 05_MARKETING_AND_EDUCATION → Active Campaign
Build Specification ownership	05-05, 05-06, 05-07, 05-08

Purpose

This section turns the current Atlas marketing assets into a controlled operator sequence. It does not reproduce the caption bank, local-profile content, ads, print pieces, lead magnets, changing channel facts, or campaign dates. It shows the partner which asset to use, when it may be used, where it sends a person, who owns the route, how the source is recorded, and what evidence closes the task.

Marketing activity is a configured operating process. Publication, account approval, printing, distribution, platform acceptance, reach, response, reviews, customers, or other business results are not established by the presence of a file.

Current marketing-system links

Asset family	Current source	Operator decision
Master index	Partner Marketing System index	Confirm installed asset versions, binding rules, and held routes
Social captions	Social Caption Bank	Select configured channel, approved asset, active route, owner, and schedule
Local profile and citations	Local SEO / Business Profile Kit	Run eligibility first; use only verified current business facts
First 30 days	Launch Campaign Calendar	Configure the start event, owners, channels, dependencies, dates, and evidence
Ad creative	Ad Bank	Bind only selected current creative to an approved active route
Two-sided flyer	Print Kit — Flyer	Resolve tokens, rights, destination, print specifications, proof, and version
Referral card	Print Kit — Referral Card	Resolve tokens, route, attribution, distribution owner, proof, and version
Lead magnet — red-flag field guide	Current staging asset	Scope, audience, message, source, and destination review required before partner use
Lead magnet — cost worksheet	Current staging asset	Scope, audience, calculations, inputs, message, and destination review required before partner use
Lead magnet — Build Specification demonstration	Current staging asset	Treat as Atlas-origin material unless a partner-use version is expressly scheduled
Consumer email bank	14-email source bank	Use only the generated partner output with configured sender, audience, trigger, timing, route, permission, reply, footer, and suppression
Short-form video bank	12-reel source bank	Use only the generated partner output with resolved brand/route tokens, current source status, rights, channel, and publication record
Partner configuration	Canonical configuration template	Create one partner-specific config; leave unresolved fields visible rather than hand-editing source masters
Replication tool	Canonical partner builder	Generate the partner's tailored output and BUILD_REPORT; never edit source masters or generated output as the new master
Inquiry and source capture	CRM-03 Field Dictionary, CRM-05 Form-to-Pipeline	Preserve approved source and campaign/event code through the CRM route
Activation and launch checks	HO-01 Activation Go/No-Go, HO-02 Integrated Launch Test	Publish only the authorized subset; hold broken or unresolved routes
Claims boundary	KB-42 Call Claims Pack	Use current permitted factual forms; route unsupported statements rather than improvising

Audience rule: an Atlas recruitment or diligence asset is not automatically a partner-to-customer marketing asset. Record the intended audience, owner, public brand, channel, destination, and approved-use state before adapting or publishing it.

Canonical tailoring and replication path

The source banks and templates are reusable masters. The operator uses the configured partner build, never a hand-edited master or hand-edited prior output.

1. Copy PARTNER_CONFIG_TEMPLATE.json to the configured partner record: PARTNER_BUILDS/[ATLAS CONFIG: PARTNER_SLUG].json.
2. Resolve the required partner/model/brand/area/contact/route/owner fields. Leave any unknown value unresolved and held.
3. Run TOOLS/make_partner.py from the controlled staging workspace.
4. Use only the generated PARTNER_BUILDS/[ATLAS CONFIG: PARTNER_SLUG]/ output.
5. Read PARTNER_BUILDS/[ATLAS CONFIG: PARTNER_SLUG]/BUILD_REPORT.md.
6. Treat unresolved tokens, missing sources, wrong-model skips, broken routes, or failed acceptance checks as held.
7. Correct the partner configuration or source master, then rebuild. Do not patch the generated output as the permanent fix.
8. Record the generated version, config version, source versions, build report, acceptance evidence, and supersession link in the Vault.

CRM merge variables remain CRM-controlled at send time. A successful build does not authorize sending, publishing, printing, or activating an unresolved route.

Campaign control board

Complete one row per included channel. The current live board belongs at [ATLAS CONFIG: CAMPAIGN CONTROL BOARD URL].

Channel ID	Channel	Model/eligibility	Asset/version	Destination	Owner	Source code	State	Test/evidence
CH-01	Website/landing route	Both	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG: DRAFT / READY / ACTIVE / HELD / N/A]	[ATLAS CONFIG]
CH-02	Social organic	Both when account is configured	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
CH-03	Permission-based email	Both when sender, segment, reply, and suppression pass	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
CH-04	Paid placement	Conditional	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
CH-05	Local Business Profile	Eligible real local operation only	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
CH-06	Citations/directories	Eligibility and fact-match required	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
CH-07	Print distribution	Conditional	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
CH-08	Referral or relationship outreach	Conditional written participation route	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
CH-09	Event/community listing	Conditional, verified event only	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
CH-10	Review request	Genuine eligible interaction and approved route only	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]

Route-state vocabulary

State	Meaning	Permitted action
DRAFT	Content or configuration exists but is not ready for external use	Internal review and fictional testing only
READY	Required internal inputs and functional checks are complete; activation decision remains	Await the recorded authorization
ACTIVE	Exact asset/version and destination are authorized and working	Use only within the configured channel, dates, and audience
HELD	A dependency, route, fact, right, account, or test is unresolved	Do not publish, send, print, or distribute
N/A	Channel is not included or does not apply to this model	Omit without renumbering or breaking the remaining campaign
SUPERSEDED	A newer controlled version replaced this one	Stop use and follow the supersession link

First-30-days operating sequence

The Launch Campaign Calendar is the detailed day-by-day source. Configure it; do not copy its changing dates or assignments here.

Before Day 1

• ☐ Record the start event and configured date.
• ☐ Select the exact authorized channel subset.
• ☐ Assign a partner owner, backup, and escalation route for every included channel.
• ☐ Resolve public brand, website, inquiry/booking route, hours, contact facts, model, and area facts from the current source.
• ☐ Confirm rights for every image, logo, layout, audio, video, and third-party element.
• ☐ Bind each CTA to a tested active destination or suppress it.
• ☐ Configure source codes and CRM field mapping.
• ☐ Complete sender, reply, permission, unsubscribe, and suppression tests before external email.
• ☐ Complete local eligibility and account-ownership checks before local-profile or citation work.
• ☐ Record print specifications, proof owner, quantity, payer, delivery, and distribution plan when print is included.
• ☐ Record the rollback, removal, or correction owner for every published route.

Weekly operator cadence

Cadence	Operator action	Completion evidence
Start of week	Review route state, current asset versions, scheduled actions, owner coverage, and new holds	Updated campaign board
Before each publication/send	Confirm exact version, source facts, rights, destination, reply route, audience, and channel state	Preflight record
Daily during an active campaign	Test public destinations; route inquiries to the partner; log broken paths and factual drift	Route-check and exception log
End of week	Reconcile source codes, publication records, corrections, opt-outs, partner responses, print/event activity, and held items	Weekly operations record
Day 7 and Day 30	Review completed actions, open dependencies, asset changes, defects, next owners, and next cadence	HO-06 review record

Source and attribution controls

Every included campaign path receives a stable source code before activation.

Field	Format or rule
Campaign ID	[ATLAS CONFIG: PARTNER CODE]-[ATLAS CONFIG: CAMPAIGN]-[ATLAS CONFIG: VERSION]
Source	One controlled value per channel/source
Medium	One controlled value per delivery method
Asset ID/version	Exact installed creative or message version
Destination ID/version	Exact page, form, booking, or inquiry route
Event code	Required for event, display, or referral pilot
CRM mapping	Source values must survive form-to-pipeline creation
Owner	One accountable partner role
Evidence	Publication URL, send record, print proof, distribution record, or held decision

Attribution fields support operational comparison and troubleshooting. They do not prove that one contact, purchase, or other result was caused by a specific channel unless the configured data and method support that conclusion.

Local eligibility branch

Use the Local SEO / Business Profile Kit as the current source.

Clinic or otherwise eligible real local operation

• Confirm the real public business, location or permitted area treatment, public contact facts, category, hours, ownership, verification state, and live routes.
• Maintain one controlled fact sheet across the website, profile, and approved citations.
• Preserve profile and listing ownership with the partner.
• Record each listing URL, account owner, displayed facts, last check, evidence, issue, and next action.
• Ask for reviews only through the configured genuine-interaction process; never incentivize, fabricate, screen, or write the review for the customer.

Platform or other ineligible configuration

• Do not create a false location, category, listing, or profile.
• Mark local-profile and ineligible citation modules N/A or HELD.
• Use approved digital discovery channels and real public contact facts.
• An online-only business receives a local-profile branch only if current eligibility is independently documented for the exact real operation.

Social and content-bank deployment

The Social Caption Bank contains the source copy. This binder does not copy it.

• ☐ Select caption ID and exact version.
• ☐ Resolve the public-brand token from the current partner facts.
• ☐ Select rights-cleared visual media and record its rights source.
• ☐ Confirm channel, format, scheduled owner, and publication window.
• ☐ Bind the CTA only to an Active destination; otherwise use the configured no-CTA version.
• ☐ Confirm that the copy matches the actual partner audience and current business process.
• ☐ Run link, visual, alt-text, mobile, and token checks.
• ☐ Retain the publication URL or held decision.
• ☐ Route replies to the partner owner; Atlas does not communicate directly with partner customers.

Ad and print deployment

Ad creative

Use the Ad Bank as the current creative source.

• Configure only the scheduled formats and audience.
• Confirm current proposition, destination, route state, media rights, account owner, payer, and platform specifications.
• Retain the exact submitted asset/version and platform response.
• A file does not establish platform approval or campaign performance.

Print materials

Use the flyer and referral card as source files.

• Resolve brand and route tokens.
• Confirm dimensions, bleed, color, paper, finish, quantity, payer, proof, delivery, and distribution owner.
• Generate and test any QR code only after its destination is Active.
• Print the readable destination beside the QR code.
• Record printer proof and approved version before production.
• Atlas supplies configured print-ready files when scheduled; the partner pays for printing unless written terms state otherwise.

Measured pilot card

Use for referral arrangements, displays, events, community channels, or co-branded activity.

Field	Controlled value
Pilot ID	[ATLAS CONFIG]
Channel and participating parties	[ATLAS CONFIG]
Written participation terms location	[ATLAS CONFIG]
Audience and model	[ATLAS CONFIG]
Approved assets/versions	[ATLAS CONFIG]
Active destination and fallback	[ATLAS CONFIG]
Source/event code	[ATLAS CONFIG]
Start and review dates	[ATLAS CONFIG]
Owner and support route	[ATLAS CONFIG]
Costs and payer	[ATLAS CONFIG]
Controllable checks	Placement/use confirmed; route works; source records correctly; materials remain current
Stop conditions	Broken route; expired facts; missing rights/terms; unapproved modification; access loss; unresolved issue
Continue/change/stop decision	[ATLAS CONFIG]

The pilot record documents execution and a review decision. It does not turn a channel into established proof.

Exception routing

Issue	Immediate action	Owner	Recovery evidence
CTA or destination fails	Hold affected asset or replace with configured fallback	[ATLAS CONFIG]	Route retest
Public fact changes	Hold inconsistent assets and update the controlled fact source first	[ATLAS CONFIG]	Cross-channel fact audit
Rights cannot be confirmed	Hold the media or creative	[ATLAS CONFIG]	Rights record or replacement
Channel/account loses access	Hold scheduled activity	[ATLAS CONFIG]	Restored partner control and access review
Email permission/suppression defect	Stop affected commercial sending	[ATLAS CONFIG]	Fictional permission and suppression retest
Print proof is wrong	Do not approve production	[ATLAS CONFIG]	Corrected proof and approval
Profile/listing is ineligible or inaccurate	Stop creation/publication or submit the proper correction route	[ATLAS CONFIG]	Eligibility/fact record and current status
Review process is inconsistent or incentivized	Stop the process	[ATLAS CONFIG]	Corrected genuine-interaction workflow
Partner asset is modified outside control	Hold or supersede it	[ATLAS CONFIG]	Current approved version and change record
Unsupported statement requested	Do not improvise	[ATLAS CONFIG: APPROVED FACT / REVIEW ROUTE]	Current approved response or held state

Print versus live

Print contains: asset family IDs, operator sequence, channel-state vocabulary, eligibility decision path, pilot card, owner roles, escalation routes, and human-readable Vault locations.

Digital Vault contains: exact copy and creative, account and profile URLs, changing public facts, dates, schedules, audiences, media-rights records, source codes, live destinations, send/publication records, print specifications/proofs, review links, costs, channel decisions, and supersession history.

No credential, secret, live customer record, private customer communication, or unpublished personal data appears in the print binder.

Acceptance evidence register

Build Spec ID	Evidence required	Evidence link	Owner	Status	Next action
05-05	Configured caption/template inventory; tokens resolve; scheduled formats render; CTA appears only for an Active route	[ATLAS CONFIG: EVIDENCE URL]	[ATLAS CONFIG]	[ATLAS CONFIG: NOT STARTED / READY FOR REVIEW / ACCEPTED / CONDITIONAL / BLOCKED / N/A]	[ATLAS CONFIG]
05-06	Eligibility decision; partner ownership; current fact sheet; configured description/category/posts/citations/review route; live links tested	[ATLAS CONFIG: EVIDENCE URL]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
05-07	Configured 30-day calendar in which every scheduled row has owner, dependency, current asset, route state, and completion record	[ATLAS CONFIG: EVIDENCE URL]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
05-08	Named ad/print inventory; scheduled sizes render; destinations test; media rights and print preflight are recorded	[ATLAS CONFIG: EVIDENCE URL]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]

Wave 2 acceptance checks

• ☐ Test 2 — branch isolation: the generated partner build contains the selected model's eligible assets and omits wrong-model assets without leakage.
• ☐ Test 3 — coverage: each owned Build Specification line has a binder section, live asset links, owner, status, evidence field, and next action.
• ☐ Test 4 — one-to-one ledger: 05-05 through 05-08 remain this section's only primary Build Specification lines; email/video/replication assets are controlled supporting assets, not new scope by presence alone.
• ☐ Test 5 — live truth: changing vendors, accounts, contacts, dates, public facts, prices, catalogs, evidence, copy, routes, source codes, and external text remain in controlled live records.
• ☐ Test 6 — fallback: every QR or short link in a configured asset has a readable destination and Digital Vault path.
• ☐ Test 7 — safe print: no credential, secret, live customer record, private message, payment detail, or sensitive data appears in print.
• ☐ Test 10 — modularity: local-profile, event, display, referral, paid, print, email, and other optional modules can be N/A or HELD without breaking the Core campaign sequence or numbering.

Operator sign-off

Role	Name	Decision	Date	Open dependency
Partner marketing owner	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Partner administrator	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Atlas project owner	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]

Section 08 — Customer Consultation and Written Decision Playbook

Status: DRAFT-APPLIED SECTION MASTER · STAGING ONLY · NOT A CONFIGURED PARTNER EDITION

Executor: Codex

Control metadata

Field	Controlled value
Owner	[ATLAS CONFIG: PARTNER CONSULTATION OWNER]
Model	Core with Clinic and Platform script branches
Scope state	[ATLAS CONFIG: INCLUDED / CONDITIONAL / EXCLUDED / NOT APPLICABLE]
Version	0.1
Last review	2026-07-24
Prerequisite	Selected model; named partner consultation owner; configured written offer; current approved-facts source; active payment or nonpayment next-step route; configured CRM decision fields; trained staff
Done when	A trained partner user can run the nine-step conversation in the selected model, stay within the approved-facts boundary, deliver the current written offer, record each permitted disposition, complete the correct payment or follow-up handoff, and pass the manager QA rubric in fictional scenarios
Escalation route	[ATLAS CONFIG: PARTNER MANAGER / APPROVED-FACTS ESCALATION ROUTE]
Live-system link	[ATLAS CONFIG: DIGITAL VAULT URL — 05_MARKETING_AND_EDUCATION / CUSTOMER_CONSULTATION]
Human-readable fallback	Digital Vault → 05_MARKETING_AND_EDUCATION → Customer Consultation
Build Specification ownership	05-02, 05-03, 05-04

Purpose and boundary

This playbook gives the partner a repeatable customer conversation that can reach a clear next step without diagnosis, invented facts, hidden pressure, or improvised promises. The partner owns the customer relationship, the conversation, the written offer, the payment decision, the follow-up, and the record.

Atlas provides the configured operating master and may support an Atlas-configured system through the partner. Atlas does not join the conversation, answer the partner's customers, receive customer payments, or become the fallback customer-contact route.

This section is not an offering sheet. It does not establish an available item, service, price, credential, professional relationship, result, or operating area. Those changing facts belong in controlled live records and must be resolved before the corresponding sentence is used.

Current system links

Need	Current source	Operator use
Permitted Atlas business statements	KB-42 Call Claims Pack	Boundary reference only; do not transplant Atlas-to-prospect statements into partner-to-customer copy unless separately approved for that exact use
Partner claims register	EDU-01 Partner Claims Registry	Locate the exact current expression, channel, owner, evidence, status, and review date
Change and approval workflow	EDU-02 Claims Change Workflow	Route a proposed new or changed statement; never broaden an approved expression
Evidence index	EDU-07 Source Library	Find the source record tied to an approved statement
Customer journey and escalation	OPS-02 Journey Map	Preserve partner ownership from conversation through payment, support, or close
CRM stages and decision record	CRM-02 Core Pipeline	Record the disposition, owner, next task, and controlled stage
Minimum-data field boundary	CRM-03 Field Dictionary	Keep the standard record administrative; do not put health narratives into ordinary CRM notes
Consent and suppression	CRM-09 Consent and Suppression	Use follow-up only when the configured purpose, channel, sender, permission, and suppression path allow it
Four consumer email sequences	Consumer Email Bank	Handoff only after the correct CRM state and permission test; use the per-partner rendered version
Twelve short-form scripts	Reel Script Bank	Optional educational follow-up path; publish only the current per-partner rendered version through an active route
Partner tailoring system	Partner Config Template and replication tool	Generate the controlled partner output at PARTNER_BUILDS/<slug>/; never hand-edit a copy of a master

The email and reel banks are controlled source assets, not automatic permission to send, publish, or repeat every statement. The installed per-partner output, route state, claims status, and CRM permissions control use.

Before every consultation

The consultation owner completes this card before taking a real conversation:

Required control	Current reference
Selected model and meeting route	[ATLAS CONFIG: CLINIC / PLATFORM + ROUTE]
Current written-offer ID/version	[ATLAS CONFIG]
Current price and payment source	[ATLAS CONFIG: LIVE REFERENCE — NOT STATIC PRICE]
Included items and exclusions	[ATLAS CONFIG: LIVE OFFER RECORD]
Approved-facts set and review date	[ATLAS CONFIG: CLAIMS REGISTER VIEW]
FAQ and education asset versions	[ATLAS CONFIG: CURRENT PARTNER-BUILD OUTPUT]
Escalation owner and route	[ATLAS CONFIG]
Payment or nonpayment next step	[ATLAS CONFIG]
CRM record owner and decision fields	[ATLAS CONFIG]
Follow-up permission and suppression state	[ATLAS CONFIG]

If the written offer, current price source, approved-facts set, escalation route, or record owner is missing, the affected part of the conversation is held. Staff may listen, document a question at the minimum necessary level, and promise a written follow-up from the partner; they may not fill the gap from memory.

The nine-step system

Step	Purpose	Required record	Stop or escalation condition
1	Open and set purpose	Consultation started; owner; channel; offer version	Wrong recipient, unavailable route, or customer asks for a different purpose
2	Discover goals and constraints	Customer-stated goal, decision factors, timing, decision participants, question list	Diagnosis, medical history, symptoms, or other sensitive narrative enters the conversation
3	Explain configured facts	Exact approved-facts IDs/versions used	Requested statement is absent, expired, broader than approved, or outside staff role
4	Confirm questions and escalations	Answered items and written-follow-up owner	Product, professional, safety, legal, privacy, or unsupported factual question
5	Present the written offer	Offer ID/version delivered; current live price source; inclusions/exclusions acknowledged	Written offer or current price source is unavailable or inconsistent
6	Address objections	Objection category; approved response; unanswered item	Response would require an invented fact, result, discount, deadline, or assurance
7	Record the decision	Yes, not yet, no, or referral/escalation	Decision is ambiguous, coerced, or recorded without customer confirmation
8	Route next step	Payment, follow-up, clean close, or escalation task	Payment route fails; permission is absent; suppression applies
9	Run manager QA	QA score, exception, coach/retrain action	Critical-fail behavior appears

Model-specific quick-run scripts

These scripts are the word-for-word operator run sheets. The detailed controls, redirects, objection cards, and records that follow govern every line.

Platform quick-run script

1. Open: “Thanks for meeting with [ATLAS CONFIG: PUBLIC BRAND NAME] through our online process. I’m [ATLAS CONFIG: CONSULTATION ROLE / FIRST NAME]. We’ll use this time to understand what you are looking for, explain the parts of our current written offer that apply, and identify a next step—if there is one. I won’t diagnose, give medical advice, or guess. Is that a useful way to spend our time?”
2. Discover: “What brought you into this online conversation now? What matters most as you compare options? What timing, budget, digital-access, time-zone, or decision-participant constraints should we account for? What would you need to see in writing to reach a clear yes, not-yet, or no?”
3. Explain: “Based on what you said, the relevant current written fact is: [ATLAS CONFIG: EXACT APPROVED CUSTOMER-FACING FACT]. Digital access does not add an availability or result promise; that written fact is the limit of what I can state.”
4. Clarify: “What questions do you want answered before we review the written offer? If a question belongs with a qualified or otherwise responsible owner, I will record it and route it rather than guess.”
5. Offer: “This is offer [ATLAS CONFIG: OFFER ID / VERSION]. The current total and payment choices appear in this live written record. It includes [ATLAS CONFIG: INCLUSIONS] and excludes [ATLAS CONFIG: EXCLUSIONS]. What is unclear or different from what you expected?”
6. Objection: “That makes sense to raise. Is the main issue fit, price, timing, another decision-maker, online process, or a missing fact? The part I can answer from the current written material is [ATLAS CONFIG: APPROVED FACT / TERM]. Does that resolve it, leave it open for written follow-up, or make this a not-yet/no?”
7. Decision: “Which decision is accurate right now: yes to the exact written offer we reviewed, not yet, no, or a question that must be escalated?”
8. Route: “I’ll record that decision and use the configured partner route. For payment, use only [ATLAS CONFIG: ACTIVE PARTNER PAYMENT ROUTE]; I do not need payment credentials in this conversation. Follow-up is optional and depends on your recorded permission.”
9. Close: “To confirm: your decision is [YES / NOT YET / NO / ESCALATED]; the next owner is [ATLAS CONFIG]; and the next step is [ATLAS CONFIG / NONE]. Is that accurate?”

Core word-for-word conversation

The bracketed fields are controlled prompts, not text to read aloud. Staff use only the branch matching the configured partner edition.

Step 1 — Open and set purpose

Platform script

“Thanks for meeting with [ATLAS CONFIG: PUBLIC BRAND NAME] through our online process. I’m [ATLAS CONFIG: CONSULTATION ROLE / FIRST NAME]. We’ll use this time to understand what you are looking for, explain the parts of our current written offer that apply, and identify the next step—if there is one. I won’t diagnose, give medical advice, or guess at an answer. If a question needs another qualified owner, I’ll record it and route it. Is that a useful way to spend our time?”

Record the customer's yes, requested adjustment, or clean decline. Do not continue a sales conversation after a clean decline.

Step 2 — Discover goals and constraints

Use these questions in order; follow the customer's words without converting them into a diagnosis.

“What brought you into this conversation now?”

“What would you want a business like ours to help you understand or decide?”

“What matters most to you when you compare your options?”

“What has made previous options hard to evaluate or follow through on?”

“Are there timing, schedule, budget, access, or decision-participant constraints we should account for?”

“Who else, if anyone, should review the written details before you decide?”

“What would you need to see in writing to make a clear yes, not-yet, or no decision?”

Boundary redirect

“I want to keep this record focused on the business decision, not collect a health history in this consultation. I can record your question in a limited way and route it through [ATLAS CONFIG: QUALIFIED ESCALATION ROUTE]. For now, may I stay with what you need to evaluate the written offer?”

Do not diagnose, interpret symptoms, recommend a product or course of care, or turn an unsolicited health narrative into an ordinary CRM note. Use the configured restricted-handling process when unexpected sensitive information appears.

Step 3 — Explain only configured, source-supported facts

Open the current approved-facts view. For each point, read or faithfully paraphrase only when the record permits paraphrase for this channel.

“Based on what you said, the relevant part of our current written process is: [ATLAS CONFIG: EXACT APPROVED CUSTOMER-FACING FACT].”

“The current source record for that statement is [ATLAS CONFIG: CUSTOMER-APPROPRIATE SOURCE DESCRIPTION], reviewed on [ATLAS CONFIG: REVIEW DATE].”

“What I can state today is limited to that written description. I won’t extend it into a promise about your result.”

If the requested fact is not present:

“That is not in my current approved answer set. I won’t guess. I can record the exact question and have the responsible partner owner answer it in writing.”

Step 4 — Confirm questions and identify escalations

“Before I show you the written offer, what questions do you want answered first?”

For each question, classify it as:

• approved business/process fact;
• written offer or price;
• operational route;
• payment;
• privacy/data;
• professional or health;
• product, supplier, quality, safety, or performance;
• other unsupported fact.

For an in-boundary question:

“The current written answer is: [ATLAS CONFIG: EXACT APPROVED ANSWER]. I’ll also point you to its place in the written material.”

For an out-of-boundary question:

“That belongs with [ATLAS CONFIG: RESPONSIBLE PARTNER / QUALIFIED EXTERNAL ROLE]. I can’t answer it accurately from this seat. I’ll record the narrow question, the owner, and the written follow-up route.”

Never say “I’m sure,” “typically,” “everyone,” “guaranteed,” or “you should be fine” to bridge an evidence gap.

Step 5 — Present the written offer

Display or provide the exact current offer; do not recreate its price or terms in a note.

“This is offer [ATLAS CONFIG: OFFER ID / VERSION / EFFECTIVE DATE]. The current total and payment choices appear here: [ATLAS CONFIG: LIVE PRICE / PAYMENT LOCATION].”

“It includes [ATLAS CONFIG: EXACT WRITTEN INCLUSIONS].”

“It does not include [ATLAS CONFIG: EXACT WRITTEN EXCLUSIONS].”

“The next operational step is [ATLAS CONFIG: NEXT STEP]. Any dependencies or conditions are shown in the written offer rather than implied verbally.”

“Please take the time you need to read it. What is unclear, missing, or different from what you expected?”

If the customer asks for an unconfigured discount, deadline, guarantee, item, or exception:

“I don’t have authority to create that term verbally. I can record the request for a written yes or no from [ATLAS CONFIG: DECISION OWNER].”

Step 6 — Address objections without pressure

Use the objection cards below. The structure is always: acknowledge, clarify, answer only from current written facts, ask one decision question.

“That makes sense to raise. When you say [CUSTOMER'S WORDS], is the main issue [CLARIFIED ISSUE]?”

“The part I can answer from the current written material is [ATLAS CONFIG: APPROVED FACT / OFFER TERM].”

“Does that resolve this point, leave it open for written follow-up, or make this a not-yet/no for you?”

Do not use artificial deadlines, alleged demand, customer fear, shame, sunk cost, an unapproved concession, or an outcome implication to force movement.

Step 7 — Record yes, not yet, no, or referral/escalation

Yes

“To confirm, you want to proceed with the written offer version we reviewed, subject to the terms shown there. I’ll record a yes and move you to the configured payment or next-step route. Is that accurate?”

Not yet

“That is a valid decision. What specific item needs to change or become clear before you would revisit it? I’ll record that item, the owner, and—only if you want follow-up—the permitted channel and timing.”

No

“Understood. I’ll record a no and close the sales follow-up. Is there an operational question or required record we still need to complete before we close?”

Referral or escalation

“This question belongs with [ATLAS CONFIG: RESPONSIBLE ROLE], so I’m not going to improvise an answer. I’ll record the narrow question and its route. That is an escalation, not a yes.”

Step 8 — Route payment, follow-up, or clean close

Payment handoff

“The payment route is controlled by [ATLAS CONFIG: PARTNER PAYMENT OWNER / PROCESSOR]. I’ll direct you to [ATLAS CONFIG: ACTIVE PAYMENT ROUTE]. Please use only that route. I do not need or want payment credentials in this conversation.”

Confirm that the route is active and displays the same offer ID/version and current amount. If the route fails:

“The configured route is unavailable, so I’m stopping this step rather than taking information another way. I’ll open a partner-owned payment-route issue and provide the tested fallback only if one is currently approved.”

Permission-based follow-up

“Would you like follow-up through [ATLAS CONFIG: CHANNEL] about [ATLAS CONFIG: PURPOSE]? It is optional. If yes, I’ll record the permission and the current wording version; you can opt out through the method provided.”

Choose the applicable installed sequence from the per-partner output:

• welcome/education after the configured qualifying event;
• missed-meeting branch after the configured event;
• nurture after an explicit not-yet plus valid permission;
• reactivation only under the configured eligibility and suppression rules.

Use the Consumer Email Bank as the master reference and the generated PARTNER_BUILDS/<slug>/ output as the partner-use asset. The Reel Script Bank may support general education through an active public route; it is not an individualized answer or substitute for a requested written response.

Clean close

“I’ve recorded your decision and closed the sales next step. Thank you for being direct. If you contact us later, we will evaluate the facts and offer current at that time.”

Step 9 — Manager QA

The manager reviews the call record and, when lawfully recorded and configured, the permitted quality evidence. Never place a recording, transcript, sensitive narrative, or payment data in this binder.

Manager closeout: “The disposition is [YES / NOT YET / NO / ESCALATED]; the offer version is [ATLAS CONFIG]; the next owner is [ATLAS CONFIG]; the next action is [ATLAS CONFIG]; the open fact or exception is [ATLAS CONFIG / NONE].”

Approved-facts boundary card

Staff may

• ask business-decision questions and reflect the customer's own nonclinical words;
• state exact configured business, process, support, contact, price, inclusion, and exclusion facts from the current controlled source;
• show current source-supported educational material assigned to this partner and channel;
• say that an answer is unknown or held;
• route a narrow question to the responsible partner or qualified external role;
• provide the current written offer without adding verbal terms;
• record a customer-confirmed disposition and next step.

Staff must not improvise

• diagnosis, treatment, safety, efficacy, suitability, causation, or expected result;
• product, supplier, purity, testing, inventory, availability, or shipping claims;
• credentials, licenses, professional coverage, geographic availability, or legal classification;
• price, discount, financing, refund, deadline, guarantee, or exception absent from current written terms;
• customer stories, proof, demand, popularity, conversion, or outcome implications;
• a fact copied from a stale email, image, printout, handwritten note, or memory.

Use this exact escalation sentence

“That is outside my current approved answer set. I won’t guess or turn it into a promise. I’ll record the narrow question and route it to [ATLAS CONFIG: RESPONSIBLE ROLE] for a written response.”

Objection cards

Customer objection	Approved response pattern	Ask back
“I need to think about it.”	“Of course. The useful question is what specifically needs thought: fit, price, timing, another decision-maker, or a missing fact? I’ll record the real item and keep the decision as not yet.”	“Which one item would make your review clearer?”
“It costs too much.”	“I hear that. I can show the current written price, inclusions, exclusions, and payment choices; I cannot invent savings or promise a return. If the written amount does not fit, no is an acceptable answer.”	“Is the issue the total, timing, included scope, or uncertainty about what you receive?”
“I need to ask my spouse/partner/adviser.”	“That makes sense. I can give you the same written offer and question list so no one has to rely on a retelling.”	“Would a joint review or a written response to a specific question be more useful?”
“How do I know this will work for me?”	“I cannot promise an individual outcome. I can show only the current source-supported explanation, the written process, and what is and is not included.”	“Which part of the process or evidence would you like to inspect?”
“What makes you different?”	“I can compare only the documented features of our current written offer, not make claims about another business. The relevant documented features are [ATLAS CONFIG: APPROVED DIFFERENTIATORS].”	“Which comparison factor matters most to your decision?”
“Can you give me a discount?”	“I cannot create a verbal discount. The controlling price and any available written choice are in the current offer. I can record a request for the authorized owner.”	“If the written terms stay unchanged, is this a no or a not yet?”
“Can I start today?”	“I can check the configured next-step requirements and route state. I will not promise timing until the current written prerequisites and available path are confirmed.”	“Would you like me to verify the next available written step?”
“What do you recommend?”	“I can help you compare the written business options. I cannot make a health, medical, legal, or financial recommendation.”	“Which decision factors would you like to compare?”
“I saw something different online.”	“Let’s identify the exact page and version. We use the current controlled source; if public information conflicts, I will stop that point and open a correction.”	“Can you share the page or exact statement without sending private information?”
“Just tell me whether I’m a fit.”	“I can explain the current administrative criteria and process. I cannot diagnose suitability or bypass a required professional or written review.”	“Would you like to review the written criteria or route the question?”
“I’m not ready.”	“Understood. I will record not yet or no—your choice. Follow-up is optional and depends on your permission.”	“Should we close this, or is there one specific future condition you want recorded?”
“Send me information.”	“I can send the current approved guide, FAQ, one-sheet, or written offer through the configured partner channel.”	“Which question do you want the material to answer?”

Written-offer shell

The controlling offer is a live, versioned partner record. This shell defines its minimum structure; it is not a price sheet.

Field	Controlled value
Partner public identity	[ATLAS CONFIG]
Offer ID/version/effective date	[ATLAS CONFIG]
Customer name or record ID	[ATLAS CONFIG: RESTRICTED LIVE RECORD — OMIT FROM PRINT]
Selected written option	[ATLAS CONFIG]
Included items	[ATLAS CONFIG: EXACT WRITTEN LIST]
Exclusions	[ATLAS CONFIG: EXACT WRITTEN LIST]
Current total	[ATLAS CONFIG: LIVE PRICE SOURCE]
Payment choices and timing	[ATLAS CONFIG: CURRENT WRITTEN TERMS]
Third-party amounts, if applicable	[ATLAS CONFIG: IDENTIFIED CURRENT SOURCE]
Customer responsibilities	[ATLAS CONFIG]
Partner responsibilities	[ATLAS CONFIG]
External dependencies	[ATLAS CONFIG]
Cancellation/refund/change terms	[ATLAS CONFIG: CURRENT WRITTEN SOURCE]
Next operational step	[ATLAS CONFIG]
Questions/escalation route	[ATLAS CONFIG: PARTNER ROUTE]
Customer acknowledgement/decision	[ATLAS CONFIG: YES / NOT YET / NO / ESCALATED]

Offer control rules:

1. Show the exact version; do not paste price or terms into an email from memory.
2. Identify inclusions and exclusions separately.
3. Separate partner charges, identified third-party charges, and optional items.
4. Do not backdate, silently revise, or overwrite an accepted version.
5. A verbal exception is not a term.
6. Store the customer copy and decision in the restricted partner system, not the binder.

Decision record

Field	Record
Consultation ID/date/channel	[ATLAS CONFIG: RESTRICTED LIVE RECORD]
Partner consultation owner	[ATLAS CONFIG]
Selected model	[ATLAS CONFIG: CLINIC / PLATFORM]
Offer ID/version shown	[ATLAS CONFIG]
Approved-facts IDs used	[ATLAS CONFIG]
Customer's stated decision factors	[ATLAS CONFIG: MINIMUM NECESSARY]
Open questions and owners	[ATLAS CONFIG]
Decision	[ATLAS CONFIG: YES / NOT YET / NO / ESCALATED]
Follow-up permission/purpose/channel/version	[ATLAS CONFIG / NONE]
Payment or next-step route	[ATLAS CONFIG / NONE]
Next action/owner/due field	[ATLAS CONFIG]
Manager QA status	[ATLAS CONFIG]

Do not use free text to store a diagnosis, health history, payment credentials, a secret, a full transcript, or unnecessary sensitive information.

Payment handoff control

• Confirm the customer decision and exact offer version before presenting the route.
• Use only the active partner-controlled payment route.
• Confirm the route displays the same current amount and option.
• Never request a card number, bank number, password, code, or credential in the consultation record.
• Record payment status from the approved processor or partner system, not from a verbal claim.
• A declined, duplicate, disputed, or unavailable payment becomes a partner-owned case.
• Route refund, return, replacement, or chargeback issues through the configured SOP; the consultation owner does not promise a remedy.
• Atlas does not collect the partner customer's payment or decide the customer's remedy unless later written terms expressly establish a different lawful role.

Manager QA rubric

Score each item 2 = complete, 1 = partial/coaching needed, or 0 = absent. Any critical fail makes the overall result FAIL regardless of total.

QA item	Points	Evidence
Purpose and non-diagnostic boundary set	0–2	Record or permitted quality evidence
Discovery covered goals, factors, constraints, and decision participants	0–2	Minimum-necessary notes
No requested-by-default health narrative entered ordinary CRM	0–2	Field and note review
Every factual statement maps to a current approved-facts ID	0–2	Claims IDs/version
Unsupported questions were acknowledged and routed without guessing	0–2	Escalation task
Exact written offer/version, inclusions, exclusions, and current live price source presented	0–2	Delivery and acknowledgement record
Objections handled without pressure or invented concession	0–2	Permitted quality evidence
Customer-confirmed disposition recorded accurately	0–2	Decision record
Payment/follow-up/close route matches permission and suppression state	0–2	CRM/payment task
Next owner, action, due field, and open question are explicit	0–2	CRM task

Passing threshold: [ATLAS CONFIG: QA THRESHOLD] after all critical-fail checks pass.

Critical fails:

• diagnosis, medical advice, product recommendation, or professional judgment by an unauthorized role;
• invented or broadened factual claim;
• outcome, availability, timing, or price promise absent from current written sources;
• manufactured urgency, shame, fear, or hidden pressure;
• unapproved discount, guarantee, refund, or exception;
• payment credential or unnecessary sensitive information captured;
• follow-up sent without the configured permission or despite suppression;
• Atlas assigned direct customer communication;
• Clinic-only language in a Platform consultation or Platform-only route presented as certifying a Clinic.

Daily manager report

Measure	Operational definition
Consultations assigned/completed	Count of configured consultation records by state
Yes / not yet / no / escalated	Customer-confirmed dispositions, not outcome predictions
Open written questions	Count by owner and next-action status
Offer-version exceptions	Record where shown copy did not match current controlled version
Payment-route exceptions	Record where active route did not function as configured
Permission/suppression exceptions	Record where follow-up state was unclear or failed a test
QA reviewed/passed/coached/failed	Count using the current rubric version
Critical-fail incidents	Case IDs and restricted escalation status

These are operational counts for queue control and quality assurance. They do not establish demand, conversion, revenue, attribution, or expected outcomes.

Model branch test

Platform edition must contain

• the Platform opening script;
• only verified remote meeting, time-zone, digital fallback, and online support-window facts;
• a partner Platform payment/next-step route;
• no walk-in, front-desk, parking, physical waiting-room, or facility-arrival assumption.

Removing either unselected branch must leave all nine Core steps, objection handling, offer control, recordkeeping, payment handoff, follow-up, escalation, and QA intact.

Build Specification acceptance evidence

Build Spec ID	Primary evidence	Owner	State	Acceptance evidence	Next action
05-02	Current partner-use FAQ maps every answer to configured facts and active routes; held questions identify an owner	[ATLAS CONFIG]	[ATLAS CONFIG: NOT STARTED / READY FOR REVIEW / ACCEPTED / CONDITIONAL / BLOCKED / N/A]	[ATLAS CONFIG: DIGITAL VAULT EVIDENCE]	[ATLAS CONFIG]
05-03	Current education guide passes copy/source review, visual QA, link check, and scheduled print preflight	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG: DIGITAL VAULT EVIDENCE]	[ATLAS CONFIG]
05-04	Each scheduled one-sheet maps to the configured topic, source, status, CTA, format, and print evidence	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG: DIGITAL VAULT EVIDENCE]	[ATLAS CONFIG]

Section 08 references journey, CRM, training, and payment systems operationally but is the primary coverage home only for 05-02, 05-03, and 05-04.

Wave 3 acceptance checks

• ☐ Test 2 — model isolation: the Clinic fixture uses the Clinic script and configured physical facts only; the Platform fixture uses the Platform script and contains no physical-location assumption.
• ☐ Test 3 — coverage: each of 05-02, 05-03, and 05-04 links to the current asset, owner, state, acceptance evidence, and next action.
• ☐ Test 4 — one-to-one ledger: these three IDs occur as Section 08 primary assignments only; operational cross-references are not relabeled as ownership.
• ☐ Test 5 — live truth: changing offers, prices, facts, sources, routes, permissions, records, and installed follow-up assets remain in controlled live records.
• ☐ Test 10 — modularity: either model branch can be omitted without breaking the nine-step Core, written offer, decision record, payment/follow-up handoff, or manager QA.

Operator sign-off

Role	Name	Decision	Date	Open dependency
Partner consultation owner	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Partner manager / QA owner	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Partner CRM/payment owner	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Atlas project owner	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]

Section 09 — Operations and Customer Experience

Status: DRAFT-APPLIED SECTION MASTER · STAGING ONLY · NOT A CONFIGURED PARTNER EDITION

Executor: Codex

Control metadata

Field	Controlled value
Owner	[ATLAS CONFIG: PARTNER OPERATIONS OWNER]
Model	Core with Clinic and Platform workflow branches
Scope state	[ATLAS CONFIG: INCLUDED / CONDITIONAL / EXCLUDED / NOT APPLICABLE]
Version	0.1
Last review	2026-07-24
Prerequisite	Selected model; configured responsibility map; named customer-support, system, vendor, privacy, incident, and decision owners; selected SOP pack; active partner-controlled records and escalation routes
Done when	Every included customer-journey state and core SOP has one accountable owner, trigger, record, ordered procedure, exception route, service target or visible hold, and passing fictional scenario; daily, weekly, and monthly reviews produce an owned next-action list; Atlas is absent from direct customer communication
Escalation route	[ATLAS CONFIG: PARTNER OPERATIONS / EXECUTIVE ESCALATION ROUTE]
Live-system link	[ATLAS CONFIG: DIGITAL VAULT URL — 06_OPERATIONS_AND_ORDERING / CURRENT_OPERATIONS]
Human-readable fallback	Digital Vault → 06_OPERATIONS_AND_ORDERING → Current Operations
Build Specification ownership	06-01, 06-02, 06-05, 06-08

Purpose and operating boundary

This section turns the configured responsibility map, customer journey, SOP pack, and issue routes into the partner's daily operating rhythm. It is a control index, not a substitute for the current configured SOPs or live case records.

Customer relationship rule: the partner owns and serves its customers. Atlas may configure workflows, templates, tests, and Atlas-controlled systems through the partner, but Atlas does not directly contact the partner's customers. Atlas is not the informal fallback when a partner employee, vendor, route, or system is unavailable.

Any later exception to that boundary requires a lawful written role, separately approved scope, appropriate access, a revised responsibility map, and a configured customer-communication route. An informal request, forwarded message, shared inbox, or binder note does not create the exception.

Current operating-system links

Operating need	Current source	Operator use
Responsibility assignments	OPS-01 Operating Responsibility Map	Configure one accountable owner, responsible performer, customer communicator, record, handoff, and backup for every included step
Journey and escalation	OPS-02 Customer Journey and Escalation Map	Run normal and exception states from discovery through relationship close
Vendor and technology dependencies	OPS-03 Vendor and Technology Register	Locate current owner, agreement, renewal, escalation, continuity, and evidence references
Account and recovery ownership	OPS-04 Account and Credential Inventory	Find account and recovery roles without storing a secret in the binder
Core procedures	OPS-05 Twelve-SOP Master Pack	Select and configure the written procedures; selection alone does not make a procedure runnable
Platform workflow differences	OPS-07 Platform Workflow Addendum	Include only in a Platform edition
Export, continuity, and offboarding	OPS-08 Continuity and Offboarding	Preserve partner control, exports, recovery, incident history, and access-removal evidence
Lead, phone, booking, and follow-up	Section 06	Operate inquiry, booking, messaging, permission, suppression, and fallback queues
Consultation and decision	Section 08	Run the customer conversation, written offer, decision record, and manager QA
Ordering lifecycle	Ordering Lifecycle Workflow	Use only for configured ordering paths; Section 10 controls the binder's ordering and payment module
Support and issue intake	HO-05 Support Guide and Issue Form	Separate included defects, external dependencies, customer issues, and change requests

Responsibility rules

1. Exactly one accountable owner is named for each included workflow step.
2. The partner names the customer-facing communicator for every normal and exception state.
3. Atlas is not assigned as customer-facing communicator, refund issuer, product investigator, professional, clinician, employer, manager, or ongoing operator.
4. A vendor, adviser, or qualified external role appears only after its actual role, relationship, route, and current evidence are recorded.
5. A selected but unresolved procedure remains HELD or CONTROLLED TEST ONLY.
6. Every live step identifies its trigger, prerequisites, ordered actions, system of record, evidence, service target, fallback, escalation, stop condition, and revision trigger.
7. A changing owner, route, time, vendor, policy, account, catalog, price, or external statement stays in the Digital Vault—not copied into print.
8. No password, key, token, recovery code, payment credential, customer record, sensitive narrative, or private case detail appears in this binder.

Daily operating rhythm

Run at [ATLAS CONFIG: DAILY REVIEW TIMES]. Use the current live-system queues and record only issue IDs or operational counts in the binder-facing summary.

Opening control

• ☐ Confirm the partner operations owner and customer-support coverage for the current operating window.
• ☐ Confirm primary inquiry, phone, booking, payment, ordering, and support route states.
• ☐ Confirm every held or failed route shows the tested partner-controlled fallback—or remains held.
• ☐ Review access, incident, outage, vendor, and external-dependency alerts.
• ☐ Confirm the selected model and real public facts have not changed.
• ☐ Confirm current offer, approved-facts, catalog, and policy versions where those modules are active.
• ☐ Assign one owner and next action to every overnight exception.

Queue control

Queue	Operator check	Required output
New inquiry	One record, source, owner, task, permitted response, and no false confirmation	Owned inquiry or exception
Booking	Correct time zone, model destination, owner, reminder state, reschedule/cancel/no-show branch	Current event and task
Consultation	Offer version, disposition, open written question, QA state, next owner	Decision or escalation record
Customer onboarding	Only configured required information; owner; missing items; approved next step	Ready, conditional, declined, or blocked
Payment	Current processor status; duplicate/decline/dispute exception; no credentials in notes	Payment status or partner-owned case
Order/fulfillment	Current authorized order state, owner, supplier/vendor reference, exception task	Order status or held case
Customer support	Category, acknowledgement, owner, next update, external reference, closure status	Case record
Complaint/refund	Preserve facts; separate routine, payment, vendor, product/professional, safety, and privacy routes	Restricted or ordinary case as configured
Permission/suppression	Opt-outs, replies, hard failures, and manual do-not-contact actions honored	Updated suppression state
System/access	Failed automation, access change, suspected exposure, outage, recovery, or broken route	Incident/task and retest owner

Mid-window control

• ☐ Unowned cases are zero or are visibly blocked with an executive owner.
• ☐ Due internal service targets have an action, not a silent overdue state.
• ☐ Customer-facing updates are sent only by the partner through an approved channel.
• ☐ Staff use current approved information and do not improvise a product, professional, safety, availability, timing, refund, or outcome answer.
• ☐ Vendor cases show a reference, next-update field, and partner communication owner.
• ☐ Any public fact or route inconsistency is held and sent through change control.

Closing control

• ☐ Every open record has a state, one owner, next action, and due field.
• ☐ Every closed case has closure evidence and the correct retention/access location.
• ☐ Fallback records created during an outage are reconciled without duplicates.
• ☐ Held routes remain visibly held until their recovery tests pass.
• ☐ Customer communications and private records remain in partner-controlled systems.
• ☐ Tomorrow's coverage, external dependencies, and escalation owner are clear.
• ☐ The daily exception summary contains no secrets or unnecessary customer details.

Weekly operating review

Run on [ATLAS CONFIG: WEEKLY REVIEW DAY / TIME].

Review block	Questions	Output
Journey health	Which configured states were used? Where did records stop, duplicate, or lose ownership?	Journey exceptions and owners
Inquiry and booking	Did source, ownership, task, time zone, reminder, reschedule, cancellation, no-show, and fallback paths work?	Route-test and correction list
Consultation quality	Were current facts and written offers used? Were unsupported questions escalated?	QA/coaching list
Customer support	Which issue categories repeated? Which lacked a current answer, route, or owner?	Pattern and root-cause queue
Complaints/refunds	Did each issue reach the authorized decision party and correct record?	Exception-case audit
Ordering/payment	Did order, payment, supplier, status, inventory, and fulfillment states reconcile where active?	Reconciliation and held-item list
Vendor dependencies	Which cases, outages, renewals, agreement terms, or external decisions need action?	Vendor dependency list
Claims/public facts	Did staff or public assets use stale, broadened, or unsupported statements?	Hold/correction/change record
Data/access	Did permissions, suppression, minimum-data, user-access, recovery, and incident controls work?	Restricted action list
Training	Which role or task needs coaching, retest, or access restriction?	Training task and verification
Change control	Is an issue a defect, dependency, routine operation, or requested expansion?	Correctly classified work item

Weekly counts are operational quality and workload records. They do not establish demand, revenue, conversion, attribution, or expected outcomes.

Monthly operating review

Run on [ATLAS CONFIG: MONTHLY REVIEW DAY / TIME].

1. Review the responsibility map for owner, backup, customer-communicator, vendor, adviser, and escalation changes.
2. Review selected SOPs, runnable state, last test, open gate, revision trigger, and next test.
3. Review the customer journey for unused, missing, duplicated, or unowned states.
4. Review complaint/refund routing against current written partner, payment, supplier, vendor, and adviser records.
5. Review current approved-facts, FAQ, education, offer, public fact, and source records.
6. Review vendor/account ownership, administrator access, payer, renewal, recovery, continuity, export, and removal evidence.
7. Review privacy, permission, suppression, restricted-record, incident, retention, and access decisions through the named responsible owner.
8. Review role training, task verification, coaching, access, coverage, and offboarding changes.
9. Review open defects, external dependencies, scope requests, accepted deliverables, and stabilization items.
10. Open a written Build Specification change request for any added work; do not convert recurring operation into Atlas scope through an informal request.

Core SOP pack index

The OPS-05 master is the current source. This table is an index only; it does not reproduce the procedure or clear its gates.

SOP	Procedure	Core status	Primary owner	Required live record	Use / hold rule
SOP-01	New inquiry receipt and response	Core working default	[ATLAS CONFIG: CUSTOMER-SUPPORT OWNER]	CRM inquiry/task	Controlled test until owner, route, fallback, and record-creation test pass
SOP-02	Booking, rescheduling, cancellation, and no-show	Core working default	[ATLAS CONFIG: CUSTOMER-SUPPORT OWNER]	Calendar/CRM event	Held until account, time zone, hours, owner, fallback, and branch tests pass
SOP-03	Customer onboarding and required information	Core working default	[ATLAS CONFIG: ONBOARDING OWNER]	Partner-approved onboarding record	Held until the minimum-information checklist, owner, notice, and storage route are configured
SOP-04	Customer-service request intake and escalation	Core working default	[ATLAS CONFIG: CUSTOMER-SUPPORT OWNER]	Support case	Controlled test until issue classes, owners, response set, and external routes exist
SOP-05	Order submission and status documentation	Conditional	[ATLAS CONFIG: ORDER OWNER]	Order ledger / portal	Held until current item, seller, supplier, payment, data, inventory/direct route, and account are configured
SOP-06	Fulfillment exception and delayed-order communication	Conditional	[ATLAS CONFIG: FULFILLMENT OWNER]	Vendor case + partner task	Held until authoritative status, vendor route, issue ownership, and customer message route exist
SOP-07	Refund, return, replacement, and chargeback routing	Conditional	[ATLAS CONFIG: PAYMENT / POLICY OWNER]	Case/payment/vendor record	Held until current partner policy, seller/payment roles, external terms, criteria, and accounting route exist
SOP-08	Product complaint and safety/adverse-event escalation	Conditional restricted route	[ATLAS CONFIG: PARTNER INCIDENT OWNER]	Restricted issue record	Held until supplier, qualified role, reporting, emergency, insurance, and notice routes are established
SOP-09	Content, claims, and public-information change approval	Core working default	[ATLAS CONFIG: CLAIMS / FACT OWNER]	Claims register and asset version	Controlled test until fact and claims owners, current source, and publication record exist
SOP-10	Account access, role change, and credential recovery	Core working default	[ATLAS CONFIG: PARTNER ADMINISTRATOR]	Access inventory / incident record	Controlled test until authorization, recovery, removal, and partner-admin tests pass
SOP-11	Privacy/data request routing and record handling	Conditional core control	[ATLAS CONFIG: PRIVACY / DATA OWNER]	Restricted request/incident record	Held until current policy, responsible owner, restricted route, and adviser decisions exist
SOP-12	Incident, outage, continuity, export, and offboarding	Core working default	[ATLAS CONFIG: INCIDENT / CONTINUITY OWNER]	Incident/export/offboarding record	Controlled test until fallback, recovery, export, partner-control, and access-removal routes pass

SOP selection rule

• Select only procedures included in the signed Build Specification or a written change.
• Record the runnable state separately from selection.
• Use the current configured partner instance; do not operate from this index.
• Ordering, supplier, payment, product, professional, privacy, and external-policy dependencies remain held until their exact prerequisites are recorded and tested.
• An optional SOP can be omitted without renumbering or breaking the remaining operating flow.

Customer journey control

Use the current OPS-02 journey map. Every active state records:

• entry trigger;
• customer-facing partner owner;
• standard action;
• system of record;
• normal exit;
• exception route;
• gate/status;
• next owner and next action.

The Core path is:

Discovery → Inquiry → Booking → Administrative onboarding → Written decision → Payment → Order/service coordination → Support → Complaint/refund route when needed → Relationship close

An unavailable or excluded module uses its documented safe path. It is not silently skipped, simulated with a false success, or assigned to Atlas.

Complaint, refund, and escalation routing

Intake rule

The partner acknowledges the customer through the configured partner channel. Staff capture only the minimum necessary facts and do not diagnose, decide causation, promise a remedy, admit liability, or quote an unverified external policy.

Minimum ordinary case record:

Field	Controlled value
Case ID/date/source	[ATLAS CONFIG: LIVE CASE]
Issue category	[ATLAS CONFIG: ROUTINE / BOOKING / PAYMENT / FULFILLMENT / REFUND / PRIVACY / PRODUCT-PROFESSIONAL-SAFETY / SYSTEM / OTHER]
Accountable partner owner	[ATLAS CONFIG]
Customer-facing partner owner	[ATLAS CONFIG]
Affected order/payment/service/system ID	[ATLAS CONFIG: MINIMUM NECESSARY]
Current policy or external-term reference	[ATLAS CONFIG: LIVE SOURCE]
Sensitive/restricted flag	[ATLAS CONFIG: YES / NO]
External case/reference	[ATLAS CONFIG / NONE]
Next action/owner/update field	[ATLAS CONFIG]
Decision authority	[ATLAS CONFIG]
Closure/disposition	[ATLAS CONFIG]

Classification and route

Level	Issue	Immediate action	Decision / substance owner	Customer communicator	Atlas role
L0	Routine question within current approved process	Resolve from current source and record closure	Partner	Partner	None
L1	Booking, system, ordinary payment, or operational exception	Preserve case, use tested fallback, assign owner, retest system	Partner/system/payment owner	Partner	Support Atlas-configured system through partner when included
L2	Vendor, platform, fulfillment, external-contract, damage, short, delay, or status issue	Open external case; preserve authoritative status; set next update	Named vendor plus partner decision owner	Partner	No promise of vendor performance, timing, replacement, or result
L3	Privacy, data, credential, access, or security issue	Restrict access; preserve minimum evidence; route immediately	Named partner owner/adviser	Partner or authorized party	Atlas acts only on Atlas-controlled access or system tasks
L4	Product complaint, professional question, safety concern, or reported adverse event	Do not assess; use restricted route; preserve configured identifiers; escalate	Named supplier/qualified role/partner incident owner	Partner or authorized responsible party	No diagnosis, causation judgment, care direction, investigation, or customer response
L5	Unresolved high-impact or continuity decision	Pause affected route; executive decision; record rollback/recovery	Partner decision-maker	Partner	Provide Atlas-controlled evidence and in-scope system action only

Refund and dispute rule

1. Record the customer's request and referenced transaction without collecting payment credentials.
2. Identify the current written partner policy, seller/payment role, supplier/vendor terms, and authorized decision owner.
3. Keep ordinary payment disputes, vendor fulfillment issues, product complaints, safety/professional reports, and privacy incidents in their distinct routes.
4. The authorized party decides the remedy.
5. The partner communicates the decision to its customer.
6. Record funds/item status, external reference, next update, and closure evidence.
7. If the necessary policy, role, or external term is unresolved, mark the remedy decision HELD; do not invent one.

Atlas does not become the refund issuer, product investigator, payment decision-maker, or customer communicator unless later final written terms expressly establish that role.

No-Atlas-contact control

Required system design

• Public phone, email, chat, form, booking, payment, order, and support routes terminate with the partner or its configured responsible external route.
• Sender and reply identities are partner-controlled.
• CRM, case, booking, and support ownership never defaults to an Atlas user.
• Fallback recipients are partner roles.
• Customer-facing templates identify the partner.
• Atlas support routes accept partner staff cases, not customer requests.
• Access is least privilege; Atlas access is removed at the recorded handoff or support-end trigger.

If a partner customer contacts Atlas

1. Do not answer the substantive customer question.
2. Do not request more customer information.
3. Do not accept payment, an order, a complaint decision, a health narrative, or a promise to resolve.
4. Provide only the configured neutral partner route when it is safe and current.
5. Notify the partner through the internal configured route using the minimum necessary information.
6. Record the misroute as an operational issue without copying unnecessary sensitive content.
7. Correct the source route and run a fictional retest.

Neutral response:

“This channel supports the partner business, not its customers. Please use [ATLAS CONFIG: CURRENT PARTNER CUSTOMER-SUPPORT ROUTE]. I cannot address the substance of your request here.”

If the partner route is unavailable, Atlas does not invent a replacement; the issue escalates to the partner operations owner while the affected public route remains held.

Model branches

Platform edition

• Use verified remote workspace, time zone, service window, digital meeting, fallback, geography decision, support, account, and continuity records.
• Do not render walk-in, front desk, waiting room, parking, public Clinic address, signage, receiving-counter, or on-site arrival assumptions.
• Digital availability does not imply unrestricted operating geography, service, product, professional, payment, supplier, or fulfillment availability.
• The partner's digital support owner communicates with customers; Atlas remains an internal system-support route through the partner.

Removing the unselected branch must leave the Core journey, operating rhythm, SOP index, complaint route, no-Atlas-contact rule, exception records, and acceptance evidence intact.

Operational dashboard boundary

The operational dashboard is referenced as a live system at [ATLAS CONFIG: OPERATIONAL DASHBOARD URL]. This section describes how the partner uses its queues and counts; it does not own Build Specification line 04-07, which remains assigned to Section 15 in the approved one-to-one ledger.

Minimum configured views may include:

• unowned or overdue internal tasks;
• inquiry/booking route exceptions;
• open customer-support cases by class and owner;
• complaint/refund routes by status;
• payment/order/fulfillment exceptions where active;
• held external dependencies;
• permission/suppression exceptions;
• access/incident items;
• SOP test and revision status;
• training/QA tasks.

Definitions, sources, access, filters, refresh state, completeness limits, and fictional test evidence remain in the live dashboard record. A dashboard count does not establish revenue, forecast, demand, conversion, attribution, or data completeness.

Build Specification acceptance evidence

Build Spec ID	Primary evidence	Owner	State	Acceptance evidence	Next action
06-01	Configured responsibility map gives every critical step one accountable owner, customer communicator, system/record, handoff, backup, and open-dependency action	[ATLAS CONFIG]	[ATLAS CONFIG: NOT STARTED / READY FOR REVIEW / ACCEPTED / CONDITIONAL / BLOCKED / N/A]	[ATLAS CONFIG: DIGITAL VAULT EVIDENCE]	[ATLAS CONFIG]
06-02	Normal and exception journey scenarios produce the correct partner owner, record, escalation, next action, and no Atlas-to-customer communication	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG: DIGITAL VAULT EVIDENCE]	[ATLAS CONFIG]
06-05	Each selected SOP includes owner, trigger, prerequisites, ordered steps, record, target/hold, fallback, escalation, stop condition, acceptance scenario, and current runnable state	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG: DIGITAL VAULT EVIDENCE]	[ATLAS CONFIG]
06-08	Fictional routine, payment, vendor, privacy, product/professional/safety, and continuity issues reach the correct owner, record, customer communicator, and controlled state	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG: DIGITAL VAULT EVIDENCE]	[ATLAS CONFIG]

Section 09 references CRM, dashboard, ordering, consultation, training, activation, and continuity systems operationally but is the primary coverage home only for 06-01, 06-02, 06-05, and 06-08.

Scenario tests

1. A valid inquiry creates one partner-owned record, task, and permitted response.
2. A booking route fails; the broken route is held, a tested partner fallback is used when available, and Atlas is not the recipient.
3. A customer asks an unsupported question; staff stop, record the narrow question, and route it without improvising.
4. A consultation reaches yes; the exact written offer routes to the active partner payment step without credentials entering the record.
5. A customer chooses not yet; optional follow-up occurs only through a permitted, unsuppressed partner channel.
6. A routine support case closes from a current approved source.
7. A refund request reaches the authorized partner/payment owner; Atlas does not decide or communicate the remedy.
8. A vendor delay creates an external case and partner communication task without a promised date.
9. A reported product/professional/safety issue enters the restricted configured route with no diagnosis or causation judgment.
10. A privacy/access issue remains restricted and reaches the named responsible owner.
11. A partner customer contacts Atlas; Atlas uses only the neutral redirect and corrects the misroute through the partner.
12. A selected conditional SOP has an open prerequisite; the procedure remains held and cannot be marked runnable.
13. A Clinic fixture uses Clinic workflow facts and contains no Platform-only assumption.
14. A Platform fixture uses Platform workflow facts and contains no Clinic-only assumption.
15. An optional SOP is omitted; numbering, Core journey, complaint route, and escalation flow remain intact.

Wave 3 acceptance checks

• ☐ Test 2 — model isolation: Clinic and Platform fixtures use only their selected workflow branch; neither branch certifies the other model.
• ☐ Test 3 — coverage: each of 06-01, 06-02, 06-05, and 06-08 links to the current asset, owner, state, acceptance evidence, and next action.
• ☐ Test 4 — one-to-one ledger: these four IDs occur as Section 09 primary assignments only; dashboard and other system references remain non-primary.
• ☐ Test 5 — live truth: changing staff, routes, targets, vendors, policies, accounts, cases, catalogs, prices, external terms, and records stay in controlled live systems.
• ☐ Test 10 — modularity: either model branch and any excluded optional SOP can be omitted without breaking the Core rhythm, journey, complaint route, or no-Atlas-contact control.

Operator sign-off

Role	Name	Decision	Date	Open dependency
Partner operations owner	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Partner customer-support owner	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Partner incident/privacy owner	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Partner decision-maker	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Atlas project owner	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]

Section 10 — Ordering, Payments, Inventory, and Fulfillment

Status: DRAFT-APPLIED SECTION MASTER · STAGING ONLY · NOT A CONFIGURED PARTNER EDITION

Executor: Codex

Control metadata

Field	Controlled value
Owner	[ATLAS CONFIG: PARTNER ORDERING / FINANCE OWNER]
Model	Core — Clinic and Platform
Scope state	[ATLAS CONFIG: INCLUDED / CONDITIONAL / EXCLUDED / NOT APPLICABLE]
Version	0.1
Last review	2026-07-24
Prerequisite	Signed Build Specification; selected model; verified supplier terms; controlled live catalog; configured payment and data decisions; named partner users; documented review, support, and exception owners
Done when	Authorized users can access and recover the configured portal; one fictional order completes every included normal state; payment, review, supplier, tracking, receiving, exception, reorder, reconciliation, and offboarding routes either pass or retain an explicit blocker, fallback, owner, and next action
Escalation route	[ATLAS CONFIG: ORDERING / PAYMENT / FULFILLMENT ESCALATION ROUTE]
Live-system link	[ATLAS CONFIG: DIGITAL VAULT URL — 06_OPERATIONS_AND_ORDERING / PARTNER_ORDERING_INSTANCE]
Human-readable fallback	Digital Vault → 06_OPERATIONS_AND_ORDERING → Partner Ordering Instance
Build Specification ownership	06-06, 06-07

Purpose and operating boundary

This section is the operator's map from authorized access through order closeout. It links the partner to the configured ordering instance and its controlled records; it is not a catalog, price list, supplier agreement, payment instruction, product guide, or promise about availability, acceptance, shipment, replacement, timing, or continuity.

The configured operating record must distinguish:

• what Atlas has built or configured;
• what the partner owns and must operate;
• what a payment processor, supplier, carrier, or other external party controls;
• what remains Conditional or Blocked; and
• who communicates with the partner's customer.

The partner remains the customer-facing seller and communication owner. Atlas does not contact the partner's customers directly, and the Atlas ordering layer must not receive partner-customer data.

Current system links

Operating need	Current source	Operator use
Portal deployment, modes, and activation dependencies	Ordering-system deploy guide	Identify the exact configured environment; do not treat a demonstration or staging environment as production
Order-state and money-path configuration	Order lifecycle and operations specification	Configure owners, triggers, states, notices, time windows, and payment route from verified current terms
Supplier requirements and integration decisions	Supplier integration specification	Resolve transmission, acknowledgment, catalog, fulfillment, tracking, inventory, issue, and continuity inputs
Catalog field structure	Product catalog template	Use as a schema only; the configured live catalog is the source of current items, status, and commercial fields
Demonstration entry route	Portal demonstration entry	Use only for the recorded nonproduction exercise unless a different configured production URL is documented
Partner portal application	Portal application source	Reference the delivered application build; operators use the configured live-system link above
Responsibility assignment	OPS-01 Operating Responsibility Map	Name one accountable owner at every partner, Atlas, processor, supplier, and carrier handoff
Vendor and external-term records	OPS-03 Vendor and Technology Register	Keep changing vendor, support, payer, renewal, contract, export, and continuity facts in the live register
Account access and recovery	OPS-04 Account and Credential Inventory	Record owners, roles, recovery, billing, and removal without recording a secret
Core operating and exception SOPs	OPS-05 Core SOP Pack	Configure only the order, issue, refund, complaint, and escalation paths included in signed scope
Data, continuity, export, and offboarding	OPS-08 Continuity and Offboarding	Record exports, limitations, recovery, access removal, and partner control
Ordering training and objective verification	TR-01 Role-Based Training Plan and TR-10 Objective Task Verification	Assign users and verify observable tasks with fictional records
Claims boundary	KB-42 Call Claims Pack	Do not improvise supplier, item, price, availability, quality, shipping, or outcome statements

Do not use a local credential note, environment file, source-code secret, or administrator key as a binder link. Authorized credentials belong only in the approved password manager and configured account-recovery process.

Source-of-truth rule — no static prices

This binder never reproduces an item list, price, discount, margin, minimum, shipping charge, tax rule, payment term, availability statement, or supplier commercial term.

Before an order is allowed:

1. the operator opens [ATLAS CONFIG: CONTROLLED LIVE CATALOG URL];
2. confirms the catalog owner and current effective date;
3. confirms the exact partner-access state;
4. confirms the order route and payment state;
5. checks the applicable change record; and
6. stops if the catalog or required external record is missing, expired, inconsistent, or held.

Live catalog control	Controlled value
Catalog ID/version	[ATLAS CONFIG]
Effective date/time zone	[ATLAS CONFIG]
Catalog owner	[ATLAS CONFIG]
Last verified	[ATLAS CONFIG]
Partner audience/access group	[ATLAS CONFIG]
Current state	[ATLAS CONFIG: DRAFT / READY / ACTIVE / HELD / SUPERSEDED]
Supersession/change record	[ATLAS CONFIG]
Next review trigger	Supplier notice, commercial-term change, item-status change, evidence change, system release, incident, or scheduled review

If the live catalog and a printed, downloaded, cached, emailed, or remembered value conflict, the operator stops and uses the controlled live record after the discrepancy is resolved. A catalog record identifies what may be ordered through the configured business process; it does not create a public claim.

Activation gate board

Every row must be READY, CONDITIONAL, BLOCKED, N/A, or SUPERSEDED. A blank field is not Ready.

Gate	Ready evidence	Current status	Owner	Blocker / next action
Signed scope includes ordering	Matching Build Specification ID/version	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Supplier terms verified	Current agreement/decision record and named owner	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Controlled live catalog active	Catalog ID, effective date, owner, and change record	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Payment route configured	Test-mode result, settlement owner, dispute route, and reconciliation record	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Partner users authorized	Unique users, roles, least privilege, recovery, and removal route	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Data path approved	Required fields, purpose, access, retention, export, and deletion decisions	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Supplier transmission route configured	Method, acknowledgment, failure route, and responsible owner	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Tracking/receipt route configured	Status source, partner notice, receiving record, and exception trigger	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Issue and remedy terms configured	Damage, shortage, delay, rejection, replacement, complaint, and refund owners/routes	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Fictional end-to-end test passed	Evidence for normal, failure, recovery, and access-removal scenarios	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]

Module router

Module	Operator record	Required decision	Done when
Access request	[ATLAS CONFIG: ACCESS REQUEST URL]	Who may request, approve, provision, change, recover, and remove access	A fictional user completes request, approval, least-privilege grant, recovery, and removal
Catalog	[ATLAS CONFIG: LIVE CATALOG URL]	Current catalog/version, owner, effective date, eligible audience, and hold state	An authorized user locates the current record and a superseded value cannot be used
Order submission	[ATLAS CONFIG: PARTNER PORTAL URL]	Required business/order fields, acknowledgments, submit authority, and failure path	A fictional authorized order is created once with traceable ID and correct initial state
Payment	[ATLAS CONFIG: PAYMENT SYSTEM RECORD URL]	Configured pay-at-submission or other written branch, processor owner, settlement, failure, dispute, and refund route	Test-mode authorization, failure, duplicate prevention, and reconciliation paths are recorded
Atlas review	[ATLAS CONFIG: REVIEW QUEUE URL]	Reviewer, review criteria, hold/reject reason, evidence, and escalation	A fictional order can be approved, held, and rejected with correct owner and notice
Supplier route	[ATLAS CONFIG: SUPPLIER TRANSMISSION RECORD URL]	Transmission method, acknowledgment, failure response, external owner, and retry/hold rule	Transmission simulation produces acknowledgment or a traceable failure/hold
Status and tracking	[ATLAS CONFIG: ORDER STATUS URL]	Status source, update owner, notification route, tracking source, and stale-status escalation	Fictional status/tracking updates reach the partner record without customer data
Receiving	[ATLAS CONFIG: RECEIVING LOG URL]	Recipient, count/condition check, time window, discrepancy record, and escalation	A fictional receipt closes normally and a discrepancy opens the correct exception
Stock/inventory	[ATLAS CONFIG: INVENTORY RECORD URL]	Whether stock ordering is included; locations, counts, custody, adjustments, and review cadence	Included stock can be received, counted, adjusted, and reconciled by a named owner
Reorder	[ATLAS CONFIG: REORDER RECORD URL]	Trigger, review cadence, authorization, catalog check, and hold condition	A fictional reorder starts only from the current catalog and documented decision
Exceptions	[ATLAS CONFIG: ORDER EXCEPTION QUEUE URL]	Issue types, priority, evidence, partner/customer communicator, vendor route, and remedy authority	Every included scenario routes to one owner and one next action
Settlement/reconciliation	[ATLAS CONFIG: RECONCILIATION RECORD URL]	Payment, processor, order, supplier, adjustment, refund, and closeout matching	A fictional period reconciles or every variance is assigned and tracked
Change log	[ATLAS CONFIG: CATALOG / SYSTEM CHANGE LOG URL]	Change owner, effective date, affected records/users, notice route, test, and supersession	An old version is retired and users can identify the current version

Optional modules may be N/A without breaking order numbering or the Core path. A held module stays visible with its blocker, owner, consequence, fallback, and next action.

Access, recovery, and offboarding

Grant

• ☐ Use a unique named user; no shared login.
• ☐ Confirm model, business role, least-privilege portal role, environment, and expiration/review date.
• ☐ Record the approver, purpose, access start, billing owner where applicable, and removal trigger.
• ☐ Confirm MFA where available or record the approved exception.
• ☐ Store credentials only in the approved password manager.
• ☐ Run the fictional login, authorized-action, prohibited-action, and recovery checks.

Review and recover

• ☐ Review access at launch, role change, incident, administrator change, stabilization close, and offboarding.
• ☐ Confirm the partner retains an administrator and recovery owner independent of an Atlas-only identity.
• ☐ Use the configured recovery path; do not paste a reset link, code, key, or session into a binder or evidence file.
• ☐ Recheck the user's permitted and prohibited actions after recovery.

Revoke

• ☐ Revoke the user in the live system and remove password-manager sharing.
• ☐ Rotate affected secrets through the approved system when appropriate.
• ☐ Preserve partner administrator access.
• ☐ Reassign open orders, reviews, exceptions, reconciliations, and inventory duties.
• ☐ Record the removal result and retest a critical path with fictional data.

Order review and handoff sequence

The current state names, triggers, and notifications remain controlled by the order lifecycle specification and configured live system. Operators follow this sequence without copying external timing or commercial terms into the binder:

1. Prepare: confirm active catalog, authorized user, correct ordering branch, required business fields, and current route state.
2. Submit: create one traceable order; preserve the displayed order ID and acknowledgment.
3. Payment state: record the configured processor result; do not manually copy full payment credentials.
4. Review: the named reviewer approves, holds, or rejects using configured criteria and reason codes.
5. Route: transmit only through the configured supplier route; preserve acknowledgment or failure state.
6. Track: update the partner-facing record from the controlled status/tracking source.
7. Receive: the partner checks shipment identity, count, and visible condition under the configured receiving process.
8. Resolve: route any exception through the correct owner, record, and written remedy terms.
9. Close and reconcile: match order, payment, supplier, adjustment, and final-status records; assign any variance.
10. Reorder or archive: start a new authorized order from the current catalog or close the record under the configured retention rule.

No state transition permits an operator to invent an external acceptance, status, reason, timing, remedy, or result.

Ordering branches

Branch A — configured payment at submission

Use only when written terms and the live payment route identify:

• payer and payee;
• processor and environment;
• authorization/capture timing;
• order-review relationship to payment;
• failed, duplicate, canceled, held, rejected, adjusted, and refunded transaction treatment;
• settlement owner and reconciliation cadence; and
• support/escalation route.

The portal display is not the controlling commercial term. The configured written record controls.

Branch B — partner stock order

Use only when carrying stock is included and the live records identify:

• authorized stock-order users;
• receiving location and custodian;
• inventory system and count cadence;
• adjustment, loss, damage, shortage, and discrepancy records;
• reorder decision owner;
• catalog and item-status check at each reorder;
• applicable storage/handling instructions from the authorized external source; and
• discontinuation, hold, or recall route when applicable.

This branch is an operational inventory record. It does not authorize a product or public statement.

Direct-customer data exclusion

Neither branch sends a partner customer's identity, contact information, health information, payment information, notes, or purchase history to Atlas. If unexpected customer data appears, stop the affected route, restrict access, notify the configured partner data owner, and use the incident process.

Inventory and receiving control

Complete only when stock ordering is included.

Field	Controlled value
Inventory location ID	[ATLAS CONFIG]
Partner custodian and backup/escalation	[ATLAS CONFIG]
Receiving route	[ATLAS CONFIG]
Count method and cadence	[ATLAS CONFIG]
Adjustment authority	[ATLAS CONFIG]
Reorder review cadence	[ATLAS CONFIG]
External storage/handling source	[ATLAS CONFIG: AUTHORIZED SOURCE URL]
Hold/withdrawal route	[ATLAS CONFIG]
Last fictional scenario test	[ATLAS CONFIG]

At receipt, record only the fields required by the configured process: order ID, shipment/tracking reference, received date/time, recipient, line count, visible condition, discrepancy state, evidence location, and next owner. Do not improvise inspection conclusions or handling instructions.

Exception matrix

Final response windows, remedies, payer duties, shipping duties, and decision authority remain [ATLAS CONFIG] until verified from controlling terms.

Scenario	Immediate operator action	Required record	Customer-facing communicator	Escalation / close evidence
Payment failed	Keep order from advancing; preserve processor reference without full payment data	Payment exception	Partner	Corrected test/result or closed order
Duplicate payment/order suspected	Hold duplicates; do not advance or refund from memory	Duplicate review	Partner	One controlling order plus adjustment decision
Atlas review hold	Record exact configured reason and next required input	Review queue	Partner	Approve/reject/continue-hold decision
Order rejected	Stop routing and preserve responsible-party decision	Order record	Partner	Written reason/status and payment follow-through
Supplier acknowledgment missing	Keep external state unresolved; follow retry/hold route	Supplier-transmission exception	Partner	Acknowledgment or documented close
Status/tracking stale	Do not invent progress	Status exception	Partner	Verified update or continuing hold
Delivery delayed	Use configured carrier/supplier escalation	Delivery exception	Partner	Verified status and next review
Shipment visibly damaged	Preserve configured evidence and isolate from normal closeout	Damage record	Partner	Remedy decision and final status
Shipment short	Record expected/received count and configured evidence	Shortage record	Partner	Adjustment/replacement/close decision
Replacement requested	Route under verified remedy terms; do not promise acceptance	Remedy record	Partner	External decision and final tracking/status
Complaint received	Partner opens configured case and uses Section 09 escalation	Complaint record	Partner	Named owner, disposition, and close evidence
Refund requested	Partner follows configured policy and money path	Refund record	Partner	Processor/order reconciliation and notice record
Unexpected customer or sensitive data	Stop and restrict the affected route	Incident record	Partner	Containment, owner decision, and corrected route
Supplier/system unavailable	Hold dependent ordering path and activate documented fallback, if any	Continuity record	Partner	Restore, substitute under written decision, or remain Blocked

Atlas may support the configured system and supplier-routing record within written scope. That does not make Atlas the customer's seller, refund issuer, product investigator, or ordinary customer-support contact.

Reorder control

A reminder is a prompt to review, not authorization to order.

1. Open the current inventory/need record.
2. Open the current controlled live catalog.
3. Confirm the partner user still has submit authority.
4. Confirm the item/order route is Active and no relevant hold exists.
5. Record the reorder basis and reviewer.
6. Submit as a new traceable order.
7. Follow the standard review, payment, supplier, tracking, receipt, and reconciliation path.

Reorder field	Controlled value
Reorder rule/cadence	[ATLAS CONFIG]
Decision owner	[ATLAS CONFIG]
Current inventory/need record	[ATLAS CONFIG]
Current catalog/version	[ATLAS CONFIG]
Open-order/duplicate check	[ATLAS CONFIG]
Hold check	[ATLAS CONFIG]
New order ID	[ATLAS CONFIG]

Settlement and reconciliation

Use one reconciliation record for each configured period.

Record	Match against	Variance owner
Portal order	Review decision, final order state, supplier acknowledgment, and receipt/close record	[ATLAS CONFIG]
Payment processor event	Order ID, payment state, adjustment, refund, dispute, and settlement	[ATLAS CONFIG]
Supplier record	Routed order, acknowledgment, external charge/credit, tracking, and remedy	[ATLAS CONFIG]
Inventory record when included	Receipt, count, adjustment, issue, and reorder	[ATLAS CONFIG]
Exception queue	Open/closed issue, responsible owner, remedy, and next action	[ATLAS CONFIG]

Close rule

The period closes only when:

• all included records match or carry an assigned variance;
• every open exception has one owner, consequence, next action, and review date;
• refunds, credits, adjustments, and replacements use the configured written route;
• no customer data or full payment credential entered the Atlas ordering record; and
• the partner owner acknowledges the close or Conditional state.

Catalog, evidence, and system change log

Changing facts remain in [ATLAS CONFIG: ORDERING CHANGE LOG URL], not here.

Change field	Required content
Change ID	Stable identifier
Affected catalog/system version	Exact current and superseded versions
Change type	Catalog, commercial, availability, evidence, route, system, role, or policy
Source and owner	Controlling record and responsible owner
Effective date/time zone	Verified live value
Affected partner/users/orders	Current controlled list
Required action	Hold, notify, configure, test, supersede, or no action
Test/evidence	Functional result without customer data or secrets
Notice record	Audience, channel, sender, date, and exact version
Close/supersession link	Final status and replacement record

Until a change is configured and tested, affected routes stay Conditional or Blocked. A notice does not itself prove that a catalog, payment, supplier, or workflow change works.

Model branches

Platform edition

• Use partner business ordering access, remote user/access controls, configured receiving destination, status, support, and reconciliation.
• Do not render Clinic-only front-desk, walk-in, room, local-device, or on-site inventory assumptions.
• A Platform edition does not imply a physical public location or local receiving operation.

Core invariant

Both editions use the same controlled live catalog, order ID, review, external route, status, exception, reconciliation, access, evidence, and offboarding control structure. Model inserts add only the selected mode's operational facts.

Print versus live

Print contains: module names, decision paths, owner roles, state vocabulary, checklists, scenario routes, acceptance criteria, escalation route, and human-readable Vault location.

Digital Vault contains: live portal and account URLs; current catalog; prices and commercial terms; supplier/vendor identities and agreements; processor configuration; users; dates; time windows; tracking; inventory; orders; exceptions; refunds; reconciliation; evidence; contacts; notices; and change history.

Approved password manager contains: credentials, recovery codes, keys, tokens, private identifiers, and other secrets.

No live order, payment, inventory, complaint, customer, supplier-confidential, or credential record belongs in the printed binder.

Acceptance evidence register

Build Spec ID	Evidence required	Evidence link	Owner	Status	Next action
06-06	Configured partner roles/access and recovery; catalog state; order-status route; fictional normal/hold/reject/payment/recovery/access-removal tests; training record	[ATLAS CONFIG: EVIDENCE URL]	[ATLAS CONFIG]	[ATLAS CONFIG: NOT STARTED / READY FOR REVIEW / ACCEPTED / CONDITIONAL / BLOCKED / N/A]	[ATLAS CONFIG]
06-07	Configured review, supplier, tracking, receiving, damage, shortage, delay, rejection, replacement, reorder, exception, and reconciliation routes; end-to-end fictional scenarios or explicit blockers/fallbacks	[ATLAS CONFIG: EVIDENCE URL]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]

Wave 3 acceptance checks

• ☐ Test 2 — branch isolation: Clinic-only receiving/site assumptions appear only in a Clinic edition; a Platform edition cannot inherit them. Platform wording does not certify any Clinic facility or process.
• ☐ Test 3 — coverage: 06-06 and 06-07 each have this section, current-system links, owner, scope state, acceptance evidence, exclusions, and next action.
• ☐ Test 4 — exact ledger contribution: this section claims exactly 06-06 and 06-07; it does not duplicate ownership of another Build Specification line.
• ☐ Test 5 — live truth: catalog items, prices, terms, vendors, contacts, accounts, users, dates, time windows, orders, tracking, inventory, remedies, refunds, evidence, and external text remain in controlled live records.
• ☐ Test 10 — modularity: stock/inventory, external transmission, tracking, payment, reminder, and other Conditional modules may be N/A or HELD without breaking order IDs, links, the remaining operating path, or reconciliation.
• ☐ A fictional normal order and each included failure/recovery route have traceable results without live customer data.
• ☐ No secret, full payment credential, static price, supplier assertion, product statement, or partner-customer record appears in this section.

Operator sign-off

Role	Name	Decision	Date	Open dependency
Partner ordering owner	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Partner finance/reconciliation owner	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Partner administrator	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Atlas ordering-system owner	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]

Section 11 — Team, Hiring, Role Training, and Employment Controls

Status: DRAFT-APPLIED SECTION MASTER · STAGING ONLY · NOT A CONFIGURED PARTNER EDITION

Executor: Codex

Control metadata

Field	Controlled value
Owner	[ATLAS CONFIG: PARTNER PEOPLE / TRAINING OWNER]
Model	Core with Clinic and Platform role branches
Scope state	[ATLAS CONFIG: INCLUDED / CONDITIONAL / EXCLUDED / NOT APPLICABLE]
Version	0.1
Last review	2026-07-24
Prerequisite	Signed Build Specification; selected model; configured operating-responsibility map; approved role need; partner decisions for staffing, work arrangement, schedule, compensation, classification, recruiting, records, and counsel-supplied documents
Done when	Every included business function has one named accountable role and a backup or documented hold/escalation route; recruiting and interview records follow the configured workflow; selected users complete onboarding, system orientation, access controls, and objective task verification; offboarding removes access and reassigns open work
Escalation route	[ATLAS CONFIG: PARTNER PEOPLE / TRAINING / ACCESS ESCALATION ROUTE]
Live-system link	[ATLAS CONFIG: DIGITAL VAULT URL — 07_TRAINING_AND_PEOPLE / CURRENT_ROLE_AND_TRAINING_RECORDS]
Human-readable fallback	Digital Vault → 07_TRAINING_AND_PEOPLE → Current Role and Training Records
Build Specification ownership	07-01, 07-02, 07-04

Purpose and boundary

This section turns the partner's real staffing decisions into a controlled operating system. It supplies:

• a role-need decision;
• reusable business-role scorecards;
• a configurable recruiting and selection workflow;
• structured screening and interview records;
• onboarding and access coordination;
• role-based system orientation;
• observable task verification;
• coaching and quality review; and
• controlled offboarding.

It does not make Atlas the partner's employer, manager, recruiter of record, payroll provider, employment adviser, clinical educator, licensure evaluator, or staff-performance guarantor. The partner and its retained advisers control employment decisions, compensation, classification, required notices, screening, record retention, professional requirements, and employment documents.

Atlas training covers the included delivered business systems. It is not clinical, professional, legal, regulatory, licensure, employment, continuing-education, or safety training and does not certify an employee's fitness, competency, or future performance.

Current system links

People-system need	Current source	Operator use
Responsibility and handoff assignment	OPS-01 Operating Responsibility Map	Assign exactly one accountable owner to every included workflow; do not invent people to fill blank rows
Customer journey and escalation roles	OPS-02 Customer Journey and Escalation Map	Connect roles to normal, exception, and out-of-authority handoffs
Account, access, recovery, and removal	OPS-04 Account and Credential Inventory	Grant least privilege; record references and recovery; keep secrets out
Operating procedures by role	OPS-05 Core SOP Pack	Assign each included SOP's owner, trigger, steps, record, exception, and escalation
Platform role differences	OPS-07 Platform Workflow Addendum	Apply only to an included Platform edition
Continuity, export, and offboarding	OPS-08 Continuity and Offboarding	Reassign duties, preserve partner control, export permitted records, and remove access
Role-based training sequence	TR-01 Role-Based Training Plan	Assign attendees, modules, prerequisites, systems, task sets, sessions, and open dependencies
Delivered-system orientation modules	TR package manifest	Use the current role-relevant brand, website, CRM, operations, launch, and handoff modules
Administrator live session	TR-07 Administrator Session	Verify administrator tasks in the configured nonproduction environment
Objective task evidence	TR-10 Objective Task Verification	Record observable Pass, Fail, Blocked, or N/A results; attendance alone is not readiness
Readiness outcome	TR-11 Final Readiness Report	Preserve role-specific incomplete tasks and their activation consequences
Claims boundary	KB-42 Call Claims Pack	Keep business descriptions inside current factual forms; never recruit with income, outcome, or unsupported category language

People-system source-of-truth rule

The binder keeps process, role families, decision rules, and reusable checklists. The Digital Vault holds the current:

• approved role and scorecard;
• work arrangement and location;
• schedule and availability;
• compensation and classification decisions;
• recruiting channels and publication records;
• applicants and selection records;
• background/reference decisions and results where authorized;
• counsel-supplied documents;
• equipment and account assignments;
• attendance, task evidence, coaching, and access history; and
• offboarding record.

Do not put applicant records, identity documents, background results, payroll records, tax records, bank information, health information, accommodations, disciplinary details, credentials, or secrets in a printed binder.

Role-need decision

Do not publish a listing merely because a legacy binder named a role. First decide whether a real operating gap exists.

Decision field	Controlled value
Role-request ID	[ATLAS CONFIG]
Business function and workflow gap	[ATLAS CONFIG]
Selected model	[ATLAS CONFIG: CLINIC / PLATFORM]
Current accountable owner	[ATLAS CONFIG]
Existing capacity or continuity risk	[ATLAS CONFIG]
Alternatives considered	Combine roles / change process / automate administrative step / contractor or vendor / hire / hold
Proposed role status	[ATLAS CONFIG: PROPOSED / APPROVED / HELD / NOT NEEDED / SUPERSEDED]
Partner decision-maker	[ATLAS CONFIG]
Adviser review required	[ATLAS CONFIG]
Approved scorecard/version	[ATLAS CONFIG]
Budget/compensation record	[ATLAS CONFIG: LIVE CONFIDENTIAL RECORD URL]
Target operating start	[ATLAS CONFIG]
Next action/owner	[ATLAS CONFIG]

No-invented-staff rule: one person may hold multiple business roles. Record the actual primary person and either a real backup or a hold/escalation route. Never add a fictional employee so a diagram appears complete.

Core role scorecard library

These are configurable business-system role families, not job titles, classifications, employment offers, professional scopes, or compensation promises. Select only the functions the partner actually needs.

Role family	Accountable outcomes within the business system	Observable recurring work	Must escalate	Core evidence
Partner decision-maker	Scope, operating decisions, readiness, resource and adviser decisions	Resolve dependencies; acknowledge acceptance/readiness; approve owners and changes	Legal/professional questions; unresolved external dependencies; changes beyond signed scope	Decision and readiness records
Partner administrator	Account ownership, access, recovery, files, system continuity	Review users; verify recovery; maintain controlled records; coordinate exports and offboarding	Suspected access issue; unavailable recovery; unexplained system change	OPS-04, access, export, and recovery evidence
Inquiry/customer-support owner	Timely partner-owned response and correct workflow routing	Monitor assigned records; respond through approved route; book/update; record exceptions; escalate out-of-authority issues	Sensitive data; product/clinical questions; complaint; broken route; customer threat or urgent issue	CRM/booking/case history
Consultation/decision-process owner	Consistent discovery, approved explanation, written next step, clean disposition, and handoff	Use the current playbook; record yes/not-yet/no/referral; hand off approved payment/order step; assign follow-up	Unsupported statement; out-of-scope question; dispute; pressure or process deviation	Consultation/disposition/QA record
Ordering/reconciliation owner	Authorized portal use, order review, receipt, exception, and reconciliation	Use current catalog; review/submit; track; receive; resolve or route exceptions; reconcile	Payment variance; supplier/route failure; complaint; unexpected customer data; unresolved remedy	Order, exception, receipt, and reconciliation record
Marketing/content owner	Current, rights-cleared, route-tested public assets and controlled change	Select current assets; resolve tokens; test destination; preserve publication/source record; hold unsupported changes	Rights conflict; unsupported statement; broken route; account loss; material fact change	Campaign board and publication evidence
Claims/source coordinator	Accurate registry, source status, version, hold, and escalation	Locate current approved form; keep evidence linked; hold unsupported text; record supersession	Missing or conflicting source; supplier-dependent statement; product or outcome request	Claims/source/change record

Scorecard configuration

For each approved role, complete:

Field	Controlled value
Role ID and approved title	[ATLAS CONFIG]
Model and work arrangement	[ATLAS CONFIG]
Reports to / accountable partner owner	[ATLAS CONFIG]
Included business functions	[ATLAS CONFIG]
Explicit exclusions / out-of-authority issues	[ATLAS CONFIG]
Required recurring tasks and cadence	[ATLAS CONFIG]
Required systems and minimum permissions	[ATLAS CONFIG]
Required Atlas modules and task IDs	[ATLAS CONFIG]
Partner/adviser-defined qualifications	[ATLAS CONFIG]
Evidence reviewed in quality checks	[ATLAS CONFIG]
Backup or hold/escalation route	[ATLAS CONFIG]
Review date and owner	[ATLAS CONFIG]

Scorecards measure performance of documented business tasks, not customer results, revenue, employee worth, or protected characteristics.

Recruiting workflow

All external publication, classification, compensation, screening, notices, questions, retention, and selection rules remain [ATLAS CONFIG] until approved by the partner and its retained advisers.

Stage map

Stage	Required action	Record	Stop condition
1. Role approved	Confirm role need, scorecard, scope, work arrangement, budget record, decision owner, and review route	Approved role request	Role need, owner, or required adviser decision unresolved
2. Listing configured	Resolve title, functions, schedule, location/remote facts, qualifications, application route, compensation display decision, and current approved text	Listing version	Unverified, misleading, outcome-based, or unsupported statement
3. Publication authorized	Confirm account owner, channel, dates, accessibility route, records owner, and close/remove process	Publication record	Account unavailable, text drift, or missing authorization
4. Application received	Assign stable candidate ID; restrict access; record source and stage	Candidate record	Unapproved data collection or access
5. Minimum criteria review	Apply the same approved job-related criteria and record result	Screening rubric	Criteria missing, changed midstream, or unapproved exception
6. Structured screen	Ask the approved common questions; score observable responses; provide role/process facts only	Phone/video screen score	Prohibited or improvised question; material fact unknown
7. Structured interview/work sample	Use the same approved rubric and, when included, a fictional business-system scenario	Interview/work-sample score	Live customer data, secret, unpaid live operating work, or unapproved task
8. Reference/background step	Run only the configured, authorized step through the correct owner	Restricted verification record	Missing decision, notice, authorization, or secure route
9. Selection decision	Compare job-related evidence; record decision and approver	Selection record	Required decision-maker or configured review incomplete
10. Written next step	Partner/counsel supplies the applicable written document and instructions	Counsel-controlled document reference	Unapproved terms or missing partner authorization
11. Close and retain	Notify through approved route; close publication; preserve/delete records under configured rule	Close/retention record	Unclear retention owner or open access

Configurable listing fields

• [ATLAS CONFIG: APPROVED ROLE TITLE]
• [ATLAS CONFIG: REAL PUBLIC BRAND / LEGAL EMPLOYER IDENTITY]
• [ATLAS CONFIG: MODEL AND REAL WORK LOCATION / REMOTE ARRANGEMENT]
• [ATLAS CONFIG: REPORTING ROLE]
• [ATLAS CONFIG: ESSENTIAL BUSINESS RESPONSIBILITIES]
• [ATLAS CONFIG: SCHEDULE / AVAILABILITY]
• [ATLAS CONFIG: PARTNER-APPROVED JOB-RELATED QUALIFICATIONS]
• [ATLAS CONFIG: COMPENSATION / CLASSIFICATION / BENEFITS DISPLAY DECISION]
• [ATLAS CONFIG: APPLICATION ROUTE AND ACCESSIBILITY CONTACT]
• [ATLAS CONFIG: RECORDS / RETENTION / PRIVACY NOTICE ROUTE]
• [ATLAS CONFIG: PUBLICATION CHANNEL / OWNER / START / CLOSE]

The listing must not promise earnings, customers, leads, outcomes, advancement, permanent employment, professional qualification, or Atlas acceptance. It must not use supplier, product, health, or customer-result statements to make the role sound more attractive.

Structured screen and interview

Common screen rubric

Use the same approved questions for the same role and score only job-related evidence.

Dimension	Prompt	Evidence to record	Score
Role understanding	“In your own words, what business tasks does this role own, and what falls outside it?”	Correct boundary and escalation awareness	[ATLAS CONFIG: SCALE]
Workflow discipline	“Tell us how you follow a documented process when the next step is unclear.”	Uses source, hold, owner, and escalation	[ATLAS CONFIG]
Record accuracy	“Describe a time you caught and corrected an administrative record error.”	Identification, containment, correction, and prevention	[ATLAS CONFIG]
Customer communication	“How do you respond when a customer asks something outside your authority?”	Does not improvise; uses approved response and route	[ATLAS CONFIG]
Technology learning	“Walk us through how you learn and verify a new business system.”	Practice, evidence, questions, and retest	[ATLAS CONFIG]
Reliability/coverage	“How would you flag an availability issue that affects an assigned workflow?”	Early notice, reassignment, and continuity route	[ATLAS CONFIG]

Structured interview / fictional work-sample options

Select only role-relevant tasks:

• locate the current SOP and identify owner, trigger, record, and escalation;
• route a fictional inquiry without requesting excluded data;
• classify a fictional statement as current, held, or needing escalation;
• find the current portal/catalog record without relying on a cached value;
• identify least-privilege access needed for a fictional role;
• classify a fictional issue as routine, out-of-authority, or urgent escalation;
• read a status board and state the next action, owner, and blocker; or
• complete a fictional handoff record without a secret or customer identifier.

The work sample uses fictional data in a nonproduction environment. It does not involve live customer work or imply that the candidate has been selected.

Interview decision record

Candidate ID	Role ID	Rubric version	Screen result	Interview/work-sample result	Reference/background state	Decision	Decision owner/date	Notes location
[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG: ADVANCE / HOLD / DECLINE / WITHDRAWN]	[ATLAS CONFIG]	[ATLAS CONFIG: RESTRICTED RECORD URL]

Keep applicant details in the restricted live system, not in this binder.

Selection and reference controls

• ☐ Use the approved job-related rubric version for every candidate in the same selection round.
• ☐ Record exceptions and their decision owner; do not silently change criteria.
• ☐ Run references, credential verification, background checks, or other screening only when the partner's configured process authorizes them.
• ☐ Do not treat a resume, reference, certificate, or self-description as independently verified without the recorded verification step.
• ☐ Keep restricted records accessible only to approved roles.
• ☐ Route uncertainty about permitted questions, notices, screening, classification, or records to the partner's retained adviser.
• ☐ Have the partner decision-maker record the selection.

Onboarding command card

Before access

• ☐ Counsel/partner-controlled written documents and required acknowledgments are complete or the start is held.
• ☐ Role, manager, start state, schedule, work arrangement, equipment, payroll/administration owner, and required partner policies are recorded.
• ☐ Role scorecard, explicit boundaries, SOPs, system list, training modules, task list, and escalation route are assigned.
• ☐ Data and customer-communication boundaries are acknowledged.
• ☐ One primary and one backup or hold/escalation route is recorded for each critical responsibility.

Account and equipment setup

• ☐ Create unique named accounts only after approval.
• ☐ Grant minimum access required by the scorecard.
• ☐ Enable MFA where available or record the approved exception.
• ☐ Record equipment and account references; keep passwords, codes, keys, and tokens in the approved password manager.
• ☐ Verify partner-controlled recovery and the user's access-removal trigger.
• ☐ Run fictional permitted-action and prohibited-action tests.

First-use orientation

• ☐ Show the current binder edition, Digital Vault path, version rule, and escalation route.
• ☐ Complete only the role-relevant modules in the TR package.
• ☐ Demonstrate how to locate the current asset instead of using a personal copy.
• ☐ Demonstrate how to classify a route or dependency Ready, Conditional, Blocked, or N/A.
• ☐ Demonstrate the no-improvisation and no-Atlas-customer-contact boundaries.
• ☐ Assign exact TR-10 tasks, evidence location, verifier, and due state.

Role-based training plan

Configure the TR-01 master; do not copy changing names, schedules, account routes, or evidence into print.

Training element	Required configured record
Attendee and role	Named user, actual role(s), primary duties, and backup/hold route
Module assignment	Role-relevant Atlas system modules only
Prerequisite	Account/environment, fictional test route, system version, and required prior module
Delivery	[ATLAS CONFIG: SELF-GUIDED / RECORDED / LIVE]
Task set	Exact TR-10 IDs plus approved role-specific tasks
Evidence	Completion, observable action, expected evidence, verifier, and location
Result	PASS / FAIL / BLOCKED / N/A
Remediation	Defect, owner, next action, retest, and activation consequence

One person may attend for multiple roles. More attendees, extra sessions, retraining, professional education, or later-system training are included only when the written Build Specification schedules them.

Core system orientation

Orientation follows the accepted delivered configuration and uses fictional data. Each included user must be able to:

1. locate the current role scorecard, SOPs, system links, status board, and escalation route;
2. distinguish staging, demonstration, test, and production environments;
3. use the current version and recognize a superseded copy;
4. follow the approved brand/factual boundary and hold unsupported statements;
5. use only the access and data required for the role;
6. perform the assigned website, CRM, booking, marketing, operations, ordering, handoff, or administrator tasks;
7. preserve partner ownership of customer communication;
8. route defects and out-of-authority issues to the correct owner;
9. use safe fallback/hold behavior when a route fails; and
10. identify the consequence of each unresolved critical task.

Attendance and viewing records show delivery, not task proficiency or operational readiness.

Objective task verification

Use the current TR-10 checklist plus scheduled role-specific tasks.

Task field	Rule
Task ID	Stable ID; mapped to role and delivered system
Designated user	The person expected to perform the work
Environment/data	Configured nonproduction environment with fictional records
Prerequisite	Exact access, version, route, and prior task
Observable action	One action the verifier can see
Expected evidence	Defined before the attempt
Result	PASS, FAIL, BLOCKED, or signed-scope N/A
Verifier	Named person and date
Defect/next action	Required for every Fail or Blocked result
Activation consequence	A failed or blocked critical task prevents Ready for the affected role/path

Minimum task families

• find the current source and distinguish a superseded copy;
• complete one permitted action and one prohibited-action test;
• follow the normal workflow;
• route an exception to the right owner;
• stop and hold an unsupported or broken path;
• recover or remove fictional access;
• locate the partner-owned fallback;
• classify Ready, Conditional, Blocked, and N/A scenarios; and
• distinguish a deficiency from new or changed work.

A safe-hold test may pass only for the hold boundary. It does not clear the underlying dependency.

Coaching and quality review

Coaching is a partner-managed process review, not ongoing Atlas management.

QA dimension	Review question	Evidence	Result
Current-source use	Did the user open the current controlled asset instead of a personal or cached copy?	Version/source record	[ATLAS CONFIG]
Required steps	Were all required workflow steps completed in order?	System history/checklist	[ATLAS CONFIG]
Record accuracy	Are owner, state, source, time, reason, and next action accurate and complete?	Fictional or permitted operating record	[ATLAS CONFIG]
Boundary discipline	Did the user avoid unsupported statements and out-of-authority decisions?	QA sample and escalation record	[ATLAS CONFIG]
Customer communication	Did the partner-owned route handle communication and preserve context?	Case/CRM record	[ATLAS CONFIG]
Data/access	Did the user use minimum necessary data and permissions without exposing a secret?	Access/data review	[ATLAS CONFIG]
Exception handling	Was the issue contained and routed to the correct owner?	Exception record	[ATLAS CONFIG]
Follow-through	Was the next action completed, reassigned, or held visibly?	Task/status history	[ATLAS CONFIG]

Coaching record

Review ID	User/role	Workflow/task	Evidence sample	Result	Coaching action	Retest	Owner/date
[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG: PASS / COACH / RETEST / ESCALATE]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]

Use documented process evidence. Do not score protected traits, personality impressions unrelated to the role, sales or customer outcomes outside the user's control, or unverified allegations.

Counsel-document checklist — reference only

Atlas does not draft, approve, interpret, or certify the documents below through this binder. The partner's retained adviser supplies or approves the actual forms, language, timing, signatures, storage, and use.

Document/decision category	Live counsel-controlled reference	Partner owner	Required before	Status
Employment/engagement offer or agreement	[ATLAS CONFIG: COUNSEL DOCUMENT URL]	[ATLAS CONFIG]	Written next step/start	[ATLAS CONFIG]
Worker classification and compensation/pay practices	[ATLAS CONFIG]	[ATLAS CONFIG]	Listing/offer/payroll setup	[ATLAS CONFIG]
Required notices, acknowledgments, and policies	[ATLAS CONFIG]	[ATLAS CONFIG]	Start/system access as applicable	[ATLAS CONFIG]
Confidentiality, intellectual-property, privacy, and data duties	[ATLAS CONFIG]	[ATLAS CONFIG]	Access to controlled information	[ATLAS CONFIG]
Screening/reference/background process and notices	[ATLAS CONFIG]	[ATLAS CONFIG]	Screening step	[ATLAS CONFIG]
Handbook/policy acknowledgments	[ATLAS CONFIG]	[ATLAS CONFIG]	Start or policy applicability	[ATLAS CONFIG]
Equipment, device, acceptable-use, and return record	[ATLAS CONFIG]	[ATLAS CONFIG]	Equipment/account issue	[ATLAS CONFIG]
Professional credential/scope verification when a role requires it	[ATLAS CONFIG]	[ATLAS CONFIG]	Assignment of that function	[ATLAS CONFIG]
Leave, accommodation, complaint, incident, and investigation routes	[ATLAS CONFIG]	[ATLAS CONFIG]	Process activation	[ATLAS CONFIG]
Separation, final access, property, records, and post-separation duties	[ATLAS CONFIG]	[ATLAS CONFIG]	Offboarding	[ATLAS CONFIG]

If a required counsel-controlled item is unresolved, hold only the affected recruiting, start, access, duty, or offboarding step and record the owner and consequence.

Access change, role change, and offboarding

Role or status change

1. Record the approved effective date and new accountable owner.
2. Reconcile the new scorecard with current SOPs and system permissions.
3. Remove access no longer required before adding expanded access.
4. Assign changed training modules and observable tasks.
5. Reassign open inquiries, appointments, consultations, orders, exceptions, campaigns, incidents, and reviews.
6. Verify partner recovery and continuity.
7. Record the change and retest affected critical workflows.

Offboarding checklist

• ☐ Confirm authority, effective date, role, last working state, and partner/counsel-controlled document route.
• ☐ Inventory assigned accounts, systems, equipment, files, records, customers/cases, orders, tasks, and approvals.
• ☐ Name the receiving owner for every open item.
• ☐ Preserve required partner records under the configured retention and access rule.
• ☐ Revoke system and password-manager access at the configured time.
• ☐ Rotate affected secrets through the approved system when appropriate; do not record them here.
• ☐ Recover partner equipment and verify its recorded disposition.
• ☐ Remove the person from notices, routing, calendars, shared access, approvals, and emergency/recovery roles.
• ☐ Verify the partner administrator and critical workflows still function.
• ☐ Close or assign incomplete training, QA, incidents, and exceptions.
• ☐ Record final access scan, open dependency, next action, and owner.

The partner owns staff and customer communication. Atlas may remove Atlas-controlled access and provide configured system records within written scope; Atlas does not conduct the partner's employment separation.

Model branches

Platform edition

Include only scheduled Platform facts and tasks, such as:

• remote workspace and distributed user coverage;
• remote meeting, digital inquiry, ordering/support, and platform-interruption duties;
• device/network fallback and remote access review;
• remote equipment return and file/account continuity; and
• working-hours/time-zone handoffs.

Do not render front-desk, walk-in, room, facility, local receiving, physical key, or on-site device assumptions in a Platform edition.

Core invariant

Both editions use the same role decision, scorecard, recruiting, selection, onboarding, current-source, task-verification, coaching, access, counsel-reference, and offboarding controls. Optional roles and modules may be omitted without changing stable section numbering.

Print versus live

Print contains: role families, decision steps, scorecard fields, workflow stages, interview rubric structure, onboarding/training/task-verification rules, QA dimensions, offboarding checklist, and human-readable Vault path.

Digital Vault contains: named roles and people; listings; compensation/classification decisions; applicants; interview and screening records; restricted counsel documents; equipment; accounts; schedules; attendance; task evidence; coaching; access; incidents; and offboarding records.

Approved password manager contains: passwords, keys, tokens, recovery codes, and other secrets.

No applicant, employee, contractor, payroll, tax, banking, background, accommodation, medical, disciplinary, personal contact, identity, credential, or secret record belongs in print.

Acceptance evidence register

Build Spec ID	Evidence required	Evidence link	Owner	Status	Next action
07-01	Named attendees map to roles, modules, prerequisites, systems, task sets, delivery formats, sessions, evidence, and open dependencies; plan is acknowledged	[ATLAS CONFIG: EVIDENCE URL]	[ATLAS CONFIG]	[ATLAS CONFIG: NOT STARTED / READY FOR REVIEW / ACCEPTED / CONDITIONAL / BLOCKED / N/A]	[ATLAS CONFIG]
07-02	Current delivered-system orientation is accessible; assigned users attend/complete required modules; environment, version, access, and role boundaries are recorded	[ATLAS CONFIG: EVIDENCE URL]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
07-04	Every required user performs assigned observable fictional tasks; Pass/Fail/Blocked/N/A result, verifier, evidence, defect, owner, next action, and activation consequence are recorded	[ATLAS CONFIG: EVIDENCE URL]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]

Wave 3 acceptance checks

• ☐ Test 2 — branch isolation: Clinic-only facility, front-desk, on-site, local receiving, and physical-access instructions appear only in a Clinic edition; Platform-only remote assumptions do not certify a Clinic workflow.
• ☐ Test 3 — coverage: 07-01, 07-02, and 07-04 each have this section, current-system links, owner, scope state, acceptance evidence, exclusions, and next action.
• ☐ Test 4 — exact ledger contribution: this section claims exactly 07-01, 07-02, and 07-04; it does not duplicate ownership of another Build Specification line.
• ☐ Test 5 — live truth: people, listings, compensation, classification, applicants, schedules, accounts, counsel documents, task evidence, coaching, access, and offboarding facts remain in controlled live records.
• ☐ Test 10 — modularity: any optional role, recruiting channel, screening step, work sample, system module, live session, or model insert may be N/A or HELD without breaking stable section numbering or the remaining people-system flow.
• ☐ Every critical function has one real accountable owner and a real backup or visible hold/escalation route.
• ☐ No secret, personal record, employment agreement, professional certification, income statement, product statement, or customer outcome appears in this section.

Operator sign-off

Role	Name	Decision	Date	Open dependency
Partner people/training owner	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Partner administrator	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Partner decision-maker	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]
Atlas training/system owner	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]	[ATLAS CONFIG]