@esoteric-logic/praxis-harness 2.13.0 → 2.15.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/base/CLAUDE.md +7 -1
- package/base/configs/registry.json +4 -2
- package/base/hooks/context7-remind.sh +81 -0
- package/base/hooks/settings-hooks.json +9 -0
- package/base/rules/coding.md +7 -0
- package/base/skills/px-prompt/SKILL.md +373 -0
- package/base/skills/px-research/SKILL.md +13 -0
- package/bin/praxis.js +7 -0
- package/bin/prompt-blocks.js +145 -0
- package/bin/prompt-compile.js +313 -0
- package/kits/web-designer/rules/web-design.md +13 -2
- package/lib/assemblers.js +249 -0
- package/lib/loader.js +148 -0
- package/package.json +10 -3
- package/prompts/blocks/behaviors/flag-confidence.md +13 -0
- package/prompts/blocks/behaviors/handle-uncertainty.md +13 -0
- package/prompts/blocks/behaviors/no-flattery.md +15 -0
- package/prompts/blocks/behaviors/recommend-with-reasons.md +13 -0
- package/prompts/blocks/behaviors/verify-before-reporting.md +13 -0
- package/prompts/blocks/context/mcp-servers.md +12 -0
- package/prompts/blocks/context/official-docs-first.md +16 -0
- package/prompts/blocks/context/praxis-workflow.md +20 -0
- package/prompts/blocks/context/vault-integration.md +13 -0
- package/prompts/blocks/domains/cloud-infrastructure.md +13 -0
- package/prompts/blocks/domains/govcon.md +13 -0
- package/prompts/blocks/domains/web-development.md +13 -0
- package/prompts/blocks/formats/concise-responses.md +13 -0
- package/prompts/blocks/formats/what-so-what-now-what.md +16 -0
- package/prompts/blocks/identity/research-partner.md +10 -0
- package/prompts/blocks/identity/senior-engineer.md +15 -0
- package/prompts/blocks/identity/solutions-architect.md +13 -0
- package/prompts/profiles/_base.yaml +15 -0
- package/prompts/profiles/federal-cloud.yaml +18 -0
- package/prompts/profiles/praxis.yaml +13 -0
- package/prompts/projects/_template/prompt-config.yaml +34 -0
- package/prompts/projects/maximus/prompt-config.yaml +13 -0
- package/prompts/projects/maximus/references/maturity-questions.md +634 -0
- package/prompts/projects/maximus/references/phase-maturity-matrix.md +188 -0
- package/prompts/projects/maximus/references/proposal-writing-standards.md +367 -0
- package/prompts/projects/maximus/space-instructions.md +67 -0
- package/prompts/projects/maximus/system-prompt.md +641 -0
- package/prompts/projects/praxis/CLAUDE.md +84 -0
- package/prompts/projects/praxis/project-instructions.md +24 -0
- package/prompts/projects/praxis/prompt-config.yaml +40 -0
- package/prompts/projects/praxis/space-instructions.md +28 -0
- package/scripts/lint-harness.sh +42 -0
|
@@ -0,0 +1,188 @@
|
|
|
1
|
+
# Phase Maturity Matrix — Knowledge Reference
|
|
2
|
+
## Maximus Federal Deal Solution Architect v9.1
|
|
3
|
+
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
## Gate Definitions
|
|
7
|
+
|
|
8
|
+
| Gate | Meaning | Action |
|
|
9
|
+
|------|---------|--------|
|
|
10
|
+
| **Pass** | All section ratings GREEN for the current phase. Proceed to next phase. | Advance capture phase. |
|
|
11
|
+
| **Conditional Pass** | No RED ratings; 1-3 YELLOW ratings with documented remediation plans and owners. | Advance with tracking. Review remediation at next gate. |
|
|
12
|
+
| **No Pass** | Any RED rating, or 4+ YELLOW ratings. | Halt phase advancement. Remediate all RED to YELLOW minimum; reduce YELLOW count below 4. Re-gate within 2 weeks. |
|
|
13
|
+
| **Stop & Reset** | 3+ RED ratings across different sections, or any single RED persisting across 2 consecutive gates. | Escalate to capture lead. Reassess bid/no-bid. Reset capture plan if continuing. |
|
|
14
|
+
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
## Section I: Customer, Mission & Value
|
|
18
|
+
|
|
19
|
+
| Phase | GREEN | YELLOW | RED |
|
|
20
|
+
|-------|-------|--------|-----|
|
|
21
|
+
| **Shaping** | Agency identified; 2+ pain points validated from public sources; strategic priorities named | Agency identified but pain points unvalidated; no public source intelligence | Customer unknown or mission unclear |
|
|
22
|
+
| **Early Capture** | All Shaping + pain points confirmed through engagement; stakeholder map drafted; mission KPIs identified | Shaping met but no direct engagement; stakeholder map incomplete | Pain points still unvalidated; no stakeholder visibility |
|
|
23
|
+
| **Mid Capture** | Complete pain point inventory with sources; customer outcome KPIs defined; acquisition strategy confirmed | Most pain points documented; 1-2 KPIs undefined | Pain points incomplete; no acquisition clarity |
|
|
24
|
+
| **Pre-Proposal** | Full mission narrative proposal-ready; KPIs in eval factor language; all 5 evaluator personas addressed | Narrative drafted but not proposal-ready; 1-2 personas unaddressed | No proposal-ready narrative; eval factor alignment missing |
|
|
25
|
+
| **Pre-Submission** | Narrative stress-tested in Red Team; all personas addressed; zero vague claims | Minor refinements needed post-Red Team | Narrative failed Red Team |
|
|
26
|
+
| **Orals** | 60-second BLUF polished; Q&A prep complete for all anticipated questions | BLUF drafted but not rehearsed | No BLUF; Q&A not prepped |
|
|
27
|
+
|
|
28
|
+
---
|
|
29
|
+
|
|
30
|
+
## Section II: Overall Architecture
|
|
31
|
+
|
|
32
|
+
| Phase | GREEN | YELLOW | RED |
|
|
33
|
+
|-------|-------|--------|-----|
|
|
34
|
+
| **Shaping** | Solution hypothesis documented; approach defined; platform fit assessed | Hypothesis vague; no platform mapping | No hypothesis; no concept |
|
|
35
|
+
| **Early Capture** | OV-1 concept drafted; key components identified; TRL assessed | OV-1 sketched but incomplete; TRL unassessed | No architecture concept |
|
|
36
|
+
| **Mid Capture** | OV-1 complete; logical architecture drafted; integration points named; trade-offs documented; TRLs 6+ | OV-1 complete but logical view missing; 1 TRL below 6 | OV-1 missing; no integration mapping |
|
|
37
|
+
| **Pre-Proposal** | All views complete; trade-off analysis for all decisions; TRL 7+; architecture traceable to RFP | All present but 1-2 views incomplete | Any view missing; TRL below 6 without mitigation plan |
|
|
38
|
+
| **Pre-Submission** | Submission-quality diagrams; Red Team findings resolved | Minor polish needed on diagrams | Red Team findings unresolved |
|
|
39
|
+
| **Orals** | Can explain at 3 levels (executive, technical, operational) | 2 of 3 levels prepared | Cannot explain without notes |
|
|
40
|
+
|
|
41
|
+
---
|
|
42
|
+
|
|
43
|
+
## Section III: Processes & Approach
|
|
44
|
+
|
|
45
|
+
| Phase | GREEN | YELLOW | RED |
|
|
46
|
+
|-------|-------|--------|-----|
|
|
47
|
+
| **Shaping** | Approach hypothesis documented; methodology candidates identified; team capability mapped to approach | Approach concept exists but methodology not yet selected | No approach concept; no methodology candidates |
|
|
48
|
+
| **Early Capture** | Named methodology selected with tailoring rationale; key processes identified; team certifications confirmed | Methodology selected but tailoring rationale weak; 1-2 certifications pending | No methodology selected; team capability gaps unaddressed |
|
|
49
|
+
| **Mid Capture** | Full process hierarchy (Approach→Framework→Methodology→Process) documented; ceremonies defined; quality gates identified; process KPIs mapped to mission outcomes | Process hierarchy mostly complete; 1-2 ceremonies undefined | Process hierarchy incomplete; no connection between processes and outcomes |
|
|
50
|
+
| **Pre-Proposal** | All processes proposal-ready with FBP narratives; process diagrams complete; staffing aligned to process roles; all eval factors traceable to process descriptions | Processes documented but FBP narratives weak; 1-2 diagrams missing | Processes not proposal-ready; eval factor traceability missing |
|
|
51
|
+
| **Pre-Submission** | Red Team validated all process claims; no unsupported assertions; past performance evidence linked to each process | Minor process narrative refinements needed | Process claims unsupported; Red Team flagged gaps |
|
|
52
|
+
| **Orals** | Can walk through any process end-to-end with real examples; prepared for "show me" questions | Most processes rehearsed; 1-2 weak on examples | Cannot demonstrate processes without reading |
|
|
53
|
+
|
|
54
|
+
---
|
|
55
|
+
|
|
56
|
+
## Section IV: Artifacts & Deliverables
|
|
57
|
+
|
|
58
|
+
| Phase | GREEN | YELLOW | RED |
|
|
59
|
+
|-------|-------|--------|-----|
|
|
60
|
+
| **Shaping** | Expected deliverable types identified from acquisition research; sample artifacts inventoried from prior work | Deliverable types assumed but not validated against acquisition strategy | No deliverable inventory; no samples identified |
|
|
61
|
+
| **Early Capture** | CDRLs/deliverables mapped from draft requirements; sample artifacts updated for relevance; quality standards defined | CDRL mapping started but incomplete; samples exist but need updating | No CDRL mapping; no relevant samples |
|
|
62
|
+
| **Mid Capture** | Full CDRL matrix with format, frequency, and acceptance criteria; template library ready; DID compliance verified | CDRL matrix mostly complete; 1-2 templates missing | CDRL matrix incomplete; no templates; DID compliance unknown |
|
|
63
|
+
| **Pre-Proposal** | All deliverable descriptions proposal-ready; sample pages/excerpts prepared; delivery schedule aligned to WBS | Descriptions drafted but not proposal-ready; schedule partially aligned | Deliverable descriptions missing; no schedule alignment |
|
|
64
|
+
| **Pre-Submission** | Deliverable descriptions stress-tested in Red Team; compliance matrix complete; all DID references verified | Minor refinements needed | Red Team flagged deliverable gaps; compliance matrix incomplete |
|
|
65
|
+
| **Orals** | Can present sample deliverables and explain quality process | Samples prepared but presentation not rehearsed | No samples; cannot discuss quality process |
|
|
66
|
+
|
|
67
|
+
---
|
|
68
|
+
|
|
69
|
+
## Section V: Program Planning & Transition
|
|
70
|
+
|
|
71
|
+
| Phase | GREEN | YELLOW | RED |
|
|
72
|
+
|-------|-------|--------|-----|
|
|
73
|
+
| **Shaping** | Transition complexity assessed; hot-start concept identified; incumbent analysis complete | Transition acknowledged but not assessed; incumbent unknown | No transition planning; incumbent not researched |
|
|
74
|
+
| **Early Capture** | 30/60/90-day concept drafted; staffing ramp plan outlined; governance model identified; key risks flagged | 30/60/90 concept exists but staffing plan incomplete; governance model vague | No transition concept; no staffing plan |
|
|
75
|
+
| **Mid Capture** | Full transition plan with milestones; staffing model with names/roles; governance charter drafted; Day-1 readiness checklist started; incumbent transition risks mitigated | Transition plan mostly complete; 1-2 staffing gaps; governance charter in draft | Transition plan incomplete; staffing model missing; no governance concept |
|
|
76
|
+
| **Pre-Proposal** | Transition plan proposal-ready; all milestones with acceptance criteria; staffing model with resumes; governance charter complete; Day-1 processes defined | Plan drafted but not proposal-ready; 1-2 resumes pending | Transition plan not proposal-ready; staffing gaps >20% |
|
|
77
|
+
| **Pre-Submission** | Red Team validated transition plan; all claims evidence-backed; phase-in schedule realistic per evaluator feedback | Minor refinements needed | Red Team flagged unrealistic timeline or staffing gaps |
|
|
78
|
+
| **Orals** | Can walk through Day 1 morning; prepared for "what if incumbent doesn't cooperate" questions | Day 1 walkthrough prepared but not rehearsed | Cannot articulate Day 1 plan |
|
|
79
|
+
|
|
80
|
+
---
|
|
81
|
+
|
|
82
|
+
## Section VI: Assumptions
|
|
83
|
+
|
|
84
|
+
| Phase | GREEN | YELLOW | RED |
|
|
85
|
+
|-------|-------|--------|-----|
|
|
86
|
+
| **Shaping** | Key assumptions documented; sources identified for validation; high-impact assumptions flagged | Assumptions listed but not categorized by impact | No assumptions documented |
|
|
87
|
+
| **Early Capture** | Assumptions categorized (requirements, technical, operational, resource, schedule); validation plan for each; customer engagement planned to confirm top assumptions | Assumptions categorized but validation plan incomplete; no customer validation planned | Assumptions uncategorized; no validation plan |
|
|
88
|
+
| **Mid Capture** | 80%+ assumptions validated or converted to requirements/risks; remaining assumptions have clear owners and deadlines; customer-confirmed assumptions documented with source | 60-80% validated; some assumptions without owners | <60% validated; no tracking of validation status |
|
|
89
|
+
| **Pre-Proposal** | All proposal-impacting assumptions validated or explicitly stated with mitigation; assumption register proposal-ready | Most validated; 1-2 high-impact assumptions still open | High-impact assumptions unvalidated; no assumption register |
|
|
90
|
+
| **Pre-Submission** | Zero unvalidated high-impact assumptions; all stated assumptions defensible in protest scenario | 1 medium-impact assumption still open with mitigation | Unvalidated assumptions that affect pricing or approach |
|
|
91
|
+
| **Orals** | Can defend every stated assumption with evidence | Most assumptions defensible; 1-2 require additional context | Cannot defend key assumptions |
|
|
92
|
+
|
|
93
|
+
---
|
|
94
|
+
|
|
95
|
+
## Section VII: Risks
|
|
96
|
+
|
|
97
|
+
| Phase | GREEN | YELLOW | RED |
|
|
98
|
+
|-------|-------|--------|-----|
|
|
99
|
+
| **Shaping** | Top 5 risks identified from opportunity research; risk categories established; initial probability/impact assessed | Risks acknowledged but not formally identified; no categorization | No risk identification |
|
|
100
|
+
| **Early Capture** | Risk register started with 10+ entries; risk owners assigned; mitigation strategies drafted for top risks; risk burn-down approach defined | Risk register started but <10 entries; owners not assigned for all | No risk register; risks discussed informally only |
|
|
101
|
+
| **Mid Capture** | Full risk register with probability, impact, mitigation, owner, and trigger; risk interdependencies mapped; cost/schedule reserves linked to risks; monthly risk review cadence established | Risk register mostly complete; 1-2 risks without full mitigation plans; reserves not yet linked | Risk register incomplete; no mitigation plans; no reserves |
|
|
102
|
+
| **Pre-Proposal** | Risk register proposal-ready; all mitigations have evidence from past performance; risk narrative demonstrates proactive management; residual risks acceptable | Register complete but evidence weak for 1-2 mitigations; narrative needs strengthening | Risk register not proposal-ready; mitigations lack evidence |
|
|
103
|
+
| **Pre-Submission** | Red Team validated risk approach; no unaddressed risk concerns; risk language calibrated (neither overconfident nor alarmist) | Minor calibration needed on risk language | Red Team flagged unaddressed risks or unrealistic mitigations |
|
|
104
|
+
| **Orals** | Can discuss risk trade-offs fluently; prepared for "what keeps you up at night" questions | Most risks rehearsed; 1-2 areas need deeper preparation | Cannot discuss risks without reading register |
|
|
105
|
+
|
|
106
|
+
---
|
|
107
|
+
|
|
108
|
+
## Section VIII: Dependencies
|
|
109
|
+
|
|
110
|
+
| Phase | GREEN | YELLOW | RED |
|
|
111
|
+
|-------|-------|--------|-----|
|
|
112
|
+
| **Shaping** | Key dependencies identified (internal, customer, external); dependency categories established | Dependencies acknowledged but not catalogued | No dependency identification |
|
|
113
|
+
| **Early Capture** | Dependency register started; internal/customer/external/technical/schedule dependencies categorized; owners assigned; critical path dependencies flagged | Register started but categorization incomplete; owners not fully assigned | No dependency register; dependencies tracked ad hoc |
|
|
114
|
+
| **Mid Capture** | Full dependency register with type, owner, status, and impact if unmet; customer dependencies communicated to customer; vendor dependencies under contract or LOI; schedule dependencies reflected in IMS | Register mostly complete; 1-2 customer dependencies not yet communicated; vendor dependencies in negotiation | Register incomplete; customer dependencies not communicated; vendor dependencies unaddressed |
|
|
115
|
+
| **Pre-Proposal** | All dependencies proposal-ready; management approach for each dependency documented; contingency plans for critical dependencies; dependency language reviewed for protest risk | Dependencies documented but management approach weak for 1-2; contingency gaps | Dependencies not proposal-ready; no contingency plans |
|
|
116
|
+
| **Pre-Submission** | Red Team validated dependency approach; no unrealistic dependency assumptions; all vendor commitments in writing | Minor refinements needed | Red Team flagged unrealistic dependencies; vendor commitments missing |
|
|
117
|
+
| **Orals** | Can explain dependency management approach and contingencies for any dependency | Most prepared; 1-2 dependencies need deeper contingency articulation | Cannot explain dependency management coherently |
|
|
118
|
+
|
|
119
|
+
---
|
|
120
|
+
|
|
121
|
+
## Section IX: Cybersecurity
|
|
122
|
+
|
|
123
|
+
| Phase | GREEN | YELLOW | RED |
|
|
124
|
+
|-------|-------|--------|-----|
|
|
125
|
+
| **Shaping** | Security requirements identified from public sources; compliance framework (FedRAMP, FISMA, NIST) assessed; ZTA relevance evaluated | Security requirements assumed but not validated | No security assessment |
|
|
126
|
+
| **Early Capture** | Security architecture concept drafted; ATO strategy identified; supply chain risk approach defined; ICAM concept outlined | Security concept exists but ATO strategy vague; supply chain not addressed | No security architecture concept |
|
|
127
|
+
| **Mid Capture** | Security architecture aligned to NIST 800-53/171; ZTA roadmap drafted; supply chain risk management plan complete; continuous monitoring approach defined; data classification scheme established | Architecture mostly aligned; ZTA roadmap in draft; 1-2 areas incomplete | Architecture not aligned to NIST; no ZTA consideration; no supply chain plan |
|
|
128
|
+
| **Pre-Proposal** | Full cybersecurity narrative proposal-ready; all controls mapped to requirements; ATO timeline realistic; incident response plan outlined; security staffing identified | Narrative drafted but not proposal-ready; 1-2 control mappings incomplete | Cybersecurity narrative missing; ATO timeline unrealistic |
|
|
129
|
+
| **Pre-Submission** | Red Team validated security approach; no compliance gaps; security language precise and defensible | Minor refinements needed | Red Team flagged compliance gaps or unrealistic ATO claims |
|
|
130
|
+
| **Orals** | Can discuss security architecture at any depth; prepared for ZTA, supply chain, and incident response questions | Most areas prepared; 1-2 need deeper rehearsal | Cannot discuss security without reference materials |
|
|
131
|
+
|
|
132
|
+
---
|
|
133
|
+
|
|
134
|
+
## Section X: Cost Drivers
|
|
135
|
+
|
|
136
|
+
| Phase | GREEN | YELLOW | RED |
|
|
137
|
+
|-------|-------|--------|-----|
|
|
138
|
+
| **Shaping** | Major cost categories identified; ROM developed; IGCE range estimated from market research | Cost categories listed but no ROM | No cost analysis |
|
|
139
|
+
| **Early Capture** | Cost model structure defined; labor categories mapped; direct/indirect cost drivers identified; basis of estimate started; make/buy decisions documented | Cost model started but labor categories incomplete; BOE not started | No cost model; no labor category mapping |
|
|
140
|
+
| **Mid Capture** | Full cost model with labor, materials, subs, ODCs; BOE complete for all cost elements; cost-to-technical traceability established; price-to-win analysis underway; cost risks quantified | Cost model mostly complete; BOE gaps for 1-2 elements; price-to-win not started | Cost model incomplete; no BOE; no price-to-win analysis |
|
|
141
|
+
| **Pre-Proposal** | Cost volume proposal-ready; all rates verified; subcontractor pricing confirmed; cost narrative explains value proposition; cost realism defensible | Cost volume drafted but 1-2 pricing elements unconfirmed; narrative needs strengthening | Cost volume not proposal-ready; pricing unverified |
|
|
142
|
+
| **Pre-Submission** | Red Team validated cost approach; price competitive per PTW; no cost realism concerns; all representations accurate | Minor adjustments needed post-Red Team | Red Team flagged cost realism issues or uncompetitive pricing |
|
|
143
|
+
| **Orals** | Can defend pricing and explain cost-value relationship at any level | Most areas prepared; 1-2 cost elements need deeper justification | Cannot defend pricing without spreadsheets |
|
|
144
|
+
|
|
145
|
+
---
|
|
146
|
+
|
|
147
|
+
## Section XI: Cross-Cutting & Competitive
|
|
148
|
+
|
|
149
|
+
| Phase | GREEN | YELLOW | RED |
|
|
150
|
+
|-------|-------|--------|-----|
|
|
151
|
+
| **Shaping** | Competitive landscape mapped; 3+ competitors identified with strengths/weaknesses; Maximus differentiators articulated; win themes drafted | Competitors identified but analysis shallow; differentiators vague | No competitive analysis; no differentiators |
|
|
152
|
+
| **Early Capture** | Win themes validated against eval factors; ghost strategies for top 2 competitors; teaming strategy defined; competitive pricing intelligence gathered | Win themes drafted but not validated; ghost strategies incomplete; teaming in discussion | No win themes; no ghost strategies; no teaming strategy |
|
|
153
|
+
| **Mid Capture** | Full competitive matrix; win themes embedded in all technical narratives; teaming agreements signed; innovation differentiators quantified; solution maturity advantage documented | Competitive matrix mostly complete; 1-2 win themes not yet embedded; teaming agreements in draft | Competitive matrix incomplete; win themes disconnected from narratives; no teaming agreements |
|
|
154
|
+
| **Pre-Proposal** | All cross-cutting elements proposal-ready; competitive positioning clear in every section; teaming partner contributions integrated; innovation claims evidence-backed | Most elements ready; 1-2 sections lack competitive positioning | Cross-cutting elements not proposal-ready; competitive positioning absent |
|
|
155
|
+
| **Pre-Submission** | Red Team confirmed competitive positioning; no unsubstantiated claims; protest risk minimized | Minor positioning refinements needed | Red Team flagged weak competitive positioning or protest risks |
|
|
156
|
+
| **Orals** | Can articulate why Maximus wins without disparaging competitors; prepared for "why not [competitor]" questions | Most competitive positioning rehearsed; 1-2 areas need preparation | Cannot articulate competitive advantage |
|
|
157
|
+
|
|
158
|
+
---
|
|
159
|
+
|
|
160
|
+
## PAMASI Stage Evidence Requirements
|
|
161
|
+
|
|
162
|
+
| Stage | Focus | Evidence Required | Completion Criteria |
|
|
163
|
+
|-------|-------|-------------------|---------------------|
|
|
164
|
+
| **P — Problem** | Validated pain points, stakeholder map, mission KPIs | Customer engagement notes; public source intelligence; stakeholder analysis; mission outcome metrics | Complete when you can answer: "What problem are we solving, for whom, measured how?" |
|
|
165
|
+
| **A — Approach** | One-sentence approach statement, differentiation rationale, cultural fit assessment | Approach statement document; competitive analysis; cultural alignment assessment; eval factor mapping | Complete when you can explain in 30 seconds why Maximus's approach is different. |
|
|
166
|
+
| **M — Methodology** | Named methodology with tailoring rationale, team certifications, ceremonies defined | Methodology selection memo; tailoring rationale; certification matrix; ceremony calendar; RACI for methodology roles | Complete when the team can describe their daily work tracing back to the approach statement. |
|
|
167
|
+
| **A — Assets** | Platforms mapped, 2+ past performance references, partner RACI, hot-start assets identified | Platform capability matrix; PP reference sheets; partner agreements with RACI; hot-start asset inventory; reuse analysis | Complete when you can answer: "What do we bring to Day 1?" |
|
|
168
|
+
| **S — Solution** | OV-1 complete, all architecture views, RTM started, TRLs confirmed | OV-1 diagram; logical/physical views; integration architecture; RTM draft; TRL assessment for all components | Complete when an evaluator can understand how the solution solves the stated problem. |
|
|
169
|
+
| **I — Implementation** | 30/60/90-day plan, staffing model, governance charter, Day-1 processes defined | Transition plan; staffing plan with names; governance charter; Day-1 process runbook; risk register with mitigations | Complete when you can answer: "What happens Day 1 morning?" |
|
|
170
|
+
|
|
171
|
+
---
|
|
172
|
+
|
|
173
|
+
## Protest Risk Checklist
|
|
174
|
+
|
|
175
|
+
Review before every submission. Any item checked YES is a protest vector requiring remediation.
|
|
176
|
+
|
|
177
|
+
| # | Risk Item | YES/NO | Remediation Owner | Status |
|
|
178
|
+
|---|-----------|--------|-------------------|--------|
|
|
179
|
+
| 1 | Proposal structure deviates from Section L instructions | | | |
|
|
180
|
+
| 2 | Page limits exceeded in any volume | | | |
|
|
181
|
+
| 3 | Compliance matrix misses one or more SHALL/MUST requirements | | | |
|
|
182
|
+
| 4 | Competitor names appear in any proposal volume | | | |
|
|
183
|
+
| 5 | Past performance references contain classified or proprietary information | | | |
|
|
184
|
+
| 6 | Teaming arrangements not properly disclosed per solicitation requirements | | | |
|
|
185
|
+
| 7 | Price significantly below or above IGCE without documented justification | | | |
|
|
186
|
+
| 8 | Key personnel do not meet minimum qualification requirements in Section L | | | |
|
|
187
|
+
| 9 | Requirements in Sections G, H, I, or C not addressed in technical volume | | | |
|
|
188
|
+
| 10 | Unsigned certifications or representations in Section K | | | |
|
|
@@ -0,0 +1,367 @@
|
|
|
1
|
+
# Proposal Writing Standards — Knowledge Reference
|
|
2
|
+
## Maximus Federal Deal Solution Architect v9.1
|
|
3
|
+
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
## 1. Regulatory Foundation
|
|
7
|
+
|
|
8
|
+
### FAR Part 15 — Evaluation Standard
|
|
9
|
+
|
|
10
|
+
All proposals are evaluated under FAR Part 15 (Contracting by Negotiation). The evaluation standard is **best value**, which may be:
|
|
11
|
+
- **Lowest Price Technically Acceptable (LPTA)**: Technical pass/fail, then lowest price wins. Minimize risk language; maximize compliance evidence.
|
|
12
|
+
- **Best Value Trade-Off**: Technical merit weighed against price. Maximize discriminators; demonstrate superior value.
|
|
13
|
+
- **Highest Technically Rated with Fair and Reasonable Price**: Technical excellence paramount. Price must be fair but is secondary.
|
|
14
|
+
|
|
15
|
+
Always confirm the evaluation methodology from Section M before writing a single word.
|
|
16
|
+
|
|
17
|
+
### Uniform Contract Format (UCF) — Key Sections
|
|
18
|
+
|
|
19
|
+
| Section | Title | SA Relevance |
|
|
20
|
+
|---------|-------|-------------|
|
|
21
|
+
| **C** | Description/Specifications/SOW/PWS | The work. Every technical claim must trace to a C requirement. |
|
|
22
|
+
| **G** | Contract Administration Data | Reporting, invoicing, COR designation. Address in management approach. |
|
|
23
|
+
| **H** | Special Contract Requirements | Security clearances, organizational conflicts, small business goals. Must address each. |
|
|
24
|
+
| **I** | Contract Clauses | FAR/DFARS clauses. Compliance matrix must reference every applicable clause. |
|
|
25
|
+
| **J** | Attachments/Exhibits | CDRLs, labor categories, GFE/GFI lists. Map deliverables to these. |
|
|
26
|
+
| **K** | Representations and Certifications | Must be signed and current. Protest vector if missing. |
|
|
27
|
+
| **L** | Instructions, Conditions, and Notices | THE authority on proposal structure, page limits, format. Deviate at your peril. |
|
|
28
|
+
| **M** | Evaluation Factors | THE authority on what evaluators score. Every sentence should trace to an M factor. |
|
|
29
|
+
|
|
30
|
+
### Plain Writing Act of 2010
|
|
31
|
+
|
|
32
|
+
Federal writing must be clear, concise, and well-organized. This is not optional — it is law. Implications for proposals:
|
|
33
|
+
- Short sentences (target 15-22 words)
|
|
34
|
+
- Active voice
|
|
35
|
+
- Concrete language over abstractions
|
|
36
|
+
- Headers and lists for scanability
|
|
37
|
+
- No jargon without definition on first use
|
|
38
|
+
|
|
39
|
+
---
|
|
40
|
+
|
|
41
|
+
## 2. BLUF Standard (Bottom Line Up Front)
|
|
42
|
+
|
|
43
|
+
Every proposal paragraph, section introduction, and executive summary follows the BLUF structure.
|
|
44
|
+
|
|
45
|
+
### Structure
|
|
46
|
+
|
|
47
|
+
| Element | Purpose | Length |
|
|
48
|
+
|---------|---------|--------|
|
|
49
|
+
| **Lead** (BLUF sentence) | State the conclusion, recommendation, or key point first. | 1 sentence |
|
|
50
|
+
| **Body** | Provide evidence, rationale, and supporting detail. | 2-5 sentences |
|
|
51
|
+
| **Close** | Restate benefit to the customer or transition to next topic. | 1 sentence |
|
|
52
|
+
|
|
53
|
+
### Examples
|
|
54
|
+
|
|
55
|
+
**Wrong:**
|
|
56
|
+
> Our team has extensive experience in federal IT modernization spanning over 15 years. We have worked with numerous agencies including DHS, VA, and CMS. Based on this experience, we believe our approach to cloud migration will meet the agency's needs.
|
|
57
|
+
|
|
58
|
+
**Right:**
|
|
59
|
+
> Maximus will complete the cloud migration within 12 months, achieving FedRAMP High authorization by Month 9. This timeline is based on three comparable migrations (VA EHR, CMS MFASIS, DHS ATLAS) where we achieved authorization 30 days ahead of schedule. The agency gains an operational platform three months before the legacy system's end-of-life deadline.
|
|
60
|
+
|
|
61
|
+
---
|
|
62
|
+
|
|
63
|
+
## 3. FBP Standard (Feature–Benefit–Proof)
|
|
64
|
+
|
|
65
|
+
Every technical claim must contain all three elements. Missing elements weaken the evaluation score.
|
|
66
|
+
|
|
67
|
+
### Three Elements
|
|
68
|
+
|
|
69
|
+
| Element | Definition | Test |
|
|
70
|
+
|---------|-----------|------|
|
|
71
|
+
| **Feature** | What we do or provide — a capability, tool, process, or asset. | "Can the evaluator identify the specific offering?" |
|
|
72
|
+
| **Benefit** | Why it matters to the customer's mission — stated in their language, tied to their outcomes. | "Does this connect to an eval factor or mission KPI?" |
|
|
73
|
+
| **Proof** | Evidence it works — past performance, metrics, certifications, or demonstrated results. | "Would a skeptical evaluator accept this as evidence?" |
|
|
74
|
+
|
|
75
|
+
### Scoring Impact
|
|
76
|
+
|
|
77
|
+
| FBP Completeness | Likely Evaluator Perception | Score Impact |
|
|
78
|
+
|------------------|-----------------------------|-------------|
|
|
79
|
+
| Feature + Benefit + Proof | Credible, substantiated, differentiating | Strength or Significant Strength |
|
|
80
|
+
| Feature + Benefit (no Proof) | Promising but unsubstantiated | Neutral to minor Strength |
|
|
81
|
+
| Feature + Proof (no Benefit) | Capable but "so what?" | Neutral |
|
|
82
|
+
| Feature only | Brochureware | Weakness or ignored |
|
|
83
|
+
| Benefit only | Empty promise | Weakness |
|
|
84
|
+
|
|
85
|
+
### Examples by Level
|
|
86
|
+
|
|
87
|
+
**Feature only (weak):**
|
|
88
|
+
> Maximus uses an Agile development methodology.
|
|
89
|
+
|
|
90
|
+
**Feature + Benefit (better):**
|
|
91
|
+
> Maximus uses an Agile development methodology, enabling the agency to reprioritize work every two weeks in response to changing mission needs.
|
|
92
|
+
|
|
93
|
+
**Full FBP (strongest):**
|
|
94
|
+
> Maximus uses an Agile development methodology (Feature), enabling the agency to reprioritize work every two weeks in response to changing mission needs (Benefit). On the CMS MFASIS program, this approach reduced time-to-deployment for priority changes from 90 days to 14 days, earning an Exceptional CPARS rating for schedule performance (Proof).
|
|
95
|
+
|
|
96
|
+
---
|
|
97
|
+
|
|
98
|
+
## 4. Grammar Rules
|
|
99
|
+
|
|
100
|
+
### Active Voice
|
|
101
|
+
|
|
102
|
+
Active voice is mandatory. Passive voice obscures who is responsible — a fatal flaw in proposals where evaluators assess your commitment.
|
|
103
|
+
|
|
104
|
+
| Passive (Wrong) | Active (Right) |
|
|
105
|
+
|-----------------|----------------|
|
|
106
|
+
| The system will be deployed by our team | Maximus deploys the system |
|
|
107
|
+
| Requirements will be gathered during Phase 1 | Maximus gathers requirements during Phase 1 |
|
|
108
|
+
| Testing is performed on a weekly basis | Maximus tests weekly |
|
|
109
|
+
| The transition plan was developed | Maximus developed the transition plan |
|
|
110
|
+
| Issues are escalated to the PM | The delivery lead escalates issues to the PM |
|
|
111
|
+
| The architecture has been designed to support | Maximus designed the architecture to support |
|
|
112
|
+
|
|
113
|
+
### SHALL → WILL Mapping
|
|
114
|
+
|
|
115
|
+
| In the RFP (Government language) | In the Proposal (Offeror language) |
|
|
116
|
+
|-----------------------------------|------------------------------------|
|
|
117
|
+
| The contractor **shall** provide... | Maximus **will** provide... |
|
|
118
|
+
| The contractor **shall** ensure... | Maximus **ensures**... (present tense for established processes) |
|
|
119
|
+
| The contractor **shall not**... | Maximus **does not** and **will not**... |
|
|
120
|
+
|
|
121
|
+
Never use "shall" in a proposal — it is the Government's directive word. The offeror's word is "will" (commitment) or present tense (established capability).
|
|
122
|
+
|
|
123
|
+
### Tense Discipline
|
|
124
|
+
|
|
125
|
+
| Tense | Use For | Example |
|
|
126
|
+
|-------|---------|---------|
|
|
127
|
+
| **Present** | Current capabilities, established processes, existing assets | "Maximus operates a FedRAMP High cloud environment" |
|
|
128
|
+
| **Future** | Commitments specific to this contract | "Maximus will deploy the initial operating capability within 90 days" |
|
|
129
|
+
| **Past** | Past performance evidence | "On the VA EHR program, Maximus reduced processing time by 40%" |
|
|
130
|
+
|
|
131
|
+
Never mix tenses within a single FBP statement. Feature (present), Benefit (present/future), Proof (past).
|
|
132
|
+
|
|
133
|
+
### Sentence Length
|
|
134
|
+
|
|
135
|
+
| Metric | Target | Maximum |
|
|
136
|
+
|--------|--------|---------|
|
|
137
|
+
| Average sentence length | 15-22 words | — |
|
|
138
|
+
| Maximum single sentence | — | 35 words |
|
|
139
|
+
| Paragraph length | 3-5 sentences | 7 sentences |
|
|
140
|
+
|
|
141
|
+
If a sentence exceeds 35 words, split it. No exceptions. Evaluators skim — long sentences get misread or skipped.
|
|
142
|
+
|
|
143
|
+
---
|
|
144
|
+
|
|
145
|
+
## 5. Tone — 70/30 Rule
|
|
146
|
+
|
|
147
|
+
**70% Mission / 30% Maximus.** Every page should talk more about the customer's mission, outcomes, and challenges than about Maximus's capabilities.
|
|
148
|
+
|
|
149
|
+
### Why
|
|
150
|
+
|
|
151
|
+
Evaluators are mission owners. They care about their problem being solved, not about your company's history. Lead with their mission. Support with your capability.
|
|
152
|
+
|
|
153
|
+
**Wrong (Maximus-heavy):**
|
|
154
|
+
> Maximus is a leading provider of federal IT services with over 45 years of experience. Our team of 35,000 professionals delivers innovative solutions across federal, state, and local government.
|
|
155
|
+
|
|
156
|
+
**Right (Mission-first):**
|
|
157
|
+
> The agency's enrollment processing backlog affects 2.3 million beneficiaries waiting for eligibility determinations. Maximus reduces this backlog by 60% within 6 months using automated eligibility workflows proven on 3 comparable programs.
|
|
158
|
+
|
|
159
|
+
### Evaluator Persona Calibration
|
|
160
|
+
|
|
161
|
+
| Persona | Cares About | Write To Them By |
|
|
162
|
+
|---------|-------------|-------------------|
|
|
163
|
+
| **Mission Owner** | Outcomes, KPIs, mission impact, timeline to value | Leading with mission outcomes; quantifying impact in their metrics |
|
|
164
|
+
| **Technical Authority** | Architecture soundness, integration risk, scalability, standards compliance | Providing architecture detail, trade-off rationale, TRL evidence |
|
|
165
|
+
| **Acquisition Professional** | Compliance, cost realism, protest risk, past performance relevance | Ensuring compliance matrix completeness; matching Section L exactly |
|
|
166
|
+
| **End User** | Usability, training, transition disruption, day-to-day workflow | Describing user experience; showing transition plan minimizes disruption |
|
|
167
|
+
| **Budget Authority** | Cost efficiency, ROI, should-cost alignment, price realism | Connecting technical approach to cost drivers; showing value per dollar |
|
|
168
|
+
|
|
169
|
+
---
|
|
170
|
+
|
|
171
|
+
## 6. Banned Language
|
|
172
|
+
|
|
173
|
+
### Buzzword Replacement Table
|
|
174
|
+
|
|
175
|
+
| Banned Term | Why | Replace With |
|
|
176
|
+
|-------------|-----|-------------|
|
|
177
|
+
| robust | Vague; no measurable meaning | State the specific capability: "handles 10,000 concurrent users" |
|
|
178
|
+
| world-class | Unsubstantiated superlative | Cite the specific ranking, certification, or metric |
|
|
179
|
+
| proven track record | Cliché; evaluators discount it | Cite the specific program, metric, and CPARS rating |
|
|
180
|
+
| cutting-edge | Meaningless without context | Name the specific technology and its TRL |
|
|
181
|
+
| seamless | Nothing is seamless; evaluators know this | Describe the specific integration approach and testing |
|
|
182
|
+
| leverage | Corporate jargon | "use," "apply," "build on" |
|
|
183
|
+
| synergy | Corporate jargon | Describe the specific combined capability |
|
|
184
|
+
| holistic | Vague | Describe what specifically is included |
|
|
185
|
+
| unique understanding | Unprovable claim | Describe the specific insight and its source |
|
|
186
|
+
| best-of-breed | Unsubstantiated comparison | Name the specific tool and why it was selected |
|
|
187
|
+
| state-of-the-art | Undefinable | Cite the standard, version, or specification |
|
|
188
|
+
| industry-leading | Unsubstantiated | Cite the ranking or market position data |
|
|
189
|
+
| turnkey | Oversimplification | Describe the specific implementation and timeline |
|
|
190
|
+
| deep bench | Vague staffing claim | State the number of qualified staff and their certifications |
|
|
191
|
+
| thought leadership | Self-congratulatory | Cite the specific publication, patent, or contribution |
|
|
192
|
+
|
|
193
|
+
### Banned Hedge Words
|
|
194
|
+
|
|
195
|
+
Never use these — they signal uncertainty to evaluators:
|
|
196
|
+
- "We believe" → State the fact or commitment directly
|
|
197
|
+
- "We hope to" → "Maximus will"
|
|
198
|
+
- "We plan to" → "Maximus will" (if committed) or remove (if not)
|
|
199
|
+
- "We feel that" → State the evidence
|
|
200
|
+
- "Arguably" → Remove entirely
|
|
201
|
+
- "Potentially" → Quantify the probability or remove
|
|
202
|
+
- "Roughly" / "Approximately" → Use a specific number or range
|
|
203
|
+
- "In our opinion" → Cite the evidence instead
|
|
204
|
+
|
|
205
|
+
### Banned Filler Phrases
|
|
206
|
+
|
|
207
|
+
Remove on sight — they add no information:
|
|
208
|
+
- "It is important to note that" → Delete; state the point directly
|
|
209
|
+
- "As previously mentioned" → Delete; either the reader remembers or re-state concisely
|
|
210
|
+
- "In today's rapidly changing environment" → Delete entirely
|
|
211
|
+
- "At the end of the day" → Delete entirely
|
|
212
|
+
- "It goes without saying" → Then don't say it. Delete.
|
|
213
|
+
- "As a matter of fact" → Delete; state the fact
|
|
214
|
+
- "In order to" → "To"
|
|
215
|
+
- "Due to the fact that" → "Because"
|
|
216
|
+
- "At this point in time" → "Now" or "Currently"
|
|
217
|
+
- "On a daily basis" → "Daily"
|
|
218
|
+
|
|
219
|
+
---
|
|
220
|
+
|
|
221
|
+
## 7. Document-Type Rules
|
|
222
|
+
|
|
223
|
+
### Technical Volume Structure
|
|
224
|
+
|
|
225
|
+
| Level | Element | Purpose |
|
|
226
|
+
|-------|---------|---------|
|
|
227
|
+
| **1** | Volume title | Matches Section L volume name exactly |
|
|
228
|
+
| **2** | Section | Major eval factor (e.g., "Technical Approach") |
|
|
229
|
+
| **3** | Subsection | Sub-factor or major topic area |
|
|
230
|
+
| **4** | Paragraph group | Specific requirement or capability |
|
|
231
|
+
| **5** | FBP block | Individual Feature–Benefit–Proof statement |
|
|
232
|
+
|
|
233
|
+
Every Level 2 heading opens with a BLUF paragraph. Every Level 4+ block contains at least one complete FBP.
|
|
234
|
+
|
|
235
|
+
### RFI Response Format
|
|
236
|
+
|
|
237
|
+
1. **Restate the question** (1 sentence, paraphrased to show understanding)
|
|
238
|
+
2. **Direct answer** (1-3 sentences, BLUF)
|
|
239
|
+
3. **Supporting detail** (as needed, with FBP where applicable)
|
|
240
|
+
4. **Differentiator** (if the question allows — what makes Maximus's answer different)
|
|
241
|
+
|
|
242
|
+
Keep RFI responses concise. The Government is gathering market intelligence, not evaluating proposals.
|
|
243
|
+
|
|
244
|
+
### PWS Standards
|
|
245
|
+
|
|
246
|
+
When writing or reviewing a Performance Work Statement:
|
|
247
|
+
- Requirements use "shall" (mandatory) or "may" (optional) — never "should" or "will"
|
|
248
|
+
- Each requirement is individually testable and measurable
|
|
249
|
+
- Performance standards have explicit Acceptable Quality Levels (AQLs)
|
|
250
|
+
- No requirements that duplicate FAR/DFARS clauses
|
|
251
|
+
|
|
252
|
+
### Past Performance — STAR Structure
|
|
253
|
+
|
|
254
|
+
| Element | Content | Length |
|
|
255
|
+
|---------|---------|--------|
|
|
256
|
+
| **Situation** | Contract name, agency, period, value, scope summary | 2-3 sentences |
|
|
257
|
+
| **Task** | Specific challenge or requirement relevant to the current pursuit | 1-2 sentences |
|
|
258
|
+
| **Action** | What Maximus specifically did (active voice, specific methods) | 2-4 sentences |
|
|
259
|
+
| **Result** | Quantified outcome with metrics; CPARS rating if available | 1-2 sentences |
|
|
260
|
+
|
|
261
|
+
---
|
|
262
|
+
|
|
263
|
+
## 8. Color Team Standards
|
|
264
|
+
|
|
265
|
+
### Team Definitions
|
|
266
|
+
|
|
267
|
+
| Team | Purpose | Reviewers | Timing |
|
|
268
|
+
|------|---------|-----------|--------|
|
|
269
|
+
| **Pink Team** | Architecture and outline review. Is the story right? | Capture lead, SA, SMEs | After outline, before drafting |
|
|
270
|
+
| **Red Team** | Full draft review simulating evaluator perspective. Scored. | Independent reviewers (not authors), at least 1 former government evaluator if possible | After first complete draft |
|
|
271
|
+
| **Gold Team** | Executive review of final draft. Win strategy alignment check. | Capture executive, BD lead, pricing lead | After Red Team revisions |
|
|
272
|
+
| **White Glove** | Compliance, formatting, and production review. Zero defects. | Production team, contracts, compliance | 48-72 hours before submission |
|
|
273
|
+
|
|
274
|
+
### Pass Criteria
|
|
275
|
+
|
|
276
|
+
| Team | Pass | Conditional | Fail |
|
|
277
|
+
|------|------|-------------|------|
|
|
278
|
+
| **Pink** | Story arc clear; outline addresses all eval factors; win themes present | Story needs refinement; minor eval factor gaps | No clear story; major eval factor gaps |
|
|
279
|
+
| **Red** | No Significant Weaknesses or Deficiencies; all findings addressable in revision cycle | 1-2 Weaknesses with clear fix path | Any Deficiency; Weaknesses that require architectural change |
|
|
280
|
+
| **Gold** | Win strategy evident; executive confident in submission | Minor strategy refinements needed | Executive not confident; major strategy gaps |
|
|
281
|
+
| **White Glove** | Zero compliance defects; all formatting correct; production-ready | Minor formatting issues fixable in <4 hours | Compliance defects; missing sections; wrong format |
|
|
282
|
+
|
|
283
|
+
### Red Team Output Format
|
|
284
|
+
|
|
285
|
+
Red Team findings use the S/W/SW/D framework:
|
|
286
|
+
|
|
287
|
+
| Rating | Definition | Proposal Impact |
|
|
288
|
+
|--------|-----------|----------------|
|
|
289
|
+
| **S — Strength** | Exceeds requirements; provides meaningful advantage | Maintain; amplify in executive summary |
|
|
290
|
+
| **W — Weakness** | Deficiency that could reduce score but is correctable | Must fix in revision cycle |
|
|
291
|
+
| **SW — Significant Weakness** | Material failure to meet a requirement; could result in lower adjectival rating | Must fix; may require architectural change |
|
|
292
|
+
| **D — Deficiency** | Failure to meet a requirement that is not correctable without fundamental restructuring | Stop. Escalate. May require re-baseline. |
|
|
293
|
+
|
|
294
|
+
---
|
|
295
|
+
|
|
296
|
+
## 9. TRL Reference (Technology Readiness Level)
|
|
297
|
+
|
|
298
|
+
| TRL | Definition | Proposal Implication | Rating |
|
|
299
|
+
|-----|-----------|---------------------|--------|
|
|
300
|
+
| **1** | Basic principles observed | Do not propose; research only | RED |
|
|
301
|
+
| **2** | Technology concept formulated | Do not propose; too immature | RED |
|
|
302
|
+
| **3** | Experimental proof of concept | Do not propose for production use | RED |
|
|
303
|
+
| **4** | Technology validated in lab | Propose only with significant risk mitigation and customer awareness | RED |
|
|
304
|
+
| **5** | Technology validated in relevant environment | Propose with risk mitigation plan; flag to customer | YELLOW |
|
|
305
|
+
| **6** | Technology demonstrated in relevant environment | Acceptable with documented maturation plan | YELLOW |
|
|
306
|
+
| **7** | System prototype demonstrated in operational environment | Acceptable; document remaining maturation steps | GREEN |
|
|
307
|
+
| **8** | System complete and qualified | Ready for proposal; cite qualification evidence | GREEN |
|
|
308
|
+
| **9** | System proven in operational environment | Ideal; cite operational metrics as proof points | GREEN |
|
|
309
|
+
|
|
310
|
+
For any component below TRL 7, the proposal must include a maturation plan with milestones, cost, and risk.
|
|
311
|
+
|
|
312
|
+
---
|
|
313
|
+
|
|
314
|
+
## 10. CPARS Rating Scale
|
|
315
|
+
|
|
316
|
+
| Rating | Definition | Proposal Citation Format |
|
|
317
|
+
|--------|-----------|------------------------|
|
|
318
|
+
| **Exceptional** | Performance exceeded most contractual requirements with zero quality issues | "Received an Exceptional CPARS rating for [specific area], with the evaluator noting: '[direct quote if available]'" |
|
|
319
|
+
| **Very Good** | Performance exceeded some contractual requirements with no significant quality issues | "Received a Very Good CPARS rating for [area], reflecting consistent above-standard delivery" |
|
|
320
|
+
| **Satisfactory** | Performance met contractual requirements | "Met all contractual requirements per CPARS evaluation" (use carefully — does not differentiate) |
|
|
321
|
+
| **Marginal** | Performance did not meet some contractual requirements | Do not cite. Address the underlying issue in risk management narrative if the contract is relevant. |
|
|
322
|
+
| **Unsatisfactory** | Performance did not meet most contractual requirements | Do not cite. If the contract is relevant, address corrective actions taken. |
|
|
323
|
+
|
|
324
|
+
---
|
|
325
|
+
|
|
326
|
+
## 11. SA Writing Checklist
|
|
327
|
+
|
|
328
|
+
Run before submitting any section for color team review.
|
|
329
|
+
|
|
330
|
+
### Gate 1: Compliance
|
|
331
|
+
|
|
332
|
+
- [ ] Every SHALL/MUST requirement in Sections C, G, H, I has a traceable response
|
|
333
|
+
- [ ] Proposal structure matches Section L instructions exactly
|
|
334
|
+
- [ ] Page limits verified for every volume
|
|
335
|
+
- [ ] All CDRLs/deliverables from Section J addressed
|
|
336
|
+
- [ ] Representations and certifications (Section K) complete and signed
|
|
337
|
+
- [ ] Font, margin, and formatting requirements met per Section L
|
|
338
|
+
- [ ] Cross-references accurate (no "see Section X" pointing to wrong section)
|
|
339
|
+
|
|
340
|
+
### Gate 2: Architecture Narrative
|
|
341
|
+
|
|
342
|
+
- [ ] OV-1 present and readable at arm's length
|
|
343
|
+
- [ ] All architecture views complete and consistent with each other
|
|
344
|
+
- [ ] Every component has a TRL assessment (all TRL 7+ or mitigation plan documented)
|
|
345
|
+
- [ ] Integration points explicitly identified with interface descriptions
|
|
346
|
+
- [ ] Trade-off analysis documented for every major architecture decision
|
|
347
|
+
- [ ] Architecture traces to requirements (RTM started or complete)
|
|
348
|
+
- [ ] Security architecture addresses FedRAMP/FISMA/NIST requirements
|
|
349
|
+
|
|
350
|
+
### Gate 3: Writing Quality
|
|
351
|
+
|
|
352
|
+
- [ ] Every paragraph opens with BLUF
|
|
353
|
+
- [ ] Every technical claim has complete FBP (Feature, Benefit, Proof)
|
|
354
|
+
- [ ] Active voice throughout (no passive voice without justification)
|
|
355
|
+
- [ ] No banned buzzwords, hedge words, or filler phrases
|
|
356
|
+
- [ ] Sentence length: average 15-22 words, none exceeds 35
|
|
357
|
+
- [ ] 70/30 rule: mission language exceeds Maximus language on every page
|
|
358
|
+
- [ ] No vague quantifiers ("many," "significant," "various") — all claims specific
|
|
359
|
+
|
|
360
|
+
### Gate 4: Evidence Quality
|
|
361
|
+
|
|
362
|
+
- [ ] Every past performance citation includes program name, agency, value, and timeframe
|
|
363
|
+
- [ ] CPARS ratings cited with specific evaluation area
|
|
364
|
+
- [ ] Metrics are specific and verifiable (not "improved performance" but "reduced processing time by 40%")
|
|
365
|
+
- [ ] No unsubstantiated claims of "first," "only," "best," or "leading"
|
|
366
|
+
- [ ] All certifications current and verifiable
|
|
367
|
+
- [ ] Partner/subcontractor capabilities substantiated with their past performance, not just Maximus's
|
|
@@ -0,0 +1,67 @@
|
|
|
1
|
+
---
|
|
2
|
+
tags: [perplexity-space, maximus, federal-capture]
|
|
3
|
+
date: 2026-04-04
|
|
4
|
+
source: agent
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Maximus Federal Deal Solution Architect — Perplexity Space Instructions
|
|
8
|
+
|
|
9
|
+
## Identity
|
|
10
|
+
|
|
11
|
+
You are a federal deal Solution Architect for Maximus Inc. (NYSE: MMS), a $5.31B government services company headquartered in Tysons, VA. Core platforms: TXM (total experience management), ITSM&M (IT service modernization & management), Clinical Services.
|
|
12
|
+
|
|
13
|
+
You operate across seven roles depending on the query:
|
|
14
|
+
|
|
15
|
+
- **Technical Architect**: Solution diagrams, OV-1 operational views, cloud/hybrid architecture, integration patterns
|
|
16
|
+
- **Proposal Architect**: RFP shred sheets, compliance matrices, Section L/M analysis, volume planning
|
|
17
|
+
- **Deal SA**: Opportunity scoring, Technical Readiness Reviews, maturity assessments
|
|
18
|
+
- **Capture Strategist**: Ghost teams, win themes, bid/no-bid analysis, competitive positioning
|
|
19
|
+
- **Cost Analyst**: Basis of Estimates, pricing models, Price-to-Win analysis
|
|
20
|
+
- **Red Team Reviewer**: SSEB-style evaluation, Strengths/Weaknesses/Deficiencies findings
|
|
21
|
+
- **OSINT Researcher**: Agency intelligence, SAM.gov mining, competitor tracking
|
|
22
|
+
|
|
23
|
+
## Core Frameworks
|
|
24
|
+
|
|
25
|
+
**11-Section Assessment**: Standardized opportunity evaluation covering customer, competition, solution, team, past performance, price, risk, capture maturity, partnerships, schedule, and strategic alignment.
|
|
26
|
+
|
|
27
|
+
**PAMASI Maturity Model**: Phases — Pre-RFP, Active Capture, Material Development, Assembly, Submission, Integration. Each phase has defined deliverables, gates, and scoring criteria.
|
|
28
|
+
|
|
29
|
+
**Phase-Aware Scoring**: Opportunity scores adjust based on capture phase. Early-phase gaps are warnings; late-phase gaps are blockers.
|
|
30
|
+
|
|
31
|
+
**FBP (Feature→Benefit→Proof)**: Every discriminator maps a solution feature to a customer benefit with verifiable proof. No unsubstantiated claims.
|
|
32
|
+
|
|
33
|
+
**BLUF Writing**: All outputs lead with Bottom Line Up Front. No burying conclusions.
|
|
34
|
+
|
|
35
|
+
## Research Domains
|
|
36
|
+
|
|
37
|
+
When asked to research, prioritize these source categories:
|
|
38
|
+
|
|
39
|
+
1. **Federal Acquisition**: FAR/DFARS clauses, contract types (FFP, T&M, CPFF, IDIQ), acquisition strategies, source selection procedures
|
|
40
|
+
2. **Agency Intelligence**: IG reports, GAO findings, strategic plans, budget justifications, congressional testimony, agency modernization roadmaps
|
|
41
|
+
3. **SAM.gov**: Active opportunities, award data, contract history, set-aside analysis, incumbent identification
|
|
42
|
+
4. **Cybersecurity & Compliance**: NIST 800-53, Zero Trust Architecture, CMMC levels, FedRAMP authorization, ATO processes, CDM program
|
|
43
|
+
5. **Competitor Analysis**: SEC 10-K/10-Q filings, GovConWire/ExecutiveBiz news, FPDS award data, team/subcontractor patterns
|
|
44
|
+
6. **Federal Budget**: President's budget requests, agency spend plans, continuing resolution impacts, appropriations tracking
|
|
45
|
+
7. **Technology Standards**: Section 508, TIC 3.0, IPv6 mandates, cloud-smart policy, EO 14028 (cybersecurity)
|
|
46
|
+
|
|
47
|
+
## Output Standards
|
|
48
|
+
|
|
49
|
+
- Always cite sources with URLs when available
|
|
50
|
+
- Distinguish between verified facts and analytical inferences
|
|
51
|
+
- Flag information age — federal data older than 12 months may reflect superseded policy
|
|
52
|
+
- When analyzing RFP language, quote the exact text before interpreting
|
|
53
|
+
- For competitor analysis, state the source date and filing type
|
|
54
|
+
- Use tables for comparative analysis; use bullet lists for findings
|
|
55
|
+
- Never fabricate contract numbers, NAICS codes, or award amounts — verify or state unknown
|
|
56
|
+
|
|
57
|
+
## Analytical Priorities
|
|
58
|
+
|
|
59
|
+
When evaluating an opportunity or building a solution:
|
|
60
|
+
1. What does the customer actually need (not just what the SOW says)?
|
|
61
|
+
2. Who is the incumbent and what is their performance history?
|
|
62
|
+
3. What are Maximus's verifiable discriminators for this work?
|
|
63
|
+
4. Where are the compliance risks in the solicitation?
|
|
64
|
+
5. What is the competitive landscape and likely PTW range?
|
|
65
|
+
6. What past performance references are strongest for this scope?
|
|
66
|
+
|
|
67
|
+
Always recommend a course of action. Never present analysis without a conclusion.
|