Director and procurement FAQ
Eighty likely questions about the business case, costs, scope, internal staff, SPII, architecture, testing, integration, programs and delivery risk.
Quick detail: decision ask, cost formulas, internal architecture, delivery stages, acceptance evidence, other programs.
Business case and the funding decision
1. What are you asking us to approve on October 18?
Approve a 3-week discovery stage with 6 person-weeks of allocated internal effort, a sponsor, and named product, engineering, policy, infrastructure and security owners. Its planning labor value is $18k to $30k at illustrative internal rates. The next gate approves a revised scope and estimate. No real-data deployment is part of this first approval.
2. What problem does this solve?
It puts sampled reviews, evidence, calculations, ownership, decisions and reporting status in one workspace. The legacy reference describes workbook, folder, email and tracker handoffs. Discovery must measure where staff repeat entry or reconciliation and which tasks actually improve.
3. Why do this now?
The demo gives staff a concrete process to evaluate before committing to a build. Use current workload, support incidents and upcoming operational needs to establish urgency. Those inputs are not yet measured here, so the brief does not invent a crisis or deadline.
4. What does the polished demo establish?
It establishes that the interaction model and several rules/storage mechanisms can be implemented. Staff can inspect a synthetic review and give precise feedback. It does not establish operational security approval, complete policy coverage, a production cost, or federal acceptance.
5. Why not use the current code as the production system?
The original purpose was to demonstrate utility and clarify requirements. The proposed real app is a new reviewed build. An engineer can carry forward proven rules, tests and UI patterns after review. Reuse is a decision by module, not a promise to keep every demo shortcut.
6. Why not keep improving Excel and Access?
That is a valid option in discovery. Compare its ongoing support, data duplication, traceability, staff time and change risk against a central service. Keeping legacy tools has a cost too, but this pack has not measured it. The central app must show benefits worth its ownership cost.
7. Why not use an existing agency platform?
Evaluate approved platforms before fixing the stack. Test dense review forms, versioned calculations, source lineage, document controls, workflow rights, output contracts, accessibility and data export. An existing platform may reduce infrastructure work. License and customization effort can also be substantial.
8. How will we know this is a good investment?
Collect a baseline, test the same activities in the pilot, and compare time, errors, reconciliation, support and task completion. Count capacity recovered separately from cash savings. Sponsor decisions can include continuity/control value, but should state that value explicitly. See the benefit model.
Cost, finance, and procurement
9. What is the build estimate?
The initial SNAP Negative pilot/cutover model is 88 person-weeks across 26 delivery weeks. At $75 to $125/hour of illustrative fully loaded staff cost, labor is $264k to $440k. A 20% effort allowance gives $316.8k to $528k. These are planning values, not new payroll or supplier invoices.
10. How much new cash is required?
Unknown until IT and finance confirm available staff and services. Existing payroll, hosting and identity can make incremental cash low. Hardware, licenses, backfill and independent assessments may need purchases. Track committed staff effort and actual new cash in separate columns.
11. Can we say it costs only a few dollars per user?
No. About 41 users is the service scope, not the cost basis. Maintenance, assurance, rules, documents, integration and support dominate a small internal service. Demo entry-tier SaaS prices do not price the approved SPII application.
12. What will annual maintenance cost?
The proposal reserves 1.1 combined FTE for engineering, QA, infrastructure, product, security and policy work. Its illustrative annual labor value is $171.6k to $286k. A provisional internal infrastructure allocation adds $3.6k to $18k/year. Actual allocations may be lower if shared service capacity is available.
13. What is the whole-life estimate?
A 36-month window with a 6-month build and 30 months of operation has a partial economic cost of $756.6k to $1.297m in this model. It excludes unpriced purchases/assessments and later expansions. See costs and staffing for the formula and assumptions. It is not a cash request.
14. What prevents costs from growing without control?
Authorize stages with scope, effort ceilings and evidence gates. Use monthly effort/risk reviews, approved change requests and per-program budgets. Keep DCA, broad migration, portals and automatic submission outside the initial estimate. A scope change must include who gains the benefit and the extra delivery/support effort.
15. Does internal delivery remove procurement work?
It can reduce vendor implementation spending, but purchases, licenses, assessments and service agreements can still require procurement. Procurement confirms the applicable agency route and existing agreements. This pack does not claim any purchasing exemption.
16. What if discovery shows poor payback?
Narrow the project, use a shared agency platform, improve the legacy process, or stop. Small illustrative time savings alone do not cover the proposed recurring labor value. The project must establish stronger benefits or lower delivery/support cost before broad commitment.
Personnel, ownership, and support
17. How many developers are needed?
The plan uses one full-time technical lead and one full-time application engineer during most of the build, with allocated QA, infrastructure, security, product, policy and accessibility support. Average total effort is 3.38 FTE across 26 weeks. It is not a two-person project with everyone else optional.
18. Can one part-time person deliver it?
Not on the proposed schedule and assurance model. One person also creates review and continuity gaps. If that is the actual capacity, scope and dates must be reduced/re-estimated. At least two people should understand deployment, rule releases and recovery.
19. What should the current proposer do?
Act as a product/domain lead, translate workflow evidence into requirements, organize staff feedback, and support acceptance. Build coding knowledge with the course. Avoid making that person the sole architect, policy approver, tester and maintainer.
20. Who owns policy correctness?
The named QC/policy owner approves rule meanings, amount tables, defect mappings and expected cases. Engineers implement and test them. QA checks the implementation independently. An AI output or a legacy cell formula does not replace that approval.
21. Who operates the system after launch?
An agency service owner accepts the system. Engineering maintains code/rules, IT maintains approved infrastructure and restore capability, operations handles staff issues, and security/records owners govern access and retention. Document escalation, backup contacts and support hours before pilot.
22. What happens if the original builder leaves?
The agency retains repository, deployment access, code documentation, decisions, test cases and runbooks. Two trained maintainers complete a handover drill. The service owner tracks unresolved work and credentials in agency systems. Personal accounts must not own production assets.
23. How much staff training is needed?
Start with role-based task sessions and quick reference guides. A planning example is 4 hours per person, or 164 trainee hours for 41 staff, plus trainer/preparation time. Pilot measurements should replace this assumption. Managers, statistics and administrative roles need different exercises.
24. How do staff influence the build?
Give every role a named representative and regular task-based reviews. Track concrete feedback against requirements and acceptance criteria. Involve DCA and other-program staff before their scope is approved. Approval authority and informal screen feedback remain separate.
SPII, internal access, and governance
25. Is the proposed app public or cloud-hosted?
The confirmed production requirement is internal only. The default proposal uses agency-hosted compute, database and private storage behind approved internal network access. The demo may use external managed services, but those are not the production hosting decision.
26. Is internal network access enough security?
No. Every request still needs identity and record/action authorization. Internal users, compromised accounts, exports and privileged tools can expose SPII. Security must review network isolation, access scope, logging, keys, documents and backup handling.
27. How will users sign in?
Use the approved agency identity service with its required MFA/SSO and lifecycle controls. Store app roles and program/team memberships in controlled configuration. Test real account setup, offboarding, temporary coverage and access reviews. The demo Clerk metadata model is a reference only.
28. Who can read a review or document?
The approved membership and assignment model controls it. Enforce the same scope in lists, direct reads, saves, exports and object retrieval. The demo has one program per actor. The real app must explicitly support approved multi-program/team/region membership.
29. Can we use real records in the demo?
The repository is designed for synthetic data and PDFs. A marker is not anonymization. Keep the October 18 demo synthetic. A real-data pilot needs the agency approving owners, controlled environment, access/records rules and evidence gates.
30. Which compliance certification do we have?
None is asserted by this pack. Security, privacy and records owners must identify the binding agency requirements and approval process. NIST SSDF, OWASP ASVS and WCAG are cited test/development references, not evidence that the app has a government authorization.
31. How are files, exports and logs protected?
The proposal uses scan/quarantine, private object access, classification, checksum evidence, restricted exports and safe logs. Audit sensitive reads/downloads and administrative actions. Set retention for raw intake, revisions, files, traces and backups. Do not log SPII payloads or credentials.
32. Will SPII go to AI coding tools?
The operational design has no AI policy/benefit decision dependency. Use only approved development tools and synthetic examples under agency rules. AI-assisted code receives human review and testing. Do not submit SPII or secrets to unapproved services.
Architecture and technical choices
33. Why a modular monolith?
For about 41 users, one reviewed application with module boundaries is simpler to deploy and support than many services. Separate a worker for slow/retried jobs. Use explicit interfaces so a service can be separated later if workload or ownership requires it.
34. Must we keep Next.js, Clerk, Neon or Vercel?
No. The approved internal stack and team skills decide. The production proposal keeps the useful boundaries and workflow knowledge. In particular, agency identity and internal database adapters need review. Demo dependencies are not a purchasing specification.
35. Why keep program rules separate from UI?
Calculation and validation should run without browser, identity-provider or database dependencies. That makes independent testing, policy versioning and historical reproduction easier. The UI can show the results without becoming the policy engine.
36. Will the production database just store JSON?
Use relational fields where constraints and frequent queries matter, plus versioned typed JSON for facts that differ by program. Store approvals, assignments, issues, documents and job evidence explicitly. Decide history/retention needs before copying the demo snapshot model.
37. Why have a worker and outbox?
A review save should commit its approved state and intent to deliver together. The worker can render documents or call an approved receiver later and retry safely. A database save cannot guarantee an external email or portal operation succeeded.
38. How are simultaneous edits handled?
Use an expected revision and reject stale writes. Repeated accepted request IDs have one effect. Provide clear conflict review and recoverable local draft handling where permitted. Do not merge approvals/calculations blindly. The demo currently discards local edits on its conflict recovery path.
39. Can staff work offline?
Offline operation is outside initial scope. Local copies of SPII create device, sync, conflict and disposal obligations. If required, discovery must design approved device storage and conflict handling. The current UI assumes networked server persistence.
40. How will the app avoid becoming another fragile custom tool?
Enforce module boundaries, independent policy cases, peer review, protected releases, supported dependencies, service ownership and two-maintainer handover. Test restore and migration. Those continuing duties matter more than the choice of a fashionable framework.
Scope, schedule, and implementation
41. When can the first real pilot happen?
The model puts a controlled pilot at delivery weeks 20 to 23, after requirements, platform, functional slice and assurance gates. It assumes available internal staff and services. Six to nine calendar months is a planning band with waits. Do not promise a fixed pilot date before discovery.
42. What is in release one?
A complete internal SNAP Negative journey: intake/assignment, investigation, approved calculations/checks/routing, evidence, a defined correspondence subset, CAO response, reporting and an accepted export route. Also include secure operation, recovery, training and support. See scope boundaries.
43. What is outside release one?
Other program packages, DCA replacement, broad historical migration, automatic Access sync, a CAO portal and automatic federal submission. Those need separate scope and owner decisions. A legacy route may continue for an output awaiting certification.
44. What stops the current demo from completing a new review?
New non-drop supervisor routing and memo classification require the management-approved Review-tab defect map. The code has an explicit guard. Seeded later-stage records can show downstream screens but cannot prove that blocked path works.
45. What does management need to decide first?
Approve the defect/memo mapping, role/coverage rules, dispute/reassignment behavior, drop extra fields and narrative templates. Confirm deadline start events/calendars and output authority. IT/security/records must identify the internal platform and real-data approval route.
46. How do we prevent scope creep?
Use a release-one requirement list with owner-approved exclusions. Each change must name its benefit, dependency, acceptance test, effort and support impact. Stage-gate decisions can move it to a later release. New programs are packages with independent acceptance, not extra tabs.
47. Can we speed up by reusing the whole demo?
Possibly for some modules, but assess whole-life effort rather than saved typing. Reuse must meet the same security, accessibility, policy, data and support gates. The default is a new build with selective review. A reuse assessment may change that with evidence.
48. What if hosting or policy decisions arrive late?
Do useful synthetic discovery and isolated pure-rule work. Keep dependent stages open and revise dates/effort. Do not remove guards, fabricate policy values, or place SPII in an unapproved environment to keep the original date.
Testing, acceptance, and recovery
49. Do existing tests prove the app is ready?
No. They test particular implementation contracts and synthetic journeys. Dated counts in implementation status are historical. Real agency identity, controls, receiving-system acceptance and operational recovery need separate evidence. See the test matrix.
50. How do you prove benefit calculations are correct?
Policy SMEs supply independent expected cases and authoritative tables. Cover rounding, household boundaries, thresholds, self-employment, education, proration and scenario selection. Compare with approved workbook/policy evidence and document intentional differences. Tests must not derive expected answers from the same function.
51. What is the end-to-end acceptance test?
Create a new review from approved-format intake, assign it, investigate, calculate, submit, return/correct, approve/route, record PEC and memo/response, release, and reconcile the required output. Also complete a drop. Run staff roles without directly changing database state.
52. How will we test all 41 users?
Use the actual role distribution, representative retained data and the approved internal network. Test an initial 12-editor assumption and bursts from all 41 signed-in users, with concurrent intake/report/export jobs. Record errors, accepted-write integrity and latency distributions. The roster count is not a tested capacity claim.
53. What are the performance promises?
There are none yet. Proposed internal targets are p95 under 2 seconds for routine data-ready pages and under 1 second for accepted ordinary saves at the agreed load. Existing demo budgets are different measurement thresholds. Operations must approve targets after baseline tests.
54. What happens when the server or database fails?
Show failed operations, retain safe drafts where possible, and prevent uncertain approvals/exports from being treated as successful. IT restores database and document objects to an agreed consistent point. Staff reconcile uncertain external deliveries. Drill recovery before real-data use.
55. How do you test accessibility?
Combine automated checks with keyboard, screen reader, zoom, focus/error, dense-form and staff task tests. The accessibility owner selects binding agency criteria. A component library alone does not prove accessible workflows.
56. Who signs acceptance?
Policy/QC owners sign rule and workflow results. QA records tests/defects. IT/security/privacy/records/accessibility owners sign the required control decisions. The service owner accepts support/recovery. The sponsor authorizes pilot expansion/cutover. No single all-tests-passed claim replaces these roles.
Documents, federal output, and corrective action
57. Does Iris currently submit to QCS?
No. It generates current-template field TSV output. Statistics owns any actual portal submission. There is no certified federal wire format, federal API, or proof of portal acceptance in the demo.
58. How will federal submission work in production?
Confirm the receiving contract, required program fields, eligibility, encoding/format, rejection handling and receipts. Start with a controlled manual export/upload route if that is accepted. Keep frozen source revisions and reconcile accepted/rejected records. Automate only an approved receiver interface.
59. Does the EPP button update Access?
No. The adapter exposes verified identity fields and unverified mapping gaps. It does not write to tblTANF_MA_SNAP_Records. A proposed upsert operation in a payload is not an executed integration.
60. What would the DCA module do?
Receive approved linked QC work, assign an owner, record corrective actions and EPP submissions, return/approve, track deadlines/extensions/follow-up, and close/reopen. It has separate state and roles. The source memo revision remains visible. See DCA handoff.
61. When should DCA receive work?
QC and DCA management must decide. Memo distribution and manager reporting release are distinct events. Waiting for CAO agreement may delay corrective action. The build needs an explicit handoff trigger and eligible memo types, not an inferred date-field rule.
62. Does the demo send approved memos or notices?
No actual memo/email delivery, notice PDF generation or print queue ships here. The demo records memo outbound status. Production needs approved templates, artifact revisions, delivery evidence and response-clock rules.
63. Can the existing Access tracker stay in use?
Yes during a controlled coexistence period if field authority and reconciliation are explicit. Avoid two editable copies of the same field without a conflict rule. Later migration needs identity mapping, duplicate/orphan handling, content reconciliation and records-owner approval.
64. What if an adapter fails after sending?
Record the uncertain operation. Check the receiver ID/receipt before retrying. Use an idempotency key where supported. If the receiver cannot confirm the effect, staff reconcile it. Do not promise exactly-once behavior for an interface that cannot support it.
Other programs and future growth
65. Can all programs fit in one app?
The proposed platform can host separate program packages under common identity, evidence, assignment, reporting and operations services. Each program still needs approved facts, intake, policy, workflow, documents and outputs. One central application does not mean one universal form or calculation.
66. Which program should follow SNAP Negative?
Prioritize by volume, operational pain, readiness of rules/source contracts and available SMEs. The suggested order includes DCA, SNAP Positive/Supplemental, TANF and agreed MA variants. Management can change it. Effort bands are preliminary and separately funded.
67. Can SNAP Positive reuse the Negative calculation?
Some common money/policy helpers may be reusable after review. Positive has different source/member facts, workbook sections, validation and outputs. Validate complete Positive cases independently. Negative parity does not prove Positive readiness.
68. Is SNAP Supplemental just Positive with a new label?
Legacy V2.2 uses prefix 55 and stores it under a Positive folder, but it is a distinct subtype. Preserve that identity and confirm Supplemental-specific rules/reporting before release. No unique rule set is invented from the folder name.
69. Can TANF use the same federal export?
No. The retained reference says TANF is not submitted to QCS. Eligibility and CAR use separate subtypes, facts and checks. Define their artifact audiences and downstream workflow with the program owner.
70. Why split MA variants?
MA Positive, Negative/CHIP, PE, LTC and non-citizen layouts/facts can differ. The current V2.2 MA population does not require BIS, unlike several SNAP/TANF paths. Name the source/layout version and exact subtype. Do not apply a universal column-letter map.
71. Can administrators change every rule without a deployment?
Approved amount tables and controlled reference values can be published if supported by the engine. New algorithms/transition logic need reviewed code, tests and version IDs. A generic editable rule engine would add governance/testing risk and is outside the first release.
72. Will we need microservices or a data warehouse later?
Only when workload, independent ownership, integration or reporting needs justify them. The proposed interfaces make later extraction possible. Measure service/query/job limits first. Do not add infrastructure merely because more programs are planned.
Risks, difficult questions, and decision discipline
73. Was this code generated with AI?
The proposer describes the project as AI-assisted and rapidly built. Treat its code as untrusted until reviewed to the same engineering standard as any other source. Check dependencies, data paths, policy rules, tests and ownership. The useful demo does not remove those duties.
74. Do we legally own all the code?
The agency must confirm ownership, contributor agreements, employment rules and dependency licenses through its normal review. Use an agency repository and approved tooling going forward. This pack does not make a legal ownership claim from how the code was created.
75. What is the biggest risk?
Unapproved or misunderstood workflow/policy plus insufficient internal capacity. The defect-map blocker is concrete evidence of that risk. Security and records decisions can also control the calendar. Put owners and dates on these dependencies before committing to operational use.
76. Could this turn into a project that never finishes?
Yes if the initial scope includes every program, every document, migration and integration at once. Release one is a bounded SNAP Negative slice with explicit evidence gates. Additions need separately priced acceptance. Stop or narrow scope when evidence does not support continuation.
77. Are we replacing the benefit eligibility system?
No. This proposal concerns quality-control review work. It can read approved source data and record QC decisions, but it does not authorize live benefit changes or payments. Any future integration that changes an operational system needs separate scope and approval.
78. What does success look like at the first gate?
A signed scope and decision table, named staff allocations, internal hosting/control route, source/rule inventory, baseline measures, reuse assessment and revised estimate. Screens alone are not gate evidence. Management has enough information to fund, narrow or stop the next stage.
79. What would make us stop?
No sustainable staff/support capacity, inability to approve the required data path, unacceptable policy/security risk, poor workflow fit, or benefits that do not justify whole-life effort. Discovery should expose these early. Record the stop condition and what evidence would change it.
80. What should I say if I do not know an answer in the meeting?
Name the missing fact, its owner and the gate it affects. Example: the records owner must approve raw-source retention before real-data intake. Do not invent a cost, policy deadline or certification. Record the question and a decision date.