Inspiration
Federal opportunities are rarely difficult to find because information is completely absent. They are difficult to pursue because the information is fragmented.
A team may discover an opportunity on one website, compare requirements in a spreadsheet, discuss organizational fit in email, track deadlines on a calendar, and record bid decisions somewhere else entirely. By the time the information has been assembled, the team may have already lost valuable time—or may still be unable to explain why an opportunity is worth pursuing.
Swambok was created to explore a better model: a structured decision workspace where discovery, capability alignment, evidence, events, and pursuit planning remain connected.
The name reflects the product’s role as a guide through a difficult and changing opportunity landscape. Swambok is not intended to replace human judgment. It is designed to make that judgment more organized, explainable, and actionable.
What it does
Swambok turns scattered opportunity information into a structured pursuit workspace.
Instead of treating an opportunity as a single record or search result, Swambok organizes the surrounding decision context:
- Discover provides a focused place to review potential opportunities.
- Opportunity Field presents opportunities as part of a broader decision landscape rather than an isolated list.
- Decision Structure helps teams organize the factors supporting or opposing pursuit.
- Capability Bridge connects opportunity requirements with the capabilities needed to respond.
- Field Events keeps important dates and activity visible.
- Pursuit Space brings the selected opportunity, supporting evidence, and next actions together in one working area.
The result is a more coherent journey from “we found something” to “we understand whether and how we should pursue it.”
The current demonstration uses controlled demo data. Live SAM.gov and Simpler.Grants.gov acceptance testing was not completed for this submission, so the project does not claim validated production connectivity to those systems.
How we built it
Swambok is a web application packaged for reproducible local deployment with Docker.
The application combines a Python-based backend, database migrations, browser-based interfaces, deterministic demo setup, and a structured documentation and validation workflow. The repository includes setup instructions, migration procedures, testing guidance, security and privacy disclosures, third-party notices, judge instructions, and a complete submission evidence package.
A major focus of the Build Week work was not simply adding more screens. It was creating a unified information architecture that allows the product’s major concepts to work as one connected system.
The selected Build Week implementation introduced and refined:
- unified navigation across the primary workflow
- the Opportunity Field decision model
- clearer connections between discovery and pursuit work
- Decision Structure and Capability Bridge experiences
- Field Events visibility
- a more detailed Pursuit Space
- consistent product language and interaction patterns
- improved judge and demonstration workflows
- accessibility and setup corrections identified during final validation
The validated product build is preserved separately from the later documentation and submission-execution commits. This makes it possible to distinguish product functionality from the work performed to prepare evidence, screenshots, deployment instructions, and contest materials.
Build Week provenance
Swambok existed before the submission period as an early federal-opportunity and pursuit-management concept.
During Build Week, the project was substantially advanced through a unified-navigation product build centered on the Opportunity Field model and the connected decision journey. The submission documentation identifies which concepts and foundations were pre-existing and which product experiences, decisions, validations, and supporting materials were created or completed during the contest period.
The repository preserves this history through separate Git milestones for:
- the validated Build Week product,
- the submission documentation package, and
- the submission-execution preparation.
This separation was intentional. It provides judges with a clearer evidence trail and avoids presenting pre-existing work as though it were created entirely during Build Week.
Codex and GPT-5.6 collaboration
Codex was used as an implementation and repository collaborator throughout the project.
It helped inspect the existing codebase, evaluate architecture, implement scoped changes, run migrations and tests, identify regressions, prepare Docker validation, audit documentation, capture submission evidence, and maintain a clear Git history.
GPT-5.6 was used as a strategic and editorial collaborator. It helped refine the product narrative, challenge unclear claims, organize the submission plan, distinguish product work from submission work, and turn technical evidence into judge-facing explanations.
The collaboration was deliberately evidence-driven. AI-generated recommendations were checked against the repository, tests, screenshots, migrations, and running application rather than being treated as proof by themselves.
No claim is made that paid GPT-5.6 API acceptance testing was completed. The project’s documentation distinguishes conversational and development assistance from any unperformed production API validation.
Challenges we faced
Turning a broad idea into a coherent decision model
Federal opportunity management can easily become a collection of unrelated features: search, notes, calendars, scoring, and task tracking. The largest design challenge was determining how those pieces should relate to one another.
The Opportunity Field model became the organizing concept. It allowed the project to treat opportunities, capabilities, decisions, and events as parts of the same pursuit environment.
Preserving provenance
Because Swambok had a pre-existing foundation, the submission needed a defensible boundary between earlier work and Build Week additions.
We addressed this through Git history, feature and decision records, implementation notes, validation evidence, a provenance narrative, and a claims-to-evidence matrix. Preparing that evidence was less visible than building a new screen, but it was essential to making the submission accurate.
Avoiding unsupported integration claims
The product domain naturally invites claims about live federal data sources and AI-driven analysis. We chose not to claim integrations or acceptance results that had not been verified.
The demonstration therefore uses controlled data, and the limitations are stated directly. Live SAM.gov, Simpler.Grants.gov, and paid GPT-5.6 acceptance remain future validation work.
Making the build reproducible
A successful local demonstration is not enough if another person cannot run it.
The final execution pass included clean-clone testing, fresh migrations, deterministic reset validation, Docker build verification, setup-script correction, link and secret audits, and judge-focused instructions.
Accessibility and interaction quality
The final browser review covered twelve routes and identified a problem with unnamed pursuit confirmation controls. Those controls were corrected and regression coverage was added.
The project does not claim complete WCAG conformance, but accessibility risks and completed checks are documented honestly.
Accomplishments that we are proud of
The final submission-execution build achieved:
- 76 automated tests passing in both the main workspace and a clean clone
- successful fresh database migrations through schema version 5
- deterministic demo reset
- successful clean-clone Docker build
- a healthy local Docker runtime
- a twelve-route browser and accessibility audit
- eighteen final screenshots captured and hash-verified
- verified local documentation links
- repository secret-pattern and integrity checks
- preserved Git provenance across product, documentation, and execution milestones
- no changes to the separate production scanner environment
We are especially proud that the submission package does not rely on unsupported claims. Each major statement is tied to repository evidence, a test, a screenshot, a decision record, or an explicit limitation.
What we learned
The most important lesson was that decision-support software needs structure more than it needs additional information.
Teams already have access to large amounts of opportunity data. The harder problem is preserving the relationship between an opportunity, the organization’s capabilities, the evidence available, the events approaching, and the decision that must be made.
We also learned that provenance is part of product quality. A strong submission is not only a working application; it is a traceable explanation of what changed, why it changed, how it was tested, and where its limitations remain.
Finally, AI collaboration worked best when it was constrained by verifiable evidence. Codex and GPT-5.6 accelerated implementation, review, and communication, but repository state and executed validation remained the source of truth.
What’s next for Swambok
The next phase is to move from controlled demonstration data toward carefully validated external integrations.
Planned work includes:
- live-source acceptance testing
- stronger ingestion and normalization workflows
- deeper capability and requirement mapping
- expanded collaboration and decision-history features
- additional accessibility testing
- public deployment hardening
- security and operational review for real organizational use
- user testing with teams that evaluate and pursue government opportunities
Swambok’s long-term goal is not merely to help teams find more opportunities. It is to help them pursue the right opportunities with greater clarity, discipline, and confidence.
Log in or sign up for Devpost to join the conversation.