cg-response-protocol

Imported from sultandroid/hermes-memory (skills/project-management/cg-response-protocol/SKILL.md). Install upstream with npx skills add sultandroid/hermes-memory --skill cg-response-protocol. Copyright stays with the author.

References

• references/warning-letter-delay-rebuttal.md — formal CG/PMC warning letters (إنذار) about project delay: claim-by-claim rebuttal from repo evidence, delay-impact table, recurring Aseer rebuttal patterns, EOT reserved-rights framing.
• references/warning-letter-arabic-reply.md — LT-08.02 addendum: Arabic-first reply, humanization pass, PM dictation integration, repo thread setup. Rule: Arabic CG letter → Arabic reply primary; EN = internal annex.

CRS Creation Workflow (MANDATORY — Follow in Order)

When the user says "create CRS" or "make a CRS sheet":

1. Fetch the blank template immediately from https://samaya-factory.com/assets/templates/CRS_Template_MOC_HQ.xlsx (the MOC_HQ Comments Resolution Sheet — the official template the user supplies; do NOT build a custom Excel CRS from scratch) — do NOT ask which template, do NOT describe the format, do NOT ask for confirmation
2. Save as CRS_[DocRef]_Rev[XX].xlsx in 02_CG_Responses/
3. Fill header block (rows 1-7): PROJECT NAME, CRS NUMBER, DOCUMENT No., DOCUMENT TITLE, DISCIPLINE, DATE, Rev
4. Fill data rows (row 11+): No., Initial, Sheet/Ref, Code, Reviewer Comment, Originator Reply, Reply By, Status
5. Present to user for review — do NOT send to CG or specialist without user approval
6. Do NOT get sidetracked by other tasks (risk register updates, merge conflicts, template hosting) before completing the CRS — the CRS is the primary deliverable

CRS Template Location

The approved blank CRS template and all other Samaya templates are at:

https://samaya-factory.com/templates/

OneDrive source of truth: 04_Docs/09_Registers/CRS_Templates/CRS_TEMPLATE_BLANK.xlsx

Pitfall — Do Not Sidetrack

When the user asks for a CRS, the CRS is the ONLY deliverable until it is done. Do NOT:

• Update risk registers mid-CRS
• Fix merge conflicts in unrelated files
• Host templates on the server
• Research CG comments from Outlook
• Ask the user to paste comments you could find yourself

Complete the CRS first, then ask "what next?".

Stage-Boundary Triage — Out-of-Stage CG Comments

CG frequently comments on items that belong to a different design stage than the one submitted. This is a distinct pattern from scope creep (which is about wrong discipline) — stage-boundary comments are about wrong timing.

Detection

CRS vs RFI Decision

CRS Response Language for Stage-Boundary Comments

Noted. This item belongs to the [90% DD / IFC / Shop Drawing] stage
and will be addressed in the relevant submission per the DMP stage-gate
sequence. The current submission is [50% DD / Gate 1 DD] and covers
[scope of current stage].

No argument, no justification — just state the boundary. CG can disagree, but the burden shifts to them to explain why a later-stage item belongs in the current review.

Triage Workflow

1. Read each CG comment against the DMP stage-gate definition for the current submission
2. Classify: In-stage (respond) vs Out-of-stage (note and defer)
3. For in-stage: Draft technical response per Stream 2
4. For out-of-stage: Use the CRS response language above — do not comply, do not argue
5. Log recurring pattern: If the same CG reviewer repeatedly issues out-of-stage comments, add a risk entry (see PRR-COM-10 template below)

Risk Entry Template

When CG stage misunderstanding is a recurring pattern, add to the risk register:

Core Principle: Two Separate Streams

CG comments come in two distinct types. Never merge them into one response.

Core Principle 2: Plan vs Register Distinction

When CG returns Code C on a management plan (RMP, SMP, DMP, HSE Plan, QMP), not all comments are valid. Some ask for operational data that belongs in live registers, not the plan itself. Before complying, ask: "Is this methodology or data?"

Why 4 Registers for Aseer Museum

Why not fewer? One register with 178 risks would be unreadable weekly. HSE must be standalone by regulation.

Why not more? Procurement and Quality risks are currently under PRR categories (PRC, QLT). If they grow past 20+ each, they can be split. Current 4 registers = balance between detail (each team sees their own) and simplicity (not 10 registers nobody tracks).

Mandatory: Run the 7 Lenses on Every CG Interaction

This protocol integrates with the CG Analysis & Lessons Learned System (cg-analysis-and-lessons skill). Every CG response handler MUST run the 7 lenses:

Pre-Submit Gate (before sending anything to CG)

If any check fails -> do not submit. Flag the blocker and resolve first.

Post-Response Capture (when CG replies)

Lessons Learned: Client-Sharable Only

When logging a lesson from a CG interaction, remember the lessons learned register is a formal project deliverable shared with the client. Only capture project-relevant lessons — no internal process notes, tool quirks, or session-specific events. See cg-analysis-and-lessons skill for the full lessons learned workflow and what to exclude.

CG Reviewer Behavior Patterns (Quick Reference)

See cg-analysis-and-lessons skill for full reviewer profiles, forecast engine, and lessons learned register.

Stream 1: Submission Plan CR Sheet

• Covers comments about what to submit, when, and by whom
• Format: Excel with columns: CR, CG Comment, CG Reference, Response, Position, Status, Open/Closed, Action Required, Supporting Documents
• CR numbering: sequential (CR-01, CR-02...) or prefixed by discipline (ARC-01, STR-01...)
• Responses are from Samaya's perspective - never mention sub-consultant scope splits to CG
• Sent to CG for agreement on positions
• Closed items: Stage 3 completed, draft in submission plan
• Open items: FF&E supplier, Life Safety by Namaa, pending tests

Stream 2: Detailed Technical Review Register

• Covers comments about technical content of submitted deliverables (BOD, calculations, drawings)
• Usually Code C (Revise & Resubmit) or Code B (Approved with Comments)
• Format: Excel with columns: Comment No., Consultant Comment, Contractor Response, Status, Reference Document, Action By, Target Date
• Not sent to CG - internal tracking for the resubmission workstream
• Each comment gets a contractor response explaining the position
• Status: Open / Closed / Noted

CR Sheet Response Framing

• Quotes must be verbatim - when quoting CG comments, ER/SoW text, or contract clauses, copy the original text exactly as written. Do NOT paraphrase, rephrase, or "clean up" the quote. The user explicitly said: "when qoute write the orginal text as it dont rewrite."
• No Sec symbol — never use Sec. Use Sec instead (e.g., ER Sec 3.7.XIII not ER Sec 3.7.XIII). The user has repeatedly corrected this across multiple sessions.
• No AI symbols — no arrows (->, <-), bullets (*, -), em dashes (--), en dashes (-), middle dots (-), or any decorative Unicode symbols. Plain ASCII only.
• Plain engineer English ("hummadize") — short, direct sentences. No fluff, no AI cliches, no "seamlessly", "robust", "holistic", "leverage", "streamline", "facilitate". Write like an engineer writing to another engineer.
• NRS is Samaya's sub-consultant — never frame NRS as separate or independent. Samaya directs NRS. Say "We direct NRS to..." not "NRS will..." or "NRS is responsible for...". Samaya is the D&B contractor; NRS works under Samaya's umbrella.
• "This was completed at Stage 3. NRS draft (XXXX) for reference. Included in submission plan and drawing register." - for items already done
• "This will be in the Life Safety registers and submittals (Namaa), not in the current architectural package." - for scope handoffs
• "Bespoke setwork furniture shown on GA with setwork codes. Remaining FF&E to be coordinated from 50% to 90% to IFC." - for phased items
• User-verified FF&E response: "Noted. Will add to submission plan and drawing register. Already in GA drawings, will split into separate drawings." — Confirms: (1) setwork already shown, (2) FF&E is a separate phased track, (3) supplier appointment is the blocker, (4) actions = add to submission plan + drawing register + split GA drawings
• "Noted." - for accepted process comments
• "All applicable loads in BOD per SBC. Showcase weights from manufacturer. Artwork weights from curator." - for technical clarifications

Specialist Drawing-Package QC

When QC'ing a specialist drawing package (ZNA lighting, Rawasin AV) at a stage gate: split formal/doc-control comments (go to specialist) from internal technical review (discipline lead); check the Design Phase Deliverables Tracker before flagging missing deliverables; CAD zips beside PDFs = source, not a package. See references/specialist-drawing-package-qc.md.

Multi-Round CRS Disposition Matrix Pattern

When CG issues multiple rounds of comments on the same document (e.g., R1 9-Mar, R2 2-Jun, R3 18-Jun), use a single consolidated disposition matrix with round-separator rows:

Structure

| # | Round | CG Comment | Disposition | Ref | Status | Route/Scope |
|---|---|---|---|---|---|---|
| cat-row | Round 1 — CG comments (9-Mar-26) — closed in Rev 1/2 |
| CG-01 | R1.9-Mar | [comment] | [response] | Sec X | CLOSED | SMP-scope |
| cat-row | Round 2 — CG CRS (2-Jun-26, Code C) — addressed in Rev 3 |
| CRS-01 | R2.2-Jun | [comment] | [response] | T1-07 | CLOSED | SMP-scope |
| cat-row | Round 3 — CG CRS (18-Jun-26, Code C) — addressed in Rev 4 |
| CRS-18 | R3.18-Jun | [comment] | [response] | CRS | CLOSED | Procedural |

Rules

• cat-row (.cat-row td with dark background) separates rounds — never use blank rows
• Round column shows date + round number for traceability
• Status badges: CLOSED (green), SUBMITTAL-PENDING (amber), IN-PROGRESS (blue), RE-OPENED (red)
• Ref column links to the document section or role ID that addresses the comment
• Route/Scope column shows whether the fix is in-scope or requires external action (PQD Register, DS, etc.)
• Each round gets its own cat-row header, even if only 1-2 comments remain open
• Comments that span multiple rounds (e.g., CG-03 re-opened in R2) get a RE-OPENED badge with explanation

Status Progression

R1: CG-01 -> CLOSED
R2: CG-01 -> CLOSED (carried forward), CRS-07 -> RE-OPENED (CV not yet submitted)
R3: CRS-18 -> CLOSED (CRS completed, QA performed)

Caveman Style for C:Resubmit Reasons

When adding CG resubmit reasons to remarks, write short direct sentences:

• "CG want: loading schedule, masonry weights, concrete cover, wind/seismic refs. All in BOD per SBC. Need to clarify and resubmit."
• "CG want: loading notation schedule, load combo names. Loading tables in BOD per SBC. Need to clarify and resubmit."
• "CG want: audit report for previous design stage. Under preparation. Will include in next package."

Multi-Round Code C Pattern — Rev.01 Still C, All Comments Open

When a Rev.01 resubmission gets Code C again with all comments still marked Open by CG:

Worked example — PEP ZD-0086 (Jul 2026):

• Rev.00 submitted 16 Jul -> Code C 22 Jul (15 comments, all Open)
• Samir circulated CG comments 22 Jul, asked team to respond
• Samir sent Rev.01 to Waris 25 Jul: "Please Review and if it's Confirmed from your side, please let's Submit it"
• Rev.01 submitted 26 Jul -> Code C again 27 Jul (same 15 comments, all still Open)
• CG note: "The CRS reply" — meaning the CRS was not fully resolved
• Root cause: 1-day internal review, no formal sign-off gate, responses were explanations not evidence
• See 01_Registers/lessons_learned_register.md LL-013 and 03_Plans/11_Quality/lessons_learned_register.md LL-017

Red Flag: PM Says "Please Review and Confirm"

When the PM/Construction Manager sends an email saying "Please Review and if it's Confirmed from your side, please let's Submit it" — this is a red flag that the CRS was not fully resolved before resubmission. The "please review" language means the team hasn't confirmed all responses yet.

Root cause of 2nd Code C: The Rev.01 was submitted before the CRS was fully resolved. CG did not accept any of the contractor's responses because they were explanations, not physical evidence. Every comment that was Open in Rev.00 remained Open in Rev.01.

Prevention: Before any resubmission, run a CRS closure check:

1. Are all CG comments from the previous round addressed with a response?
2. Are the responses physical evidence (test reports, approved drawings, completed studies) — not explanations or references to existing documents?
3. If any item is still "under preparation" or "being arranged", defer it explicitly in a cover note — do not submit hoping CG will accept partial responses.

Pattern Recognition

What This Means

• CG did not accept any of the contractor's responses from the CRS
• Every comment that was Open in Rev.00 is still Open in Rev.01
• The contractor's responses (explanations, references to SBC clauses, coordination meeting agreements) were insufficient to close any item
• CG wants physical evidence (test results, reports, approved drawings), not explanations

Common Root Causes

Action Plan

1. Stop resubmitting explanations. CG has rejected the explanation approach twice.
2. Complete the physical evidence — core testing, rebar scan, geotechnical investigation must be done before Rev.02
3. For loading/seismic comments — produce the exact schedule/study CG described, not a reference to existing BOD content
4. For team approval — formalize the appointment and get MoC sign-off
5. Update the risk register — this is now a High/Critical risk, not a routine resubmission

CRS Disposition for Multi-Round

Use the consolidated disposition matrix pattern (see above) with a clear note:

| cat-row | Round 1 — CG comments (5-Jul-26) — Rev.00 Code C — all Open |
| cat-row | Round 2 — CG comments (18-Jul-26) — Rev.01 Code C — all still Open |

Add a summary row at the top:

| SUMMARY | 2 rounds | 15 comments | 0 closed | All require physical evidence, not explanations |

Interpreting Mixed-Status CG Responses

CG often returns a submittal with different statuses at different levels. Do not conflate them.

Critical pattern — "C overall but mostly B":

• CG may stamp the submittal C overall while approving most individual drawings as B
• The C is driven by a small number of items that need revision, not the whole set
• Do not treat the overall C as a blanket rejection — check the per-item breakdown
• Action: query CG if the overall C seems disproportionate to the per-item breakdown

"Not Stamped" items:

• Drawings submitted but CG did not review or stamp
• These have no status at all — not approved, not rejected, not reviewed
• Common reasons: CG ran out of time, CG focused on specific sections, CG waiting on dependencies
• Action: flag as "Not Reviewed" in tracking, do not assume approval or rejection

Excluded/deferred packages:

• CG explicitly carves out certain drawing groups from the current review cycle
• These get a separate review at a later date
• Action: track separately, do not include in current resubmission unless CG asks

Contradictory stamps — "C" with "Approved As Submitted" text:

• CG sometimes stamps C on a drawing that also carries "Approved As Submitted" text
• This is an internal inconsistency — the stamp and the text disagree
• Action: flag both drawings by number in the query email. Ask CG to confirm the correct status. Do not guess which one is right.

C-stamped drawings with no comments:

• CG may issue a C stamp on a drawing with no review notes, no markup, no comments
• The drawing number and "C" are the only marks
• Action: ask CG explicitly for the review notes. Without comments, the resubmission has no direction.

Practical analysis — what was actually actioned:

Total submitted = A
Actioned (B + C) = B
Not reviewed (Not Stamped + Excluded) = A - B
Effective review rate = B / A

• If review rate is low (<50%), the CG did not complete their review
• Flag this in status reports: "CG reviewed only X% of submitted drawings"
• The resubmission scope is only the C-rated items + any CG comments on B-rated items
• Not Stamped items stay as-is unless CG specifically asks for changes

Querying CG About Status Inconsistencies

When the overall submittal status contradicts the per-item breakdown, send a short email to CG:

When to query:

• Overall C but majority of actioned drawings are B
• C-stamped drawings with "Approved As Submitted" text
• C-stamped drawings with zero comments
• 121+ drawings not stamped (CG didn't review most of what they received)

Email structure (keep it short, 2 questions max):

1. State the numbers: "X drawings -> B, Y drawings -> C, Z drawings -> not stamped"
2. State the contradiction: "Overall C seems incorrect given X are B"
3. Name specific drawings with contradictory stamps
4. Ask 2 clear questions: (a) should overall be B? (b) confirm status for specific drawings

Template:

Subject: Clarification on Overall Status — Submittal [NUMBER]

Dear Eng. [Name],

We received the review for Submittal [NUMBER]. The overall status is C, but the breakdown shows:

[X] drawings -> B
[Y] drawings -> C
[Z] drawings -> not stamped

With [X] drawings approved as noted and only [Y] marked C, the overall C seems incorrect. Also, [N] drawings ([NUMBERS]) have "Approved As Submitted" on them but received a C stamp with no comments — we cannot identify what needs revision.

Please clarify:
1. Should the overall status be B instead of C?
2. For drawings [NUMBERS], can you confirm the correct status?

Regards,
Eng. Mohamed Sultan

Caveman Style for C:Resubmit Reasons

When adding CG resubmit reasons to remarks, write short direct sentences:

• "CG want: loading schedule, masonry weights, concrete cover, wind/seismic refs. All in BOD per SBC. Need to clarify and resubmit."
• "CG want: loading notation schedule, load combo names. Loading tables in BOD per SBC. Need to clarify and resubmit."
• "CG want: audit report for previous design stage. Under preparation. Will include in next package."

Deemed Approval — CG Silence = Approval

When CG does not respond to a submittal within the contractual review period (typically 14-21 working days per DMP/SoW), the submittal is deemed approved per standard construction practice.

When to Apply

Register Entry

Update the submittal register with:

Email Record

Keep the email thread showing:

1. Date of submission (e.g., 21 May 2026)
2. Date range with no CG response (e.g., 21 May -> 20 Jul = 60 days)
3. Your declaration of deemed approval

Risk

• CG may later claim they were still reviewing — document your declaration date clearly
• For critical-path items (shop drawings, long-lead materials), send a follow-up email before declaring deemed approval: "We have not received a response within the review period. Please advise if you require more time, otherwise we will proceed per the deemed approval provision."
• For non-critical items (management plans, informational submittals, CV packs), deemed approval is safer to declare without follow-up

Status Definitions

Code Semantics for Automated Status Scripts — CRITICAL

When any cron/script counts submittal or design-tracker rows by CG status code, Code-C and Code-D are NEVER "done":

Worked failure (Aseer, 20-Aug-2026): scripts/design_tracker_overdue.py had "code-c" and "code-d" inside its DONE_STATUS set. The daily cron (design-tracker-daily-status) therefore reported "Architecture: Done 272" when 62 rows were actually Code-C, and "Mechanical: Done 5" all of which were Code-C. The misleading summary hid genuine resubmission work. Fix (issue sultandroid/aseer-museum-pm#269):

1. Remove code-c / code-d from the done set; keep only code-a/code-b/approved/submitted/closed.
2. Add a Code-C/Revise bucket and a Rejected bucket so those rows surface in the report instead of vanishing into "Done".
3. When cross-checking a report against a register, never trust the summary — re-read the raw sheet columns and confirm which file the script actually parsed.

Pitfall — stale source beats fresh register. The status script's find_latest_xlsx() scans ~/.hermes/cache then 01_Registers for the newest .xlsx, but a CG-issued tracker can sit stale on disk for weeks. The verified design_phase_deliverables_tracker.md (rebuilt from the dated CG xlsx, e.g. ..._12-08-2026.xlsx) is frequently AHEAD of the xlsx sitting in 01_Registers — CG approved Code-C items that the stale xlsx still shows as Code-C. Before quoting "N overdue / N Code-C" in a status report, cross-check the md register or the actual dated CG source; if the xlsx mtime predates the md last_updated, treat the md as more current. Never label stale xlsx numbers as today's truth.

CRS Triage — Filtering Comments Before Forwarding to Designer

Recurring Pattern: Resubmitting Without Closing CRS Comments

Pre-submission compliance audit — check a Rev against its OWN rejection before submitting. When the user asks "does this rev comply with all the comments", do NOT read the cover letter or the CRS. Audit the revised documents against the verbatim Code C/D rejection, comment by comment:

1. Get the rejection verbatim. The resubmission cover PDF usually embeds the full Code C/D comment block (CG reviewer + dates). Extract it with pdftotext -layout and build the comment list from it — do not rely on the CRS or a summary. If the rejection names specific files (e.g. AV Network Architecture...pdf), map each comment to the actual file in the rev folder.
2. Grep the revised docs for the named requirements, not the whole text. Every CG demand that names a concrete item (switch model, device, port count, schedule) must appear literally in the revised document.
   • Example hit (AV Package Part II, 1G-0002 Rev 001): pdftotext "AV Network Architecture...pdf" - | grep -i "Zyxel\|GS2220" returned 0 hits — the switch CG explicitly required to be reconciled was entirely absent from the "revised" doc. The author updated the narrative but never put the required model in. One grep caught a silent gap.
3. Confirm demanded documents exist at all. Sometimes a deliverable CG named (e.g. Control System User Interface & Fault Monitoring.pdf) simply is not in the package. find -iname "*user*interface*" -o -iname "*fault*" before claiming it was submitted.
4. Classify each comment: COMPLIED / PARTIAL / NOT-COMPLIED. A comment is COMPLIED only if the concrete demanded artifact is present AND named in the text. "Added a VLAN scheme but no port count/PoE/rack-allocation" = PARTIAL, not complied.
5. Forecast the CG verdict from the compliance profile, not optimism:
   • If docs moved off pure-generic (named hardware, some schedules) but core engineering demands are still missing -> forecast C (not D), because the package is no longer "generic guidance."
   • The killer gap that forces C is usually a document CG explicitly asked for that is entirely absent (e.g. the control-UI/fault-monitoring doc) plus an explicitly-named item that never appears (Zyxel switch).
   • Only procedural comments (proper format, signed/stamped) are reliably closed in a Rev. Expect the C rejection to re-quote the still-open comment, not re-reason.
6. Timing: CG review window ~14 working days; a partial Rev returns C with the same comments still Open — a third round. Do not submit a package with PARTIAL/NOT-COMPLIED blocks open; route back to the specialist (Rawasin) to supply the actual engineered deliverables.

QC of a specialist's first-issue package (ZNA lighting case, 2026-08)

When QC'ing a specialist's newly-issued design package (lighting, AV, showcases) BEFORE submission to CG, the recurring over-flagging errors to avoid:

Drawing numbering to enforce on specialists (lighting, per the tracker): the project reference is MOC-ASE-{Disc}-{System}-{Type}-{Floor}-DDD-{Seq}, e.g. MOC-ASE-EL-ELT-LL-BF-DDD-30001-00 (Electrical · Lighting · Layout · Basement). Specialists (ZNA) often issue with their OWN office numbering (ZNA3297_LG002_*) even though their DWG xrefs use the project codes. Also require uniform Rev + current date across every sheet of one issue (one package had LGF-HL=V2, others V0/V1, and a GF-LL sheet dated 21/01/2025). Full worked case: references/zna-lighting-qc-case.md.

Recurring Pattern: Resubmitting Without Closing CRS Comments

This is a documented recurring issue on this project. Instances:

• Structural DD (1C0-1G-0001) — Code C twice, 15 comments all Open both rounds
• PEP (ZD-0086) — Code C twice, 26 comments all Open both rounds
• DMP — Code D then C, comments partially addressed

Root cause in every case: the CRS Originator Reply column was left empty or contained explanations instead of physical evidence. CG returned Rev.01 with all comments still Open. The CG's note "The CRS reply is missing from SAMAYA side" confirms the pattern.

Prevention — CRS closure check before any resubmission:

1. Every CG comment MUST have a response in the Originator Reply column
2. Responses MUST be physical evidence (test reports, approved drawings, completed studies) — not explanations, references, or "under preparation"
3. Any item still pending must be explicitly deferred in a cover note with a commitment date
4. Internal QA review must be completed and signed off before submission

Red flag: When the PM says "Please review and confirm" before submitting — it means CRS responses are not yet finalised. Hold submission until all items are confirmed.

When you receive a CG CRS (Comments Resolution Sheet) for a submittal, do not forward the raw CRS to the designer. Filter comments by responsible party first.

Triage Categories

Triage Rules

• Cloud survey / survey-related comments are Samaya's responsibility, not the designer's. Acknowledge as pending in your response to CG. Do not forward to NRS.
• Title blocks, QA notes, sheet layout standards ARE on the designer (they produce the drawings). Forward these to NRS.
• Doors/stairs shop drawings (#13) are contractor action — the designer provides design intent, contractor produces shop drawings.
• Setwork details and graphic housing (items #83-99) are specialist sub scope, not NRS — handle separately.
• B-status per-drawing comments ("See General Comments") are typically contractor action unless the general comment itself is design-related.
• Verify which floor(s) the CRS covers by checking drawing number prefixes (BF=Basement Floor, LG=Lower Ground, GF=Ground Floor). The document title may say one floor only. Do not assume multi-floor coverage.
• Demolition comments (#11-12, #15-16) are contractor action — demolition methodology, ceiling removal clarification. Do not forward to NRS.
• Sections missing dimensions/room names (#140-143) ARE on the designer — they produce the section drawings. Forward to NRS.
• Floor/ceiling scoping comments (#19-20) about space labeling (FFL/CIL), finishes schedule format, expansion joint treatment ARE on the designer. Forward to NRS.
• Do NOT lump Samaya gaps into a vague "etc." in the forwarding email — be specific about what Samaya handles (cloud survey pending, demolition methodology, mock-ups, material samples, BIM coordination) so the designer knows exactly what is not their problem.
• When the user corrects your triage (e.g. "title blocks is on jim"), fix the email immediately — do not argue. The user knows who produces what.

Forwarding Email Template

Subject: NRS Input Required — [CRS NUMBER] ([Floor])

Dear Jim,

CG returned the CRS for the [Floor] [Discipline] DD submittal (overall C). We are preparing our response and will address the items on our side ([list Samaya gaps]) directly with CG.

The following items need NRS design input:

[Section heading]:
- #[N] — [brief description]
- #[N] — [brief description]

Please review and advise so we can prepare the resubmission.

Regards,
Mohamed Sultan

CRS Email to NRS — What NOT to Include

• Do NOT list contractor-side items (cloud survey, mock-ups, material samples, BIM coordination, demolition methodology) as NRS action items
• Do NOT ask NRS to fix things that are Samaya's responsibility
• Do NOT include the full raw CRS — only the filtered NRS-relevant items
• Do NOT use the CRS email to also discuss unrelated topics (visuals, invoices, etc.) — keep it focused

Design Study Folder Structure

When NRS submits a design study in response to CG/Ministry requests, file it under a dedicated 12_Design_Studies/ folder:

Aseer-Museum/
+-- 12_Design_Studies/
|   +-- 01_Object_List/          (object schedule files)
|   +-- 02_New_Study/            (future studies)
|   +-- 03_Study_01/
|       +-- MOC-ASE-AR-ARC-GEN-DDD-DS01-00_DRAFT.pdf   (NRS study PDF)
|       +-- G12_Structural_Assessment_Template.docx     (team templates)
|       +-- G12_Logistics_Method_Statement_Template.docx

The study PDF is extracted from Outlook via AppleScript. Team action templates (structural assessment, logistics method statement) are generated as Samaya-branded DOCX and placed alongside the study.

Pitfalls

• Plan vs Register distinction — When CG returns Code C on a management plan (RMP, SMP, DMP, etc.), not all comments are valid. Some ask for operational data that belongs in live registers, not the plan itself. Before complying, ask: "Is this methodology or data?" If data (risk scores, P6 IDs, specific risk entries, register snapshots), push back — the plan is methodology, the register has the data. The user explicitly confirmed this position after initially agreeing to comply. See references/rmp-cg-response-patterns.md for the full worked example.
• Defend original design decisions — When you validated the user's approach (e.g., different scoring scales per register is fine per PMBOK), and CG challenges it, defend the original design. Don't flip positions and immediately change the plan. The user will correct you. The correct response: acknowledge CG's preference, explain the PMBOK basis, offer to document more clearly (not change), no rescoring.
• No placeholders in formal submissions — Never submit a plan with "To be recalculated", "To be confirmed", or any other placeholder text. CG will flag it as incomplete. Either include real data or remove the section entirely with a clear statement that it will be completed when inputs are available. The user explicitly corrected this: "ليه حطيتهم من الأول" — placeholders are worse than omitting the section.
• Never add unapproved names to documents. If a person's name hasn't been formally approved by CG/MoC (via CV submission, KPR update, or formal appointment), list the role only with a note: "Per live KPR" or "TBC — appointment pending." Adding unapproved names creates liability — CG will hold Samaya to that person's qualifications even if they were never formally accepted. The user explicitly corrected: "dont add names are not approved."
• Never merge submission plan comments with detailed technical reviews — they are two separate streams with different audiences and response formats.
• cat-row separators must use .cat-row td class (dark background, white text), not blank rows. Blank rows break table continuity.
• Status badges must be consistent: CLOSED (green), SUBMITTAL-PENDING (amber), IN-PROGRESS (blue), RE-OPENED (red). Don't invent new badge types mid-document.
• Round column must include both date and round number (e.g., "R2 . 2-Jun") for traceability across revisions.
• Verify which floor the CRS covers — CG often reviews one floor at a time. Check drawing number prefixes (BF=Basement Floor, LG=Lower Ground, GF=Ground Floor) in the CRS drawing references. The document title may say "Basement Floor" only. Do not assume a CRS covers multiple floors unless explicitly stated. When forwarding to the designer, name the correct floor in the subject line.

CRS From a Specialist's "Audit Response" Workbook (Rawasin / AV-style)

When the CRS input is a specialist's own response workbook (e.g. Rawasin's Audit Response.xlsx for AV Package Part II), NOT a CG CRS form, build the Samaya CRS from it. Source layout:

• Two sheets: 1st Submital responce and 2nd Submital responce. (note trailing dot + space in sheet name — read by exact title).
• Each comment is two stacked rows: CG comment (verbatim) in the first B-cell, then the specialist's reply in the next B-cell. The No. appears only on the first row. Iterate row-by-row collecting pairs — do not assume one comment per row.
• The specialist's reply is the Originator Reply; keep the specialist's substance (Samaya may reframe wording). Never put Samaya-internal commentary (cost, schedule risk) in the reply column.
• Assign the CRS doc ref from the underlying submittal (e.g. AV Part II = MOC-MUS-ASE-1E0-1G-0002). Confirm the ref + prior CG code from the submittal register (this package was Code D then Code C).
• Pre-submission status convention: mark items Open (red) that still need resolution before CG submission, Closed (green) only for genuinely complete ones. The CRS is presented to the user for review and is NOT submission-ready until the Open blockers are cleared. Do not send to CG/specialist without user approval (user review gate).
• Committing .xlsx to the aseer-museum-pm repo requires git add -f (the repo .gitignore blocks binary xlsx); the post-commit webapp-regen hook dirties 06_Risk_System/webapp/ — git checkout -- those before pushing.

CG-Proposed Material Change — Control Lever (user strategy, Aseer flooring 2026-08)

When CG (or a CG reviewer) proposes substituting a specified material/finish, treat it as a control lever, not a commitment:

• Samaya (the D&B contractor) is NOT obliged to implement a CG-proposed substitution — CG proposals are suggestions/flags, not decisions (consistent with the NRS patinated-brass rule).
• Route the proposal to the design authority (NRS/Jim) for a technical opinion — that opinion becomes Samaya's reference point.
• Design authority rejects → Samaya closes it citing the technical reference.
• Design authority approves → Samaya can STILL reject from its own side for schedule/scope reasons. The opinion is ammunition, not a mandate.
• Precedent risk: each approved substitution opens the door to many more, and every change costs time + sample approval + schedule pressure (already tight). Treat a single material change as a gateway to be controlled, not rubber-stamped.
• User prefers local suppliers (e.g. Sheed, sheedsa.com) over imports for substitutes — reduces import lead time/approval friction.

Supplier Technical Rebuttal — When CG Demands Alternatives

When CG rejects a material submittal (Code C) and demands "3 alternative suppliers" but the supplier has already provided a technical rebuttal:

Check Outlook first

The supplier's reply often sits in an Outlook folder (not the project submittal folder). Search by:

• Submittal ref (MA-NNNN) in subject
• Supplier PM's email address
• Date range around the CG rejection date

SQLite query pattern:

SELECT m.Record_RecordID, datetime(m.Message_TimeReceived, 'unixepoch', 'localtime'),
       m.Message_SenderList, m.Message_NormalizedSubject, substr(m.Message_Preview, 1, 500)
FROM Mail m JOIN folders f ON m.Record_FolderID = f.Record_RecordID
WHERE m.Message_NormalizedSubject LIKE '%MA-0006%'
   OR m.Message_NormalizedSubject LIKE '%Glasbau%'
ORDER BY m.Message_TimeReceived DESC;

Extract attachments

Use AppleScript osascript to extract the supplier's reply sheet + manufacturer datasheet from the email. These are the two key documents.

Build the argument

1. The "3 suppliers" demand was based on the initial non-compliant submission
2. The supplier has now proven technical compliance (datasheet + comments reply)
3. Request CG to accept single supplier with technical justification
4. If CG insists, then source 3 alternatives — but the supplier's existing reply is the strongest negotiating position

Email evidence in CR Sheets — reference only, no .txt files

When citing email correspondence in a CR Sheet:

• Do NOT include .txt files of email threads in the support folder
• Do NOT include raw email text in the CR Sheet body
• Reference by date and sender only — e.g. "Glasbau Hahn reply 29-Apr-2026", "NRS Jim Richards 19-Jun-2026"
• If a printed PDF of the email exists (e.g. from Outlook print-to-PDF), include that in the support folder instead
• The CR Sheet is a formal document — email body text is not appropriate content

Resubmission support folder

Build a structured folder at the subcontractor's submittal directory:

MA-NNNN_Rev01_Support/
+-- 01_CG_Rejection_Code_C/
+-- 02_Supplier_Technical_Reply/
+-- 03_Manufacturer_Datasheet/
+-- 04_Supporting_Data_Sheets/     (flat — no subdirs)
+-- 05_PQ_Approval/
+-- 06_Sample_Board/
+-- 07_Related_Submittal_Support/
+-- 08_Email_Thread/               (outside support folder — for CG)
+-- 09_Resubmission_Checklist/     (outside support folder — for CG)

CR Sheet structure for material resubmission

Real-world CR sheets are longer than 5 items. PQ (prequalification) conditions carry forward as additional CR rows — they were never closed by the original Rev.00 MA submission. For the full 10-row MA-0006 Rev.01 pattern (with PQ-0063 conditions 1/2/5/6) and the canonical file locations, see references/ma-0006-showcase-resubmission-case.md sections "Full 10-Comment CR Sheet Structure", "Canonical File Locations", and "Rev.01 Status".

Look & Feel Approval Strategy

When supplier test reports/certifications take time (supplier lead time), but the visual sample is ready:

1. Request CG to approve LOOK AND FEEL now — visual appearance, colour, texture
2. Test reports & certifications to follow once received from supplier
3. Alternative samples from local suppliers in parallel
4. Submit outstanding docs as Rev.01 addendum within 30 days

Separate Submittal Principle

Do not block one submittal because a related submittal is pending. Example:

• MA-0006 (showcase materials: glass, silicone, fabric, Corian, lighting, powder coating) — independent of brass
• MA-0007 (patinated brass) — separate submittal, separate rejection
• MA-0006 Rev.01 can proceed without MA-0007 approval

Track A/B Separation — When CG Blocks Over a Finish Material

When CG rejects a submittal (Code C) specifically over a finish material issue (e.g., patinated brass), and the supplier confirms the material is single-source or high-risk, split the response into two independent tracks:

When to use this pattern:

• CG rejects a submittal over a finish material that is a small fraction of the overall scope
• The supplier confirms the finish does not affect fabrication/production
• The finish material has long-lead testing (Oddy, fire, VOC) that will take weeks
• The shop drawings are otherwise ready for approval

Email framing for Track A/B:

We have split the approval process into two independent tracks:

Track A — Shop Drawings (not affected by finish material):
- [Supplier] has confirmed the [finish] is a surface finish only and does not affect fabrication.
- We request CG to proceed with shop drawing approval independently — this is the critical path for production lead time.

Track B — Finish Material (MA-0007):
- Oddy testing in progress — results expected [date].
- In parallel, developing [alternative] from local suppliers as lower-risk substitute — sample within 30 days.
- This can serve as the alternative manufacturer option you requested.

When the supplier advises AGAINST their own material (GBH Letter 002 pattern):

If the supplier's formal letter states they do NOT recommend the specified material:

1. This strengthens the Track A/B argument — the supplier themselves says the finish shouldn't block fabrication
2. Use the supplier's own words as evidence: "GBH has requested that patinated brass approval NOT hold shop drawing approval"
3. The supplier's technical objections (single-source, colour inconsistency, conservation risk) become Samaya's evidence for proposing an alternative
4. Update the CR sheet to reference the supplier's letter as a new supporting document
5. The response shifts from "we're working on it" to "this material is high-risk, we recommend alternative path"

Handling CG's "2 alternative manufacturers" demand when supplier confirms single-source:

When CG asks for 2 alternative certified manufacturers but the supplier's letter confirms only 1 supplier exists globally:

• Frame it as GBH's market finding, not an absolute fact. Say: "GBH conducted a market search and identified only one supplier capable of producing it to the required museum standards." Not "only one supplier exists globally" — CG may challenge that claim.
• CG likely wants to see options to choose from, not supply from multiple sources simultaneously. Frame the response accordingly: "This gives you multiple options to review and select from."
• Single-source argument for finish consistency: Patinated brass is specified across multiple project elements (showcases, wayfinding, doors, wall cladding). To guarantee colour and texture consistency, all must come from a single supplier. Different suppliers = visible variations due to the manual patination process.
• Propose alternatives in a DIFFERENT material category (e.g., PVD-coated brass instead of patinated brass)
• Reference the risk register entry (e.g., PRR-PRC-05, Score 12, Critical) to show the risk is already tracked
• Offer: "Samaya will source [alternative material] alternatives from KSA suppliers as a functionally equivalent, lower-risk substitute — samples within 30 days."

Alternative submittal package scope: When offering a PVD-coated or other alternative, the full submittal package must include: sample, manufacturer certificates, and test reports — not just a visual sample. State this explicitly in the email: "Full package to be submitted within 30 days including sample, manufacturer certificates, and test reports."

Do NOT recommend accepting an alternative before it's submitted. Never say "recommend CG accept X as primary path" when X is still in development. Say "to be submitted for CG review" instead.

Email composition — which email to reply to and what to attach:

When CG sends a follow-up email (e.g., Mansour's 13-Jul reminder asking for 2 alternative manufacturers), reply to THAT specific email, not the original rejection. Attachments:

1. Updated CR Sheet — reflecting the new information (GBH letter, Track A/B split, alternative proposal)
2. Supplier's letter — the document that confirms single-source or advises against the material (e.g., GBH Letter 002)

Do NOT attach the original submittal PDF, sample board photos, or data sheets — those were already submitted. The reply is a status update + proposal, not a full resubmission.

Email structure for this scenario:

Subject: RE: [Original Subject]

Dear Eng. [Name],

We received [Supplier Letter Ref] from [Supplier] regarding [topic]. Risk [Risk ID] (Score [N], [Rating]) already registered.

On your request for 2 alternative manufacturers:
[Supplier] searched the market and found only one supplier for this finish. We also contacted [country] suppliers — samples with certificates expected within [timeframe]. A [alternative] is also in development (full package within [timeframe]). This gives you options to choose from, while ensuring the final finish is applied consistently from one source across all project elements.

Current samples submitted:
1. [Material A] — [N] effects under [Submittal Ref]. [Status].
2. [Material B] — [description] already submitted.
3. [Mater

*Truncated - read the full file at https://github.com/sultandroid/hermes-memory/blob/14e283ef6f541df0670bad33b8a1f5de9d5aa984/skills/project-management/cg-response-protocol/SKILL.md.*