Applying architecture in the field: how a collection of study recordings became a learning platform for Sailors.
The rollout and qualification outcomes describe the deployment period. The architecture sections describe the implementation maintained today.
Architecture under deployment constraints
During my military deployment to the Middle East, I designed, developed, and deployed the SCW app while continuing my primary duties as a Navy Construction Electrician. I was awarded the Navy and Marine Corps Achievement Medal for my combined contributions to developing the application and providing electrical support to expeditionary operations.
The experience brought together two parts of my professional life. In the field, I helped solve immediate power-distribution problems, including designing and configuring four improvised 200-amp distribution panels. In my personal time, I applied my architecture and security background to a different problem: helping Sailors prepare for demanding warfare qualifications when their study resources were scattered and sometimes inconsistent.
I had completed my IBM and TOGAF architecture certifications shortly before deploying, following roughly nine months of preparation. I wanted to put that learning to work. The opportunity began with audio resources I created from unclassified training material. Other Sailors wanted copies, demand grew, and a friend’s suggestion helped turn a collection of files into an application.
The SCW app now brings together audio lessons, flashcards, Q&A practice, deliverables, and Bobcat AI, a study assistant built around retrieval-augmented generation (RAG). I built a shared frontend with web, Android, and iOS targets, supported by application data services, backend functions, and infrastructure defined in code.
This article connects that deployment experience to the architecture I maintain today. The account of the initial rollout and qualification outcomes describes the deployment period; the technical sections describe the current implementation. Those are different views of an evolving project, rather than a claim that every component described here was part of the first release.
The problem I set out to solve
Preparing for the Seabee Combat Warfare and Expeditionary Warfare qualifications requires sustained study. During deployment, I saw how decentralized material, multiple document versions, and incomplete explanations made that preparation more difficult. The challenge was not simply the amount of information. It was finding useful material and moving between reading, review, and practice without losing continuity.
As requests for the audio increased, distributing individual files became an administrative task. Centralizing the resources gave me a way to make access more consistent and build additional study activities around the material.
I launched an early landing page while waiting for a departure flight and collected more than 120 sign-ups. That gave me a concrete indication of interest and a group of people to engage as I developed the solution. I wanted the application to address the needs I was hearing from them, including my own needs as a learner.
My responsibility extended across the project. I designed the architecture, developed the application, prepared study resources, tested the experience, and deployed the platform. I also continued my electrical duties as we moved between locations and supported operations. That combination made maintainability and operating cost practical constraints: I needed a system I could continue supporting with the time and resources available to me.
How I applied my architectural approach
I applied my IBM well-architected approach and TOGAF learning by connecting the preparation problem to the application design. Requests for study resources and direct engagement with Sailors established the need. From there, I worked through the activities the application would support, the data those activities would produce, and the services needed to deliver them.
I separated functional needs from the qualities the solution needed to maintain. Playing an audio lesson was a feature. Retaining a downloaded lesson with the metadata required for later playback was a storage and lifecycle concern. Recording a practice answer was a feature. Keeping that record associated with the correct user was a data and security concern.
Those distinctions led to concrete boundaries. I kept learning interactions in the frontend, placed shared progress and authentication state outside individual screens, and used backend execution for AI processing and audio licensing. That let each part of the application handle its own data and failure conditions without making every screen responsible for the full system.
Cost, reliability, security, and maintainability remained connected to those decisions. Adding a fallback AI path introduced another dependency to support. Adding offline audio introduced local storage and expiration handling. I treated those consequences as part of the feature design and continued refining the experience through my own use and feedback from Sailors.
Requirements and design priorities
I organized the experience around five complementary activities. Audio provided another way to consume lessons. Flashcards supported recall. Q&A practice helped learners check their understanding. Deliverables brought together reference material and examples. Bobcat AI provided a route to clarification when a learner encountered a difficult topic.
The features shared an audience, but their technical requirements differed:
| Learning need | What I implemented | Design consequence |
|---|---|---|
| Review material in different formats | Audio, flashcards, Q&A, and deliverables | Shared navigation and state, with feature-specific behavior. |
| Retain study activity | Per-user question and flashcard progress | Persistent records separate from temporary screen state. |
| Ask for explanations | Bobcat AI with retrieved study context | Server-side retrieval and generation with failure handling. |
| Use downloaded lessons offline | Encrypted local audio and license metadata | A media-storage lifecycle separate from the application cache. |
| Reach web and mobile users | Shared frontend with Android and iOS projects | Reusable interface code plus platform-specific integration. |
| Keep the service maintainable | Service modules and infrastructure definitions | Explicit integration boundaries and reviewable configuration. |
Low cost influenced the design alongside reliability and security. AI requests, storage, media delivery, and monitoring all introduce recurring work or expense. I needed to consider those costs as part of each feature, rather than treating them as an issue to address after release.
Four choices carried much of that design:
| Constraint or need | My choice | Benefit and accepted cost |
|---|---|---|
| Maintain several delivery targets with limited development time | Share the frontend across web, Android, and iOS | Common learning behavior stays in one codebase; native lifecycle and integration differences still need separate handling. |
| Give explanations access to the study material | Retrieve relevant passages before answer generation | The generator receives curriculum context; extraction quality, retrieval relevance, and index maintenance become part of the feature. |
| Support downloaded protected audio | Store encrypted media and license metadata separately from the application cache | Media keeps its own access and storage lifecycle; expiration and device-storage failures require explicit handling. |
| Keep remote services and resources manageable | Use managed services and define selected infrastructure in code | Resource configuration and integration responsibilities remain explicit; provider dependencies, permissions, and state recovery still require attention. |
The solution architecture
I structured the SCW app around a shared client, managed application services, and backend functions with distinct responsibilities. The client handles the learning experience; backend services handle operations such as AI generation and audio licensing.
The main responsibilities in the SCW app. Some application-data operations use managed services directly; AI and audio licensing follow dedicated backend paths.
I kept those paths distinct because they solve different problems. Recording a flashcard result does not require the same processing as generating an explanation. Audio licensing has its own identity, key-handling, and media-access requirements.
This structure also keeps external integrations out of individual screens where possible. A screen can request an operation through a service module while the module handles the interaction with its dependency. The cost is an extra layer to follow during debugging, but it gives integration behavior a recognizable home.
Frontend, learning progress, and mobile delivery
I built the frontend around feature screens, shared application contexts, and service modules. Authentication, playback, and learning progress have shared state because they affect more than one interaction or screen.
Flashcards illustrate how I separated immediate interaction from persistent behavior. Flipping a card changes the interface. Marking it as understood or still being learned records an outcome against the user’s progress. The service stores review counters, the most recent result, and a timestamp. Chapter summaries use those records to show progress.
Q&A practice follows a similar pattern, retaining question results and favorites. I also connected practice to Bobcat AI so a learner can ask for clarification from the question they are studying. Deliverables support the application side of preparation through reference content, examples, and supporting documents.
For mobile delivery, I reused the frontend within Android and iOS application projects. Sharing the interface helped keep the experience consistent, but I still had to account for native behavior around authentication, keyboards, local storage, and the application lifecycle.
Application updates provide a concrete example. On native platforms, the startup code unregisters existing service workers before registering the current worker. This addresses the risk of an older worker continuing to serve a cached interface after an application update. Browser startup registers the worker without that native cleanup step.
Keyboard behavior is another example. In the native application, I scroll a focused input into view after focus changes so the on-screen keyboard does not leave the learner typing into an obscured field. The form can remain shared while that handling lives in the platform integration code.
Bobcat AI: preparing knowledge and answering questions
I added Bobcat AI because access to material was only part of the problem. Sailors also needed help finding relevant information and clarifying difficult topics. I used RAG to connect answer generation to the study material available to the application.
Preparing the knowledge for retrieval
The ingestion scripts read source PDFs from object storage, extract text, and split it into overlapping passages. Each passage receives an embedding, a numerical representation used for similarity search. I store the vector with its passage text and source metadata so retrieval can return useful context for generation.
The ingestion pipeline prepares study material before a learner asks a question.
I used overlapping passages so adjacent sections retain some shared context rather than being separated at a hard boundary. The scripts attach deterministic identifiers based on the source and passage position, supporting repeatable updates to matching records.
The primary and fallback retrieval paths use separate embedding pipelines and indexes. That makes content maintenance part of the architecture: a curriculum update needs to reach both paths. Successful retrieval from one index does not establish that the other contains equivalent, current material.
Text extraction also has limits. An image-only PDF does not automatically become searchable text in this pipeline. The ingestion scripts skip designated non-searchable or duplicate files and handle documents from which no text can be extracted. Preparing useful source material remains an important part of the AI feature.
Processing a question
At request time, the backend validates the learner’s identity and input, retrieves matching material, evaluates the usage allowance, and passes the retained context into answer generation.
Bobcat AI's main request sequence. Retrieval and generation each have a separate provider-fallback path, omitted here to keep the sequence readable.
The current implementation overlaps user-record loading with retrieval. This allows independent work to proceed concurrently, but it also means retrieval may run for a request subsequently rejected by the allowance check. That is a concrete tension between request ordering, latency, and resource consumption.
I implemented fallback independently for retrieval and generation. A failure during retrieval can use the alternate retrieval path, while generation can fall back separately. Monitoring records these events so a recovered request does not make dependency failures invisible.
I use retrieved passages to inform the explanation, with instructions for the assistant to distinguish missing study context from an answer based on general knowledge. The remaining limits around grounding and conversation continuity are addressed in the next-steps section.
Audio delivery and offline storage
Audio was the starting point of the project, and it required more than a player component. I separated authorization, media download, local storage, and playback so each could handle its own responsibilities.
The client requests a license using its authenticated identity and device public-key information. The backend returns a download URL and the associated license data. The client downloads the encrypted media and can save it locally with the metadata needed for later use.
The audio lifecycle separates obtaining a local copy from having the information needed to play it.
I stored offline audio in a dedicated local database, with encrypted media and license metadata written together in a transaction. Download progress and storage-capacity checks make the operation visible to the learner and help handle device constraints.
The completion boundary matters: the interface marks a lesson available offline only after that storage operation succeeds. A license, download, or save failure produces an error notification instead. This keeps a successful network transfer from being mistaken for a usable offline lesson.
This storage path is separate from the service worker’s application-asset cache. The interface bundle, images, and protected audio have different lifetimes and access requirements. Keeping those policies separate lets downloaded lessons support offline playback without implying that remote operations such as a new Bobcat AI request can also work offline.
Infrastructure, security, and monitoring
Infrastructure as maintained code
I defined infrastructure for the audio API, compute, storage, data tables, permissions, and key management in code. Keeping that configuration explicit makes resource relationships reviewable alongside changes to application behavior.
I also configured a remote state backend with versioning, encryption, public-access restrictions, and locking. Infrastructure state links declared resources to the resources managed by the tooling. Its protection and recoverability therefore belong in the operational design.
The frontend and backend have separate repositories, which keeps their responsibilities clear while introducing a coordination requirement: changes to a backend response or deployment configuration may require a corresponding client release. The infrastructure definitions manage the resources assigned to them; other managed integrations have their own configuration and lifecycle.
Trust boundaries and data handling
I placed AI credentials in managed server-side secrets and performed AI execution in the backend. Authenticated requests establish identity before protected backend processing. For learning progress, data rules enforce ownership at the managed data boundary.
Audio adds another boundary. The licensing backend validates identity, handles key-related operations, and returns time-limited download information. Additional entitlement enforcement depends on the configured access mode. On the device, offline audio remains encrypted in storage.
These controls address different parts of the system. A hidden interface control is not an access decision, and encryption does not replace authorization. Keeping those responsibilities explicit helped me reason about where enforcement belongs.
Monitoring the experience and its dependencies
I integrated client error and performance instrumentation alongside product-event analytics. Error monitoring helps investigate failures; events such as practice completion, flashcard sessions, and audio downloads describe how the learning experience is used.
I configured client performance tracing with a 10% sampling rate, alongside backend exception and fallback reporting for Bobcat AI. Sampling controls the proportion of client traces collected, while fallback events help identify dependency problems even when the learner ultimately receives an answer.
Monitoring also introduces data-handling responsibilities. Event properties and replay settings are part of the application’s privacy considerations, alongside the data stored for learning progress and conversations.
Building and refining the application during deployment
I developed the SCW app around my deployment responsibilities, often working during personal time between operational commitments. That made incremental delivery practical: I could develop a learning activity, use it in preparation, and refine it as the broader application took shape.
The work evolved through use. I prepared resources, used them in my own qualification study, and released features around the milestones I reached. I earned both qualifications while using the material I developed. Other Sailors’ feedback then broadened the perspective beyond my own study habits.
The development journey combined personal use, incremental delivery, and feedback from Sailors.
Leadership support helped introduce the platform across the command. For me, that meant architectural work remained close to the people using the application. I could connect a request or difficulty to a feature change rather than working only from an abstract list of requirements.
Using the app myself provided an important feedback loop, but it did not represent every device, connectivity condition, or learner. That distinction informs how I want to strengthen validation: personal use helps uncover experience problems, while repeatable checks and broader user feedback are needed to assess behavior across environments.
Results and impact
The SCW app grew from shared audio resources into a platform supporting several forms of qualification preparation. The following figures describe that experience:
| Measure | Project result |
|---|---|
| Initial landing-page interest | More than 120 sign-ups |
| Personal engineering effort | More than 2,100 hours across design, development, testing, and deployment |
| Command qualification rate during the deployment period | Approximately 11% to 65% |
| Absolute qualification-rate increase | Approximately 54 percentage points |
| Qualifications I earned while using the material | 2 |
| Application delivery targets | Web, Android, and iOS |
During that period, the SCW app supported preparation alongside instruction, leadership support, and individual study. The qualification-rate change is a command-level observation; it does not isolate the application’s contribution. Initial sign-ups likewise describe interest rather than ongoing active usage.
The medal recognized my application and electrical contributions together. Both involved designing within the constraints of deployment and delivering something others could use.
For the application, the lasting result is a foundation I can continue improving: a shared learning experience, persistent progress, RAG-based assistance, protected audio delivery, and explicit infrastructure configuration.
Current limitations and next steps
I am continuing to develop three areas of the current implementation.
Answer grounding and content maintenance. Bobcat AI can use general knowledge when the retrieved study material does not cover a question. The prompt requires that limitation to be made clear, but I want the interface to make the distinction easier for learners to recognize. I also want more systematic retrieval evaluation and content-version tracking across both retrieval paths.
Conversation continuity. The backend stores conversation turns and supports conversation identifiers. The current interface does not retain the identifier returned with an answer, so it does not yet carry that context into subsequent requests. Connecting those pieces is a specific improvement to the learning experience.
Validation and measurement. My own use and Sailor feedback informed development. I want to strengthen that with repeatable checks across platforms and clearer measurements of AI latency, fallback frequency, progress-save failures, and offline playback success. I would also establish outcome measurement earlier if starting again, so comparisons have a defined population and observation period.
What I learned
The first lesson was that direct access to users is valuable architectural input. The project started because Sailors asked for resources, and continued to evolve through their use of the platform. That kept the work connected to an actual preparation problem.
Second, a shared frontend works best when platform differences have a clear home. The native update and keyboard handling are small pieces of code, but they directly affect whether the learning experience feels dependable.
Third, building an AI assistant made content preparation an ongoing engineering responsibility. Extraction, passage boundaries, and index freshness influence the material available to the generator. Adding a fallback path expands that responsibility.
Fourth, a feature is not finished at the point where its remote request succeeds. For offline audio, the useful result is a lesson saved with the information needed to play it. That changed where I placed the success indication and how I handled failures.
Building the SCW app gave me a practical setting in which to apply architecture while remaining responsible for implementation. The connection between a Sailor’s study difficulty and a specific engineering decision is what made the work meaningful. My goal remains to help Sailors find useful material, understand it, and prepare with greater confidence.