The Pod of Conviction

Owner: Luke

Revised after further material arrived. The 113-page Confluence export resolves four of the seven could-not-verify items from the first pass: spend is now fully accounted (€1,242.21 of the €1,500 cap — the $1,740 tracker budget is the cap expressed in USD, and top-ups minus balance reconcile with consumption), a genuine daily record with partly verifiable write-times exists, a 40+-item known-issues log and a sharply self-critical retrospective replace the 'no self-assessment' finding, and the handover documentation gap is largely closed. Efficiency (6→8), candour (4→7), documentation (5→7), ai_usage (6→8) and process (6→7) move on that evidence; total 71→81. Nothing in the pages touches the code-level findings, so acceptance, security, code, testing, architecture, deployability and model_choice stand — including the committed credentials and cross-tenant IDOR, which remain undisclosed even in the pod's own bug log. Two new rule-2 mentions (Gemini in the 25 Aug demo notes, a disclosed-and-corrected external-AI incident on 21 Aug) are raised as questions, not findings.

What this artifact can and cannot show. The 113 Confluence pages and 70 attachments come from the pod's PBR workspace. Access was provided by the pod on time; the assessment fetched the content rather than receiving it as a file. The sponsor has ruled this a delivery on time, and it is not held against the submission. The pages carry Confluence created-at dates and version numbers, so write time is partly verifiable — better cadence evidence than a zip export can supply, which is a difference in what each artifact can show rather than a demonstrated difference in how the pods worked.

A six-repo submission centred on a Spring Boot backend driving a Telegram-first campaign flow, two React portals, a genuinely operable IaC/GitOps estate, and an AI-driven QA framework — now paired with a 113-page Confluence record (PBR space, 'NGAIGE POD 2') that supplies most of what the repos lacked: automated daily spend reports with EUR conversion, a reconciling financial ledger showing €1,242.21 spent of the €1,500 cap, dated meeting journals, a 40+-item bug log filed against their own system, and an unusually self-critical retrospective. The engineering is real and verifiable (143 backend tests green, two-layer opt-out, human-only dispatch), and the documentation gap that dragged the first assessment down is largely closed. What still stands against it: a committed .env with live-shaped stack credentials, a live ngrok authtoken in a README, cross-tenant IDOR on dispatch and reporting, and item F implemented as an unsubscribe link rather than the STOP keyword — the last now shown to be a documented product decision, the security findings still undisclosed anywhere in the pod's own record.

81 / 100 scored

Tokens and spend, as the pod reported them

Tokens reported	1,009,989,029
In / out	1,005,576,834 in · 4,412,195 out
Spend reported	$1,446.30 ≈ €1,242.21 · 83.1% of budget
Models named	GLM-5.2 on the pod's RunPod instance; qwen3.6-35b-a3b and faster-whisper served through their own LiteLLM

Source: Confluence daily report of _2026-08-3 — GLM-5.2 utilisation table, 7 days counted once each (the reports are cumulative, so only the latest is used). These are the pod's own figures, not measurements by this assessment. Cap: €1,500 per pod.

Token counts cover GLM-5.2 only; usage of the other served models is not separately reported.
Telemetry begins 17 Aug; the trial started 10 Aug.
Infobip cost (~€10) appears in prose in the retrospective but is not itemised in the financial ledger.

Effort — stated against demonstrable

Hours stated	not reported
Commits	458 across 6 repo(s), 5 authors
Active days	14 days, 2026-08-16 to 2026-08-31 · busiest 2026-08-27 (98)
Commits inside the 3-hour window	21.0%

Bare git repositories with full history, so commit timing is verifiable — but a commit is not an hour. The profile below bounds when work happened, not how long it took.

The retrospective states hours were not tracked (2022604817_28.08.2026_Sync_Up_with_Kevin.md).

A commit is not an hour and a commit count is not effort. This bounds when work happened, not how long it took, and no score is derived from it.

Prompt craft 5 / 10

The strongest individual prompt documents sit next to the weakest evidence trail. The in-repo artifacts are genuinely good: prompt.md and APP_GENERATION_PROMPT.md carry hard constraints (exact stack, 'Do not use Vite', 'Do not create mock APIs', forbid hardcoded secrets, lint/build must pass) and are the most directly reusable prompts any pod submitted; FULL_PROMPT is a serious 673-line master spec iterated to version 8 by 20 Aug. But almost none of it is a record of actual sessions. The .junie history's own header says its 23 prompts were 'written as natural human developer questions' and it stops on 20 Aug though backend work ran ten more days; the Confluence prompt library, created 30 Aug, states its activity log was 'reconstructed... not a verbatim transcript'; and every one of its 21 library prompts exports as an empty '[code block]' placeholder, so the library's actual text is not in the submission. Honesty lives in the retrospective (the '30-40% problem', 3.5 days of rework from unshared prompts) rather than in the prompt logs, which is honest about outcomes but leaves iteration invisible.

best — submissions/pod2-conviction/repo/ngaige-mno-portal/prompt.md
Do not create mock APIs, fake API services, random data generators, or simulated backend behavior. ... build the UI and typed API service contract, but show a proper empty or error state.
weakest — submissions/pod2-conviction/docs/confluence/2024800260_AI_Prompt_Library_and_Prompt_Logs.md
reconstructed from the project requirements, prompt documents, source structure, and implementation history. It is a work log, not a verbatim transcript of every AI conversation.
weakest — submissions/pod2-conviction/repo/ngaige-be-app/.junie/prompts_history.md
All entries are ordered chronologically time-descending (newest first) and written as natural human developer questions.

Assessed separately from the twelve categories: the trial's question was how each pod worked with models, and the prompts are the record of that.

Flagged for a second look

Things a reader would want to know. Not findings against the submission and not scored — questions, oddities and loose ends.

All 13 prompts in the 'Prompt Library' and all 8 in 'Detailed Frontend and Backend App Prompts' export as '[code block]' placeholders, so the actual text of the pod's flagship prompt library is absent from the submission.
submissions/pod2-conviction/docs/confluence/2024800260_AI_Prompt_Library_and_Prompt_Logs.md
The prompt library and its detail page were both created on 30 Aug, one day before the deadline, and the library's own text concedes the day-by-day activity log was 'reconstructed' rather than transcribed.
submissions/pod2-conviction/docs/confluence/2024800260_AI_Prompt_Library_and_Prompt_Logs.md
A session-log schema promising per-session model, GPU configuration, cloud cost and token usage was defined on 13 Aug, but no session log matching it exists anywhere in the submission.
submissions/pod2-conviction/docs/confluence/1987477532_AUTOMATED_AI_SESSION_LOG.md
The backend prompt history stops on 20 Aug even though daily reports show backend work continuing through 30 Aug, leaving the final ten days of backend AI usage unrecorded.
submissions/pod2-conviction/repo/ngaige-be-app/.junie/prompts_history.md
The retrospective records that one member 'doesn't fully trust AI' and 'was using a lot of traditional methods', so part of the codebase in this AI-first trial was hand-built, with no way to tell which part.
submissions/pod2-conviction/docs/confluence/2023849987_AI-First_Development_Experiment_Pod_Retrospective.md
The retrospective reports 'silent failures: AI reported fixes in its summary that were not actually applied to the code', a defect class no prompt log or session record captures.
submissions/pod2-conviction/docs/confluence/2023849987_AI-First_Development_Experiment_Pod_Retrospective.md

Repository	gitea.ngaige.haud.report (6 repos, tarball received 31 Aug)
Received	repos 31 Aug 10:30 CEST · Confluence workspace retrieved 31 Aug 12:30 CEST

Assessment by category

Acceptance coverage

partial6/9

Do items A–F actually work, on demand, without the pod driving?

Judge justification

Unchanged — mechanisms exist for all six items and the code findings stand: F honours an unsubscribe web link rather than the STOP keyword (BUGS item 41, 26 Aug, now shows this was a deliberate product decision — 'The system should include the unsub link'), cost per campaign is absent (EnterpriseService.java:581-585 hardcodes zeros, and BUGS item 72 confirms credit-per-SMS is miscalculated), and scheduling never fires (BUGS item 75, still marked incomplete: 'we need to have at least 1-Time schedules Broadcast working'). The pod's own 28 Aug testing corroborates the mechanism for F ('OPT out is successfully working', item 70) and records that delivery reports were initially not delivered (item 69, later marked complete). Live end-to-end behaviour still could not be exercised here.

What would make this better

Add an inbound MO webhook that treats a STOP reply as an opt-out (or get the deviation formally accepted), finish the one-time scheduled broadcast, and compute per-campaign cost from dispatch logs instead of the hardcoded zeros.

What this category looks for

A onboard SME: business name, sender ID, consented recipient list
B campaign created conversationally through the Telegram POC
C engine drafts the plan and a human must approve before dispatch
D dispatch to 50+ test MSISDNs, delivery receipts ingested
E report of sent / delivered / failed / cost, reproducible by script
F STOP honoured, opted-out excluded from the NEXT send

C and F are refusal properties — the system must decline to do something. A demo can look perfect with the mechanism absent, so these are probed adversarially rather than asked about.

Architecture & technology

solid7/8

Are the technology choices ones you would defend in six months?

Judge justification

Unchanged — defensible choices throughout: Spring Boot modular monolith with pluggable channel and SMS-gateway adapters, Flyway, Redis state cache, OpenAI-compatible client against their own LiteLLM, and an infra estate that would survive a six-month review. The Confluence infrastructure pages (8 maintained pages, versions 8-10, created 20-23 Aug) confirm the host-communication design was documented as it was built. Weak spots stand: fat Telegram handler classes and a SCHEDULED state with no executor behind it.

What would make this better

Split the Telegram handlers into flow-specific services and either implement or delete the SCHEDULED execution path so the state machine matches reality.

What this category looks for

Component boundaries match the problem, not a framework's defaults
Dependencies justified; nothing heavy pulled in for a few lines
The orchestrator / engine split is real, not cosmetic
Failure paths considered: what happens when the gateway is down
Choices explained somewhere, not just made

Novelty is not a virtue here. Boring and correct beats clever and unexplained.

Code quality

partial6/8

Could a new engineer change this safely next week?

Judge justification

Unchanged — consistent style, sensible enums/DTOs, validation at the onboarding boundary, and a green suite make routine change safe, but handleBroadcastExecution (CampaignCommandHandler.java:637-693) still fetches any campaign by ID with no ownership check or status precondition, ReportCommandHandler.java:55-71 has the same cross-tenant read, and exceptions are swallowed in several handlers. Nothing in the Confluence record contradicts or acknowledges these.

What would make this better

Add a campaign.getClientId().equals(client.getId()) guard plus a status precondition (only DRAFT/APPROVED may dispatch, never DISPATCHED again) at the top of handleBroadcastExecution and the report handler.

What this category looks for

Readable without a guide; naming that matches the domain
No large copy-paste blocks or dead speculative abstraction
Errors handled where they occur, not swallowed
Consistent style across the codebase, including AI-written parts

Volume earns nothing. A small codebase that does the six things beats a large one that does four.

Testing & verification

partial6/8

Do the tests prove the acceptance items, or just exercise code?

Judge justification

Unchanged in score — 143 backend unit tests verified green, strong onboarding coverage, honest xfail-annotated QA execution logs; still no test proving opt-out-then-second-send or approval-gate refusal. The Confluence 'Tests and Verification Evidence' page (30 Aug) claims 46 passing React Testing Library tests for the MNO frontend and green builds across repos, and the retrospective admits plainly that the final QA cycle was never executed (tester unavailable in week 3) — that admission is credited under candour, but the frontend test claims were not run here and cannot move this score.

What would make this better

Add one test that unsubscribes a subscriber via token, runs dispatchCampaignWithMetrics again, and asserts the MSISDN is absent from the gateway calls, plus one asserting a DISPATCHED or cross-tenant campaign ID is refused.

What this category looks for

Tests exist, run from a clean clone, and pass
The refusal properties (C, F) have tests of their own
Verification evidence beyond unit tests: scripts, fixtures, logs
A failing test would actually catch a real regression

Coverage percentage is not read. A single test that proves STOP excludes on the next send is worth more than 80% line coverage.

Deployability & operations

solid7/8

Clean clone to running system, following only the written steps.

Judge justification

Unchanged — ngaige-product-deploy remains a genuine clone-to-running runbook backed by CI auto-deploy with health verification; the retrospective corroborates it honestly ('runnable, deployable' per the 28 Aug Kevin sync, 'though tested only locally behind VPN', not production-ready on security/certificates/scaling). Could not be executed here, and the runbook's reproducibility still partly rests on the committed live .env.

What would make this better

Replace the committed .env with a documented secret-provisioning step so the runbook works without shipping live credentials in git.

What this category looks for

One documented command, or a short documented sequence
Configuration and secrets handled sanely; .env.example present
It actually starts — verified, not asserted
Teardown, logs and health checks exist

This is scored by doing it. The result is binary and unkind: either the written steps produced a running system or they did not.

Documentation & handover

solid7/8

Could HAUD take this over without the pod in the room?

Judge justification

Raised from 5: the 113-page Confluence space closes most of the handover gap — a 29.6k-char PRD, 8 maintained infrastructure pages, PWA and MNO-portal developer documentation (created 26 Aug, during the build), ten LLDs, a QA execution guide with a new-engineer setup section, a Telegram-bot delivery/handover report mapping acceptance items to code locations, a user manual, and a project synopsis distinguishing charter items from extras. HAUD could now take over infra and most of the product without the pod in the room. Held from 8 because the product repos' READMEs remain near-empty (the documentation lives off-repo), the seven-point submission document still does not exist as such, and the LLDs were generated in a single AI pass on 30 Aug.

What would make this better

Mirror the Confluence developer docs into each repo's README (even as links plus a one-page summary) and assemble the seven-point submission document from the synopsis and retrospective, which already contain most of its content.

What this category looks for

The submission .md answers all seven requested points
Claims cite where in the repo the implementation lives
Each claim says how to reproduce or test it
A runbook for operating it, not just a README for reading it

The bar is the client-bound mainline: would you hand this to someone who has never met the authors?

AI usage & prompt craft

solid8/9

The A/B payload — how the pod actually worked with models.

Judge justification

Raised from 6: on top of the 3,335-line portal prompt suite and 23 timestamped backend prompts, the Confluence record supplies a real A/B payload — a 13-pattern prompt library with a dated activity log (10-28 Aug, honestly labelled 'reconstructed... not a verbatim transcript'), daily per-user per-model token telemetry, and a retrospective that analyses how the pod actually worked with models: the '30-40% problem' of AI-reported-but-unapplied fixes, the fragmented-prompting root cause costing 3.5 days of rework, the PWA-in-one-hour full-prompt experiment as a controlled comparison, and a GLM/Qwen/GPT-OSS model comparison. Held from 9 because the AUTOMATED_AI_SESSION_LOG remained an unfilled template, the backend .junie history still stops on 20 Aug, and the per-session kept-vs-redone record exists only at project level.

What would make this better

Populate the session-log template you designed on 13 Aug — even a few real entries per week would turn the reconstructed activity log into a verbatim record.

What this category looks for

Prompt library or logs present and legible
Which models, used where, and why those
Evidence of iteration: what was kept, what was redone
Token usage per model where recorded
Human review of model output visible in the history

This is the whole point of the trial. A pod that shipped well but cannot show how it used AI has answered the wrong question.

Process & decision evidence

solid7/8

Decision log and daily journal — kept as work, not written on the 30th.

Judge justification

Raised from 6: the Confluence record supplies contemporaneous cadence the repos could not — page creation dates spread 13-31 Aug, daily reports auto-published the following morning (the 17 Aug report was created 18 Aug), the BUGS page created 26 Aug and versioned 31 times, dated meeting journals for most working days with attendees, achievements and difficulties, and decisions recorded where they were made (e.g. the activation-date logic ruling inline in BUGS items 59-60). The journal pages are meeting minutes rather than the strict rule-6 format (no per-day kept/redone or impediment time-lost fields; the retrospective covers those at project level), several dated entries for 11-21 Aug were backfilled on 25-26 Aug from recordings, and no repo carries a freeze tag.

What would make this better

Tag the freeze commit in each repo, and next time capture the rule-6 fields (kept/redone, impediment category-owner-time-lost) in the daily page rather than reconstructing them at the end.

What this category looks for

Decisions recorded with their reasoning and their date
Journal entries across the working days, not backfilled in a burst
Impediments logged with category, owner and time lost
Rework recorded honestly, including what was thrown away

Entries dated across fifteen days read differently from fifteen entries committed on the last afternoon. The git history shows which.

Candour & self-assessment

solid7/9

The requested LLM assessment, and whether it tells the truth.

Judge justification

Raised from 4: a known-issues record now clearly exists and it is honest. The BUGS page logs 40+ defects against their own system including 'We do not have delivery reports (this is part of the charter requirement)' and the still-open scheduling failure; the retrospective names the pod's biggest failure itself (fragmented prompting, 3.5 days of rework), quotes members admitting problems, concedes the 3h/day charter 'was not followed' with 'zero visibility into actual effort', discloses the unexecuted final QA cycle, states 'not production ready' on security, and records the 21 Aug external-AI compliance incident and its correction. Held from 9 because the sharpest risks in this submission — the committed .env, the ngrok authtoken, the cross-tenant IDOR — are disclosed nowhere in the pod's own record, and the honesty is scattered across pages rather than gathered into the required self-assessment.

What would make this better

Write the self-assessment as one document and have it name what the retrospective missed: the committed credentials, the ngrok token, and the missing ownership checks on dispatch and reporting.

What this category looks for

The LLM-generated assessment is present
It names areas where evidence is weak or the requirement is unmet
Known issues, limitations and shortcuts are listed specifically
The self-assessment matches what the repo and probes actually show

A submission that names its own gaps is more trustworthy than one that claims six of six. Overclaiming found by probe is scored here, and it is the most damaging single finding a submission can carry.

Model choice & sovereignty

solid8/8

Which models, were they the right ones, and did they respect the boundary?

Judge justification

Unchanged — product runtime on self-hosted qwen3.6-35b-a3b and faster-whisper via their own LiteLLM (application.yaml:64-68), dev/QA on GLM-5.2-int4 on RunPod, no third-party model found in product source, and the daily reports now confirm the story with per-key per-model token counts. Two new mentions are cited as questions per rule 2, not as findings: the 25 Aug demo notes list 'models used (Whisper, GLM, Gemini)' for the Telegram bot, and the 21 Aug minutes record 'AI usage compliance issue — Akhilesh using external AI. Luke mandated: stick to pod GLM' — a dev-side incident the pod disclosed and corrected itself.

What would make this better

State explicitly in the submission doc which model served each product path, and address the Gemini mention in the 25 Aug demo notes head-on.

What this category looks for

Models named specifically, with versions — not 'an LLM'
Product code and trial data touched self-hosted open weights only
Third-party APIs, if used, stayed on the platform layer (rule 2)
Model choice fits the task: a frontier model where it earned its cost, a small one where it did not
The issued rig was actually used, not idled while work went elsewhere

Newest is not best. The scored question is fit and boundary, not leaderboard position. A pod that ran a mid-tier open model well scores above one that reached for a frontier API it was not permitted to use. A rule-2 breach is a finding here regardless of how good the output was.

Token & spend efficiency

solid8/9

What the budget bought — EUR 1,500 per pod, hard, every euro logged.

Judge justification

Raised from 6: the figures the repos lacked are now delivered and they reconcile. The $1,740 tracker budget is the €1,500 cap expressed in USD (€1,494.47 at the 28 Aug ECB rate of 0.85889, €1,500.91 at the 17 Aug rate — the fixed USD figure straddles the cap by under a euro either way). Actual consumption was $1,446.30 ≈ €1,242.21, 83.1% of budget and comfortably inside €1,500; top-ups of $1,550.00 minus the $103.45 remaining balance match consumption to within rounding, and ~€10 of Infobip SMS spend is disclosed in the retrospective. The record is per-day, per-service, dual-currency at dated ECB rates, with GPU utilisation and $/1M-token efficiency analysed against it ('heavy AI usage does not automatically translate to working output'). Held from 9 because the Infobip spend appears only in retrospective prose rather than the financial log, token telemetry starts 17 Aug, and the 3h/day effort budget was — by their own admission — never tracked.

What would make this better

Add the Infobip line to FINANCIAL_LOGS and snapshot the final daily report into the repo so the spend story travels with the code.

What this category looks for

Token usage recorded per model, not guessed at the end
Spend logged as it happened, with the cap respected
Output per euro: what the money actually produced
Rented GPU hours matched to work — parked when idle, not left burning
Rework cost visible: what was regenerated and why

Underspending is not virtue and overspending is not vice; an exhausted budget is a workflow finding, not a failure. What is scored is whether the pod knew where the money went and can show it. A pod that spent the full cap and can account for it scores above one that spent half and cannot.

Security & data handling

partial4/8

Consent, opt-out, secrets and the sovereignty boundary.

Judge justification

Unchanged — real controls (default-on JWT interception, webhook secret validation, rate limiting, network-isolated data tier, two-layer opt-out) remain undermined by live credentials committed to git (full .env in ngaige-product-deploy; ngrok authtoken in README.md:125, commit 94a014b), cross-tenant IDOR on dispatch and reporting, an unauthenticated DLR webhook, and no consent capture on recipient upload. The Confluence record confirms security was consciously deferred ('Security and non-functional requirements deferred', retrospective §8) but discloses none of these specific findings, so the score stands.

What would make this better

Rotate every credential in the committed .env and the ngrok token today, purge them from history, and add the missing ownership checks and a DLR webhook shared-secret.

What this category looks for

Consent recorded on the recipient list, not assumed
Opt-out state durable and honoured across campaigns
No credentials committed; secrets loaded from environment
Trial data synthetic; sovereignty boundary respected
Sender ID and MSISDN handling sane

A campaign platform that leaks a recipient list or ignores an opt-out is not a product, whatever else it does well.

Excluded from assessment: ngaige-full-prompt (repository). Excluded at the pod's request: "Please do not look into the following repository ngaige-full-prompt since this was a test and I will explain during the presentation." Moved aside unopened before any check ran; never read, indexed or scored. Recorded because an excluded artifact is a fact about the submission.

Evidence

Category	Item	Where	Note
efficiency	Spend inside the EUR 1,500 cap, reconciled	`docs/confluence/2025586690_2026-08-30_-_Daily_Report.md`	Budget $1740.0 ≈ €1494.47 at ECB 0.85889 — the €1,500 cap in USD. Spent $1446.3 ≈ €1242.21 (83.1%). Top-ups $1,550.00 (1988755457_FINANCIAL_LOGS.md, 9 dated transactions) minus $103.45 balance ≈ consumption. Per-day GPU/CPU/storage in USD and EUR back to 13 Aug.
efficiency	Non-RunPod cost disclosed	`docs/confluence/2023849987_AI-First_Development_Experiment_Pod_Retrospective.md`	'Budget: $1,740 (RunPod GPU) + €10 (InfoBip SMS)' and 'Cost efficiency: Within budget'. Infobip pay-as-you-go ~€0.06/SMS, funded 24 Aug per the recap. Not itemised in FINANCIAL_LOGS.
efficiency	Per-model token telemetry, daily	`docs/confluence/2015854593_2026-08-25_-_Daily_Report.md`	Per LiteLLM key, per model, per day: e.g. awais-dev 162,382,839 tokens in on glm-5.2-int4-int8mix on 25 Aug; qwen3.6-35b-a3b broken out separately. GLM-5.2 pod utilisation with busy % and $/1M tokens. Coverage starts 17 Aug.
candour	Charter shortfalls disclosed in the pod's own bug log	`docs/confluence/2018902035_BUGS.md`	Item 69 (28 Aug): 'We do not have and delivery reports. (this is part of the charter requirement)... nothing is ever sent' — later marked complete. Item 75 (open): scheduling not working. Item 70: 'OPT out is successfully working'. Page created 26 Aug, version 31.
candour	Self-critical retrospective with named failures	`docs/confluence/2023849987_AI-First_Development_Experiment_Pod_Retrospective.md`	Names fragmented AI prompting as the biggest self-identified failure (3.5 days rework), admits 'zero visibility into actual effort; no evidence of 3hrs/day compliance', unexecuted final QA, 'not production ready' on security, and the 30-40% AI-reported-but-unapplied-fix problem, with attributed quotes.
acceptance	STOP-vs-link was a documented product decision	`docs/confluence/2018902035_BUGS.md`	Item 41 (26 Aug): bot was suggesting STOP replies; ruling was 'The system should include the unsub link'. Consistent with CampaignRecommendationService.java:134 instructing the model not to write 'Reply STOP'. A decision, but still a deviation from item F as written.
process	Contemporaneous cadence partly verifiable via Confluence metadata	`docs/confluence/_index.json`	113 pages with createdAt and version numbers spread 13-31 Aug: daily reports created next morning (17 Aug report created 18 Aug, v12), BUGS created 26 Aug. Caveat: several dated journal pages for 11-21 Aug were created 25-26 Aug (backfilled from meeting recordings), and later versions may postdate creation.
model_choice	External-AI incident disclosed and corrected; Gemini mentioned in demo	`docs/confluence/2026405895_NGAIGE_POD_2_Full_Project_Recap_Progress_Timeline_11_30_Aug_2026_.md`	21 Aug: 'AI usage compliance issue — Akhilesh using external AI. Luke mandated: stick to pod GLM, document everything.' 25 Aug demo notes list Telegram bot 'models used (Whisper, GLM, Gemini)'. Mentions cited per rule 2 for a human to rule on; product source greps found no third-party model.
ai_usage	Prompt library and reconstructed activity log	`docs/confluence/2024800260_AI_Prompt_Library_and_Prompt_Logs.md`	13 reusable prompt patterns plus a dated activity log 10-28 Aug, honestly labelled 'reconstructed... not a verbatim transcript'. Complements the 3,335-line portal prompt suite (ngaige-mno-portal/APP_GENERATION_PROMPT.md) and 23 timestamped backend prompts.
documentation	Delivery/handover documentation set	`docs/confluence/2026668040_NGAIGE_Telegram_Bot_Integration_-_Delivery_Handover_Report.md`	Maps acceptance items to code locations, validation steps, models used, and limitations. Alongside: PRD (2006221036), 8 infra pages, PWA and MNO developer docs (created 26 Aug), 10 LLDs (single AI pass, 30 Aug), QA execution guide with new-engineer setup (2014412855), user manual, pod-to-pod handover checklist (template, unfilled).
acceptance	Opt-out excluded at query time on every dispatch	`repo/ngaige-be-app/src/main/java/com/haud/ngaige/service/broadcast/MultiChannelBroadcastDispatcher.java:42`	findByClientIdAndIsOptedOutFalse selects the target list; SmsBroadcastAdapter.java:82 re-checks getIsOptedOut() per subscriber at send time. Pod's own 28 Aug testing (BUGS item 70) corroborates the behaviour live.
testing	Full unit suite verified green	`repo/ngaige-be-app/src/test`	./mvnw test in an eclipse-temurin:25 container: Tests run: 143, Failures: 0, Errors: 0. No test covers opt-out-then-second-send or approval-gate bypass. Confluence claims 46 passing frontend RTL tests (30 Aug) — not run here.
security	Live ngrok authtoken committed deliberately	`repo/ngaige-product-deploy/README.md:125`	49-char NGROK_AUTHTOKEN plus reserved domain, added in commit 94a014b 'fix: update ngrok credentials in README'. Not disclosed anywhere in the 113 Confluence pages.
security	Committed .env with live stack secrets	`repo/ngaige-product-deploy/.env`	Real-shaped REGISTRY_TOKEN, Postgres/Redis passwords, JWT_SECRET, OPENAI_API_KEY (LiteLLM), SMTP_PASSWORD, INFOBIP_API_KEY, TELEGRAM_BOT_TOKEN and secret tracked in git history. Liveness not tested. Prompt-library page asserts no secrets went into prompts; the repo record is the counterpoint judges should weigh.
security	Cross-tenant IDOR on dispatch and report	`repo/ngaige-be-app/src/main/java/com/haud/ngaige/service/telegram/handler/CampaignCommandHandler.java:657`	campaignRepository.findById(campaignId) with no clientId comparison; 'campaign_broadcast:<anyId>' typed by any ACTIVE client dispatches any campaign. Same pattern in ReportCommandHandler.java:70. Undisclosed in BUGS or the retrospective.
model_choice	Product runtime on self-hosted open weights	`repo/ngaige-infra/ngaige-host/product/.env.example:37`	OPENAI_BASE_URL=https://litellm.ngaige.haud.report/v1, OPENAI_MODEL=qwen3.6-35b-a3b, TRANSCRIPTION_MODEL=faster-whisper-medium. Greps for third-party API models across product source came back empty.

Questions for the pod

Raised by the assessment, not answered by it. Each is a thing a reader of the submission would reasonably ask.

The committed .env in ngaige-product-deploy and the ngrok authtoken in README.md:125 (commit 94a014b) look like live credentials, and neither appears in your BUGS page or retrospective. Were they known, intended for judges' reproduction, and have they been rotated?
The 25 Aug demo notes list the Telegram bot's 'models used (Whisper, GLM, Gemini)'. Product config and source show only qwen3.6-35b-a3b and faster-whisper via your LiteLLM — did Gemini touch any product path at any point, or was this a comparison/demo aside? (Cited per rule 2 for a human to rule on.)
The 21 Aug minutes record 'Akhilesh using external AI' corrected to 'stick to pod GLM'. What was the external tool, over what period, and did any of its output land in product code?
handleBroadcastExecution accepts any campaign ID without an ownership or status check — was this known, and is a fix planned before any real tenant shares the bot?
Item F: BUGS item 41 shows you deliberately replaced STOP with the unsubscribe link. Was an inbound MO path unavailable on the sandbox gateway, or purely a product preference? The charter names the STOP keyword specifically.
ngaige-qa/NGaige/.agents/skills/qa-test-planner/README.md:3 describes a 'Claude Code skill'. Did Claude run against repo content for QA planning, or was execution entirely on the LiteLLM GLM-5.2 pod? (Cited per rule 2.)
The AUTOMATED_AI_SESSION_LOG template (13 Aug) was never populated and the prompt activity log is reconstructed. Do any raw session transcripts exist that could back it?

Could not verify

Checks that could not run. Recorded as unverified, never counted as failures.

Live Telegram bot flow (B) — no running system; scored on code mechanism plus the pod's own 26-28 Aug test notes, which are claims, not verification.
Dispatch to 50+ test MSISDNs and live DLR ingestion (D) — the Infobip account and €10 funding are documented, and BUGS item 69 records reports initially failing then fixed, but no dispatch log or DLR evidence for 50+ MSISDNs is in the submission.
Whether the committed credentials (.env, ngrok token) are currently live — deliberately not tested against external services.
Confluence page content at creation time — createdAt and version numbers verify when a page began, but later versions (e.g. BUGS v31, FINANCIAL_LOGS v8) may have rewritten earlier content; the export carries no per-version diffs.
The 46 frontend RTL tests and green builds claimed in Tests and Verification Evidence (30 Aug) — not executed here.
The deploy runbook end-to-end — requires the pod's private registry and hosted LiteLLM; the pod's own record says it was tested only locally behind VPN.
RunPod invoices behind FINANCIAL_LOGS — the page lists 9 receipts as 'View receipt' links not included in the export; totals were cross-checked against the daily reports instead and reconcile.