Platform programs, AI governance, and the decisions behind them. Each case study covers the constraint, the call I made, and what happened.
By early 2023, GenAI tools were proliferating across Medidata with no centralized oversight. Engineering teams had no standardized access to AI-assisted development tools. Business teams (Marketing, Sales, PMO) had no governed path to adopt GenAI for operational workflows. Departments were independently submitting requests to evaluate overlapping products, and the volume overwhelmed what InfoSec and Legal could review. The intake process set up in January 2023 stopped moving within months.
The first question was who should get access first. A study published in Harvard Business Review showed that senior developers got significantly more out of AI code completion than junior developers did, because they understood the code well enough to judge and correct what the tool suggested. With that evidence in hand, I convinced leadership to adopt a top-down rollout rather than a random sample or an opt-in.
We asked each Engineering Manager across 10 teams to nominate their top-performing engineers, resulting in a cohort of approximately 50 senior developers. Success criteria focused on defect density and code churn over time, measuring whether AI-assisted code maintained quality standards rather than simply tracking adoption or output volume.
The pilot confirmed the hypothesis. When results were presented to leadership, they initially proposed a continued staged rollout, slowly expanding access over months. I pushed back: the pilot had validated the tool, and a staged rollout across 1,000+ engineers would create more operational headache than risk. A prolonged rollout would mean managing multiple tiers of access, fielding complaints from engineers waiting for their turn, and delaying the productivity gains the pilot had demonstrated. Leadership agreed to a full rollout.
The Copilot rollout covered engineering and nothing else. Marketing, Sales, Product, and other non-technical teams were discovering GenAI tools on their own and filing business cases into an intake process that had already stopped moving.
Rather than reviewing each tool request individually, I shifted strategy: standardize on Google Gemini as the enterprise-wide GenAI platform and teach users how existing tools could solve their problems. I created an org-wide Gemini Gem for standardized meeting note capture and delivered hands-on NotebookLM training to 150 non-technical employees. For many of the submitted business cases, the answer wasn't "approve a new tool", it was "here's how to do this with what we already have." Between the full Copilot rollout and the Gemini and NotebookLM work, the governed program now reaches 1,200+ people across engineering and the business.
By early 2025 the fix clearly had to be structural. I helped establish the AI Operating Committee (AIOC), which replaced the ad-hoc intake process with a governed decision-making body.
Two policy changes made the biggest impact. First, we restricted who could submit business cases. Previously, any employee could submit a tool request, which meant the committee was flooded with requests from individuals who had seen an ad or heard about a product. Under the new model, only department leads could submit, which filtered requests through a layer of business justification before they reached the committee. Second, we shifted cost ownership. R&D had previously absorbed the cost of tools requested by other departments. Under the new policy, any tool requested by a department would come out of that department's budget. This forced genuine buy-in from department leads: if they weren't willing to fund it, the need wasn't real enough.
The committee consisted of SVPs and VPs from across the organization who could report directly to the executive committee on approved tools. The immediate impact: 12 duplicated business cases were identified and eliminated. Marketing and Sales had independently submitted cases for different products solving the same problem. PMO and R&D had done the same. In several cases, we simply assigned someone to teach the requesting team how Gemini could address their need, no new tool required.
Database platforms reach end of support on a fixed schedule, and when they do, the vendor (AWS for MySQL, Microsoft for SQL Server) begins charging extended-support fees on every instance still running the old version. The fee scales with footprint. In a large, regulated environment, the footprint is substantial, so each of these deadlines arrives as a known, multi-million-dollar penalty for doing nothing.
Over four years I owned three of these migrations in sequence. None of them was technically exotic. The difficulty was getting a great many people to prioritize a change that shipped no features, against a deadline someone else had set. Together the programs avoided roughly $30M, and each one produced a lesson that made the next move faster. The most valuable of those lessons had nothing to do with databases, it was about who pays.
The first program carried a $6M penalty if we missed the AWS cutoff for MySQL 5.7. The upgrade itself was routine. Persuading dozens of engineering teams to prioritize it was not. So I ran the conventional playbook: stakeholder meetings, program newsletters, and a steady routine of locating each engineering lead and confirming, again, that their instances were moving.
It worked, but it ran entirely on me applying pressure, and the pace was capped by how many leads one person can realistically chase in a week.
A year later the next deadline arrived, MySQL 8.0 to 8.4, this time with a larger $8M penalty. We opened with the same playbook, and partway through I changed the part that actually mattered: not the communications plan, the accounting.
Until then, the penalty sat as an R&D-wide cost, which is another way of saying it belonged to no one. So I tied every database instance back to the product area that owned it (internally, an "experience") and the SVP responsible for it, and moved cost absorption to be per-area rather than pooled across all of R&D. Once an SVP could see their own line item, and own the penalty their un-migrated instances would generate, prioritization stopped being something I had to manufacture. The SVPs drove it. My role shifted from pressuring engineers to keeping the scoreboard honest. That scoreboard was assembled by hand for a single program; it is now being built into a permanent system, the Unified Ops Portal described below.
The final program was the largest, at a $13M penalty. Microsoft SQL Server was reaching end of support, and we would owe extended-support fees on every instance left behind. We began in November 2024 and spent the first month migrating nothing, only establishing how bad the situation was. It was bad.
The root problem was a piece of legacy software we licensed and hosted in our own data center. Clients bought a license, and we had no mechanism to compel them to upgrade, so roughly 30 different versions of the product were running in the field, each one potentially pinned to the database version we were trying to retire. The regulated context compounded it: every supported combination had to be formally validated, and we were performing that validation at the same time as validating new releases.
That forced two decisions before anyone could touch a server. Which versions do we actually support? We chose the most recent five. And on what legal footing do we move clients off the rest? We established a policy requiring them to upgrade to the latest version. With scope and policy settled, the remaining work was orchestration across teams that did not ordinarily move in lockstep:
To hold quality across that many handoffs, I built templates the DBA team followed step by step, which is the cheapest available insurance against a tired engineer improvising at the wrong moment. Stakeholder workshops and the usual change-management tooling kept the functions aligned. We remediated 98.5% of all affected URLs and servers. The remaining 1.5% were the genuinely stuck cases, not the easy ones left undone.
Tools accrete. Over enough years an engineering organization builds a system to track this, a dashboard to watch that, a spreadsheet someone swears by for the third thing, and every one of them is reasonable on its own. The cost shows up later, when answering a genuinely simple question (which servers are running an end-of-life OS, what is this team actually spending, where is utilization heading) means logging into five systems and reconciling them by hand. I had felt this directly. The database modernization and FedRAMP programs both opened with weeks of assembling a picture from tools that did not talk to each other.
The Unified Ops Portal is the fix. One system and one view, instead of a tour of disparate ones. It is an internal developer platform in the now-standard sense: a single front door to the operational data and tooling an engineer or a leader needs, rather than a directory of links to the systems that hold it.
This was product management rather than program management, and I ran it that way. It started with research. I studied the internal developer platforms built by the companies known for getting this right, Spotify's Backstage most prominently, along with Airbnb's internal tooling and others, to understand what a good one actually does and, just as importantly, what scope tends to sink them. From that I built the product roadmap and defined the scope: what the portal owns, what it merely integrates with, and the order in which capabilities land.
The discipline here was saying no. An internal platform fails the same way nearly every time, by trying to be everything and ending up a worse version of the tools it was meant to unify. So the roadmap is as much a statement of what the portal deliberately does not do as what it does. Getting that boundary right was the hardest and most valuable part of the product work.
The scope is now defined and largely built. The portal tracks:
The component currently in development is the financial one: attributing cost back to the teams and product areas ("experiences") that incur it. That is not a coincidence. The manual per-experience cost scoreboard that made the MySQL 8.4 migration prioritize itself worked, but it was assembled by hand for a single program and then set down. The financial layer turns that one-time scoreboard into a permanent feature, which is the portal's thesis in miniature: take the thing a program manager rebuilds from scratch every time and make it stand on its own.
FedRAMP Moderate is the bar a cloud system has to clear before it can handle US federal data, and it is built on the NIST 800-53 Moderate baseline, which runs to a few hundred controls. The gap between running a genuinely secure platform and being able to prove every one of those controls to a third-party assessor is wide, and most of the work lives inside that gap. I owned the program that closed it, which meant turning a long list of "not compliant yet" into named findings, accountable owners, milestone dates, and evidence an assessor would actually accept.
The work opened with a gap assessment against the Moderate baseline. Working with the security team, I mapped the current state of the platform to each required control and separated the ones we already satisfied from the ones we did not. That assessment produced the artifact the rest of the program ran on: a Plan of Action and Milestones, the POA&M, which is the standing register of every open finding, its owner, its remediation step, and the date it is due. In FedRAMP the POA&M isn't paperwork you assemble at the end, it's the instrument you run the program from.
Before any of that could be trusted, though, I had to establish what was even in scope. A vendor inventory established what actually sat inside the authorization boundary, and an ownership model put a specific name against every control area, so no finding could quietly fall into the gap between two teams. With the boundary and the owners settled, the rest was program management of a fairly classic shape against an unusually unforgiving deadline (an assessor's calendar). I ran a recurring remediation cadence against the POA&M, held owners to their milestone dates, and worked the dependencies that gate this kind of effort.
Those dependencies were where the program manager earned their keep. Plenty of findings could not close until another team delivered first. The unsupported-OS items, for instance, waited on the server team provisioning replacement hardware, the same hardware lead-time constraint that shaped the database modernization program. And remediation was only half of each item. The other half was evidence collection, because in a FedRAMP assessment a control you cannot evidence is a control you do not have. For every closed finding I made sure the artifact existed to prove it, not just the work.
The findings themselves spanned five areas:
Atlassian's end-of-life announcement for Jira Server forced a migration to Jira Data Center. The migration itself was routine; the environment around it was not. Jira was Medidata's source of truth for compliance, and the state of the platform reflected years of unmanaged growth. There was no API policy; individual users could create their own API keys without oversight. Change requests were ad-hoc, with no formal process for evaluating or prioritizing platform changes.
The moment that crystallized the problem: one user's automated script was sending 10,000 API requests per minute to both Jira nodes simultaneously, bringing the entire instance to a standstill for the organization. There was no policy to prevent it and no governance to catch it before it caused an outage.
I proposed reframing Jira from a tool that "just worked" (or didn't) into a platform product with defined ownership, service standards, and governance. This was more than branding, it had practical implications. The Jira admins gained a sense of ownership over the platform rather than just being reactive firefighters. Users were promised a defined level of service, including response time SLAs for Jira-related tickets, something that hadn't existed before. And the organization gained a governance structure for evaluating changes before they were made.
I established a steering committee consisting of three PMO representatives (one each from R&D, Service Delivery, and Product, the three heaviest Jira-using departments), the two Jira Admins, and myself. This committee met regularly to review and prioritize platform changes, API access requests, and integration proposals.
The API policy was the most contentious change. After the 10,000-requests-per-minute incident, we instituted a policy requiring all API requests to be reviewed by the steering committee before keys were issued. This added friction by design; the previous "anyone can create a key" approach had nearly taken down production.
The project spanned approximately 4 months end-to-end, including compliance and legal review to ensure Data Center met Medidata's regulatory standards. The actual migration was executed in a planned 8-hour downtime window from Friday evening to Saturday morning. We chose to continue with the self-hosted Data Center option rather than migrating to Atlassian Cloud, a deliberate decision driven by the compliance and data-residency requirements of the time. (The move to Cloud came later and is running now; it appears under Other Work below.)
The migration itself completed without incident: zero data loss, no rollback required. The governance work done in the months prior meant the post-migration environment was cleaner and better-managed than what we'd migrated from.
Symbridge was building a crypto custody and exchange platform that required SOC1 and SOC2 certification. A prerequisite for certification was implementing access controls governing who could access client data and platform administrative functions. This became the focal point of a stakeholder conflict between Operations and Security that threatened to stall the entire certification timeline.
Operations wanted à la carte permissions per individual. Their model: each person gets a custom set of permissions based on what they need, and Operations controls who gets what. This approach prioritized flexibility: when edge cases arose (and in a startup exchange, edge cases arose constantly), Operations could grant exactly the access needed without waiting for a role change.
Security wanted strict Role-Based Access Control. Their model: permissions are allocated to defined roles, each user is assigned no more than two roles, and access is governed by the Principle of Least Privilege. This approach prioritized auditability: SOC auditors need to see that access follows a structured model, not a spreadsheet of individual exceptions.
The tension was real. Operations saw RBAC as a straitjacket that would slow them down when unusual situations required unusual access. Security saw per-individual permissions as an audit nightmare that could sink the certification effort.
After conducting a risk analysis across both teams' requirements, I recommended hierarchical RBAC based on the NIST model. Security had evaluated and rejected ABAC (Attribute-Based Access Control) and PBAC (Policy-Based Access Control) as carrying too much implementation and management overhead for a startup-stage organization. Hierarchical RBAC offered the structured, auditable framework Security needed while providing enough role-inheritance flexibility to address Operations' concern about edge cases.
I presented the recommendation to the CEO with specific reference to the NIST RBAC paper, outlining both the security benefits and the practical downsides of Operations' preferred approach: specifically, that per-individual permissions would make SOC certification significantly harder and more expensive to maintain. The NIST backing gave the recommendation credibility that an internal opinion alone wouldn't have carried.
The recommendation was approved and implemented over the following 4 months, culminating in successful SOC1 and SOC2 certification. Admin panel vulnerabilities dropped by 30%. Notably, the edge cases Operations had worried about (scenarios where hierarchical RBAC wouldn't provide sufficient flexibility) never materialized during my tenure at Symbridge. The concerns were legitimate in the abstract but didn't reflect the actual operational patterns once the system was live.
Apple Intelligence ships Writing Tools (Proofread, Rewrite, Summarize). Russian isn't one of the supported languages, and Apple hasn't said when, or if, that changes. For roughly 260 million Russian speakers, the on-device writing assistant that exists for English, French, and a dozen other languages simply doesn't exist for them. That gap is the entire premise of Грамота. The goal was specific: bring Apple-style writing tools to Russian, fully on-device, nothing leaving the phone.
The first bet was the obvious one: take a strong existing Russian model and put it on the device as-is. YandexGPT-5-Lite-8B, an open-source instruction-tuned model from Yandex, 8 billion parameters, a 32k context window. On MLX, on an M1 Pro Mac, it ran fine. Getting it through a CoreML pipeline for actual iOS deployment was a different story. Quantized to Q4 it barely ran on iPad and didn't run at all on iPhone, and the conversion path broke outright because YandexGPT wasn't built with conventional Hugging Face Transformers formatting, so the normal tooling couldn't read the structure.
The real problem wasn't raw size, it was platform behavior: iOS and iPadOS manage memory for on-device processes far more aggressively than macOS does, the allocator never cleanly released the model, and the OS killed it regardless of how much RAM the device actually had. The limit wasn't the hardware but what the operating system lets stay resident. It survives as a Mac-only legacy branch.
Next was RuAdapt Qwen-3B, a Russian-adapted version of Qwen2.5-3B with a custom tokenizer. Smaller than YandexGPT, but not trained well enough for grammar correction without a substantial additional investment, and training it up to standard was judged a losing effort. This is also where the project's actual scale came into focus: using an 8-billion or 3-billion-parameter model to correct grammar in a text message is a bit like using a heavy-duty truck to pick up a couple of two-by-fours from Lowe's. Technically capable, wildly oversized for the job. Cut.
The third attempt went smaller and custom: a model trained from scratch on Russian, built ANE-native from day one on Apple's recommended layout and idioms, on the theory it would learn what correct Russian looks like. It did, to a point, but not the right register. The corpus was formal and academic. Nobody texting a friend or fixing a sentence needs academically precise Russian. They need their everyday, modern Russian corrected, not upgraded into something nobody actually speaks.
At 82 million parameters it was fast but had a real capacity ceiling. On its own evaluation it managed a GLEU score around 0.77 and handled roughly 40% of a 23-category error benchmark, which sounds passable until you look at what it missed. It failed entire classes of error, agreement and conjugation among them, and invented rare word forms it didn't have room to represent correctly. Fast and confidently wrong isn't a usable product. That model got scrapped.
The harder decision was to stop building from scratch and bet on someone else's pretrained model instead. FRED-T5-large, from ai-forever, around 820 million parameters. Off-the-shelf models are a specific kind of risk: you don't find out whether they can be made good until after you've already spent the time. Tested cold with no fine-tuning, FRED scored 0% on the correction task. That sounds disqualifying until you understand why: FRED is a denoising model, trained to reconstruct masked text, not an instruction-follower that's ever been asked to fix a sentence. The knowledge of correct Russian was clearly present underneath the wrong training objective. Fine-tuning was the bet.
Several hundred thousand Russian source-target pairs were generated with YandexGPT to build the fine-tuning corpus, some locally, some via API when local generation proved too slow even across parallel processes. Two bugs made the results look far worse than reality. The first: every correction came out doubled. The cause was small, the tokenizer never appended an end-of-sequence token during training, so the model never learned when to stop. Fixing it at the data-pipeline level moved the raw score from an apparent 25% to 67%. The second was the training data itself. A corpus audit surfaced "correct" targets that were themselves ungrammatical, found only by reading the target side of the pairs by hand. Both got fixed, evaluation refocused on the mistakes real people actually make (аканье and оканье, the confusion between "а" and "о" in spelling, chief among them), and the model reached about 85% on the product benchmark. It shipped as the first working version of Грамота: roughly 900 MB, 8-bit, running on the GPU.
And it was slow. About 2.16 seconds per sentence, because generating a corrected sentence means a full decoder pass for every output token. That number forced the next decision, and the next model retired this one.
The fix wasn't a smaller version of the same idea, it was a different idea entirely. Instead of writing out a new sentence, classify each word (keep it, delete it, fix its case, fix a letter) and apply the edits with plain, deterministic code. That shape is one the Apple Neural Engine runs natively, which the generative decoder never could.
The result: 246 million parameters, 99.7% of the model's operations on the ANE, about 17 milliseconds per sentence. Roughly 130 times faster. A model built this way also can't paraphrase, by construction: its edits come from a fixed menu, and rewriting a sentence from scratch isn't on it. For a proofreader whose job is to leave text mostly alone, that's the right trade.
It won on quality too. The deciding test was a head-to-head on 212 words of fresh text neither model had seen. The tagger made 13 corrections, all 13 correct. The old generative model made 21, three of them wrong, including one that changed what the sentence meant. That settled it. The roughly 900 MB generative engine came out of the app.
The most valuable fix in the whole project didn't touch the model. The evaluation set that had been steering training was rebuilt from the same pool of data the model trained on, so its scores measured memorization, not skill. One error category showed 22.6% on that eval and 4.4% on an honestly held-out one. The fix was unglamorous: freeze a benchmark that never enters training, and quarantine a fresh slice of new data every round so nothing recent leaks into it either.
The same discipline caught two more bugs nobody suspected. A theoretical-ceiling calculation for the tagger's architecture surfaced code that couldn't reproduce 38.9% of the answers it should have been able to reach. And multiplying the odds along the self-improvement loop, the one meant to feed the model new targeted examples each round, showed it was surfacing about 16 of the 1,400 examples it was supposed to, per round. The loop looked automatic and was mostly decorative. Nobody had multiplied the probabilities until then. All three checks run automatically after every training round now, because before that two regressions ran undetected for 49 rounds while the only thing watching was a dashboard.
The first honest number here was uncomfortable: the model corrected 41% of sentences that had no errors in them. Every training example up to that point contained a mistake, so the model had learned that text is always broken. Roughly a third of training is now clean-to-clean pairs. If a model needs to know when to do nothing, that has to be taught too.
Everything past that point is built around precision, because a wrong edit damages text that a missed edit merely leaves alone. The dictionary layer that catches non-word typos only fires when three conditions hold at once: the word isn't in a 422,000-form frequency list, the proposed swap matches a real typo mechanism (a sound-alike substitution or an adjacent key), and the fix is at least ten times more common than its nearest competitor. False positives on live, informal text dropped from 16.7% to 0.5%.
The most uncomfortable finding came from measuring the shipped app honestly instead of assuming it was fine. On real, messy internet Russian, the shipped tagger leaves 24% of sentences fully correct; doing nothing at all leaves 30%. On that kind of text it breaks about as much as it fixes.
A small trained judge, sitting on top of the existing ranking and deciding whether to apply the top suggestion or leave the sentence alone, beats the shipped app on every measure at once: fixes found doubled from 12% to 24%, damage down, clean text left alone up from 65% to 76%, and fully correct sentences up from 24% to 34%. Usually one of those improves at another's expense; here all four moved the right way together. The judge itself is a linear model, about six lines of arithmetic over 42 numbers the pipeline already computes, so it runs on the phone trivially. It's a research result as of this writing, not yet shipped.
Some mistakes aren't a wrong letter or a missing ending but a word mangled past recognition ("заче", "чсемьсот"). No tagger can describe a fix for a word it can't parse in the first place. That's a second, separate lane: the tagger marks the word it couldn't resolve, a small on-device Gemma model (Gemma 4 E2B) rewrites just that span, and only the marked part gets spliced back into the original sentence.
That lane is now wired into the app rather than sitting in research. The Swift port reproduces the Python reference measurement byte-for-byte, and pruning the model's vocabulary down to what Russian actually needs cut the bundle from 6.0 GB to 2.8 GB. It ships as a separate download rather than bundled with the app, since not everyone needs it every day. The same model also converts cleanly to Apple's newer Core AI runtime, with output numerically identical to the source. That's parked as a speed option gated on the next OS, not a quality change: the words it still misses are a limit of the model itself, and swapping runtimes doesn't move that.
Proofreading is free; the Tutor is the paid part. It turns your own corrected sentences into exercises spaced out over time, so you drill the specific mistakes you actually make rather than a generic lesson plan. It's built and validated: 1,120 of 1,120 generated exercises agree with the corrector. What's left there is product decisions, not engineering.
On the Mac, where there's memory and power headroom the phone doesn't have, Грамота also grew a full editor with ghost-text autocomplete, the kind of inline suggestion you accept with Tab. Same privacy rule, same offline constraint, a class of feature the phone build can't run.
Early in the project, the instinct was to assume a redesign was needed to get a model onto the Neural Engine. Instead the question got tested directly, a primitive-level probe before any redesign happened. The finding: attention mechanisms, whether written as einsum, matmul, or Apple's own fused attention primitive, never execute on the ANE, and an autoregressive decoder generating one token at a time runs at a sequence length of one, which is CPU-bound by construction. The honest conclusion at the time was that the models in hand weren't shaped for the ANE, and getting there would take a different architecture. That got deferred to a later model rather than forced.
The tagger is that different shape: one classification pass per sentence instead of one decoder step per token, closer to the encoder-style designs Apple's own ANE transformers use. The two-minute probe cost almost nothing and prevented a redesign that would have failed; the 99.7% figure is the same question answered later, on a model whose shape actually fit the hardware.
The boring part of shipping was, as always, the part that actually blocked the release. An iOS beta upgrade crashed the build, traced eventually to corrupted local Xcode checkout state and fixed by a fresh clone. A black-screen bug came from a gradient background occluded by a navigation container that renders opaque on iOS but isn't there on macOS, fixed by attaching the background to the scroll view. A blank app icon needed a cache-clearing reinstall on a physical device. A TestFlight archive failed because every build all week compiled a single architecture while an archive compiles two, and one type (Float16) simply doesn't exist on Intel Macs, so the Mac app is now arm64-only, which is fine because its headline feature can't run on Intel anyway. None of these are interesting problems. All of them stop a release if you don't find them.
Грамота ships today on the tagger: 246M parameters, 99.7% on the Neural Engine, about 17 milliseconds a sentence, live on iPhone, iPad, and Mac at version 1.3. The Gemma rescue lane for words the tagger can't parse is wired in and downloadable. The judge that decides whether to apply a fix at all is built and measured, not yet shipped. The Tutor is built and validated. The next model returns to this small-model approach with everything learned built in from the start, evaluated against the actual demographic this product serves rather than a generic benchmark score.
Грамота is on the App Store. There's a product site at gramota.troegubov.co covering what it does and how it's built. The main thing left to fix is making the app easier to use. That's a far better problem than the model not working.
Russian Orthodox Christians face a practical challenge when reading Scripture. The standard Russian Synodal Bible (1887) uses archaic language that modern speakers struggle to understand, and no Church-approved modern translation exists. Existing apps offer the Synodal text but provide no comprehension support. The opportunity was to build a single-text Bible app with an integrated dictionary of archaic terms and a liturgical calendar with daily readings.
Claude Code served as the primary development agent, with YandexGPT for Russian-language dictionary generation and Grok/Codex as secondary tools. Within 20 minutes of the first prompt, Claude generated a functional React prototype. By the 40-minute mark, all files were staged for Xcode. The transition from chat-based development to Claude Code (command-line agent with full project context) was the single biggest productivity unlock.
The original concept included a modern Russian translation alongside the Synodal text. Two factors forced a scope reduction: modern translations have unclear licensing, and the Russian Orthodox Church has never officially approved one. Rather than risk presenting an unauthorized text as authoritative, I scoped the MVP to the canonical text with comprehension support, a classic PM trade-off of reducing scope to ship a more trustworthy product.
Attempt 1: historical OCR scraping (Grok). Failed. Scraping an 1890 Russian dictionary produced systematic errors from pre-reform Cyrillic characters that no longer exist. ~$6 in API credits consumed with no usable output.
Attempt 2: YandexGPT 5 Pro. Partial success. The breakthrough was that every word needing a definition already existed in the biblical text. YandexGPT's native Russian language understanding outperformed English-first models. However, the model intermittently refused to define certain biblical terms: its safety filters were flagging religious terminology as sensitive content.
Attempt 3: Claude Code gap-filling. Success. Claude processed the remaining undefined terms with consistently higher-quality output than the other tools.
A ~1 second page-transition delay required performance profiling. Grok correctly suggested generating an Instruments .trace file. Codex couldn't analyze it without requesting access to out-of-scope directories. Claude Code analyzed the trace within its sandbox and resolved the bottleneck. This validated the security decision to restrict each agent's file system access to the project folder only: Codex later requested broader access that would have been automatically granted without the restriction.
The newest addition is the one furthest from a Bible reader: point the camera at an Orthodox icon and the app tells you which saint or subject it is, entirely on the phone, with no photo leaving it. A Core ML classifier trained on catalog reproductions runs first. If it's confident enough it names the icon; if it isn't, it shows a short "possibly this…" list from a similarity search over the same catalog rather than committing to a wrong single answer.
The honest part is where it stops working. The model is right about 65% of the time on clean shots, but a photo taken in a church, at an angle, with a wide wall around the board, falls into a dead zone: the model still ranks the correct icon first, just not confidently enough to clear the bar. So on a no-match the app doesn't give up. It offers a crop with the icon board pre-selected, and re-running on just the board is usually enough. On one control photo, cropping to the board moved the right saint from 0.36 confidence to 0.60, over the line. The thresholds are tuned on clean validation data and will need retuning on real-world photos, which is the next piece of work here.
The app shipped as Синодал and is now live on the App Store. It's at version 1.4: the prayer book, the liturgical calendar, and on-device icon recognition were added after the first two weeks. The source is public on GitHub, and the product site is at synodal.troegubov.co.
In 1944, the Office of Strategic Services (the predecessor to the CIA) published a classified field manual for citizen-saboteurs operating in Nazi-occupied Europe. The goal was straightforward: teach ordinary people how to destroy enemy organizations from the inside without getting caught, without explosives, and without drawing attention.
The manual was declassified in 2008. Reading it today is a strange experience, because the sabotage tactics described in Sections 11 and 12 (covering organizations, managers, and employees) are indistinguishable from the ordinary dysfunction of most workplaces. Not occasionally. Consistently. The manual reads like a diagnostic checklist for organizational health, written by people who understood how organizations actually fail.
That observation led to a simple question: if the manual describes how to destroy an organization through everyday behavior, does reversing each instruction produce a workable set of management principles? The answer, it turns out, is yes. And the exercise is more useful than it sounds, because the reversal doesn't produce anything novel: it produces the same principles that competent managers already follow. What the manual adds is framing: it forces you to recognize that common organizational behaviors aren't neutral, they're destructive, and the fact that nobody intends them that way doesn't change their effect.
The OSS Simple Sabotage Field Manual is 32 pages and available in its entirety from the CIA's digital reading room and on Project Gutenberg. Section 11 covers organizations and conferences. Section 12 covers managers, supervisors, and employees. The instructions require no special skills, no resources, and no cover story. They are designed to be executed by anyone, at any level of an organization, without arousing suspicion.
The manual was written for operatives who needed to blend in, so every instruction is calibrated to be plausibly deniable. Nobody who insists on "proper channels" looks like a saboteur, and nobody who calls another meeting looks malicious. The tactics work because they are ordinary.
The manual opens with instructions on decision-making: "Insist on doing everything through channels. Never permit short-cuts to be taken in order to expedite decisions." "When possible, refer all matters to committees, for further study and consideration. Attempt to make the committees as large as possible, never less than five." "Bring up irrelevant issues as frequently as possible." "Refer back to matters decided upon at the last meeting and attempt to re-open the question of the advisability of that decision."
The target is time. Every instruction is designed to consume it, with no visible act of destruction and no obvious perpetrator. The "advocate caution" instruction is particularly effective because it is almost impossible to argue against. No one wants to be positioned as the person who dismissed a legitimate concern. The saboteur gets to slow everything down while appearing to be the most responsible person in the room.
The manual's instructions for saboteur-managers are more specific, and more recognizable: "In making work assignments, always sign out the unimportant jobs first. See that the important jobs are assigned to inefficient workers." "Insist on perfect work in relatively unimportant products; send back for refinishing those which have the least flaw." "To lower morale and with it, production, be pleasant to inefficient workers; give them undeserved promotions. Discriminate against efficient workers; complain unjustly about their work." "Never pass on your skill and experience to a new or less skillful worker." "Multiply the procedures and clearances involved in issuing instructions. See that three people have to approve everything where one would do."
The manager described here does not look incompetent. They look diligent, thorough, and even principled: high standards, careful review. They are systematically destructive. The work misallocation instruction ensures that critical projects are undermanned while marginal tasks consume the best people. The promotion instruction corrodes performance norms over time.
The rank-and-file instructions operate on the same principle of plausible deniability: "Work slowly. Think out ways to increase the number of movements necessary on your job." "Contrive as many interruptions to your work as you can." "Do your work poorly and blame it on bad tools, machinery, or equipment." "Never pass on your skill and experience to a new or less skillful worker." "Snarl up administration in every possible way. Fill out forms illegibly so that they will have to be done over."
No single instance of any of these behaviors would get someone fired. Each one is explainable in isolation. Multiplied across a team and sustained over time, they are crippling. The manual is useful here as a diagnostic rather than a disciplinary tool. If these patterns are visible on a team, the first question is not who is responsible, it is what conditions are producing these behaviors. Slow work, constant interruptions, and tool complaints are sometimes genuine sabotage. More often, they are symptoms of poorly designed workflows, inadequate tooling, or unclear expectations.
The final section is the shortest and most personal: "Give lengthy and incomprehensible explanations when questioned." "Act stupid." "Be as irritable and quarrelsome as possible without getting yourself into trouble." "Spread disturbing rumors that sound like inside dope."
These are not process failures. They are interpersonal ones. The OSS included morale sabotage because demoralized organizations produce less, make worse decisions, and lose their best people. The "spread rumors" instruction describes, with uncanny precision, what happens inside organizations where leadership does not communicate clearly and frequently. Rumors don't require a saboteur. When information is withheld or poorly communicated, the vacuum fills itself.
The reversed principles are not new. Assign important work to capable people. Keep meetings short. Train new hires properly. Communicate clearly. Every management framework covers this territory.
What the manual adds is the framing. When someone proposes adding another approval step to a process, it is easy to nod along. When the same proposal is recognized as a tactic from a wartime sabotage manual, the question becomes different: is this approval step mitigating a specific risk, or is it adding delay while appearing cautious?
The exercise also makes it harder to excuse common organizational behaviors as neutral. They are not neutral. The committee that is too large to decide anything produces the same outcomes as deliberate obstruction. The manager who tolerates poor performance and penalizes reliability produces the same outcome as the manual's instruction to discriminate against efficient workers. The distinction between intentional and unintentional sabotage matters legally and morally. It does not change the outcome for the organization.
The most useful application is as a diagnostic. Read Section 11 against a team you know. Check off the behaviors you recognize: oversized committees, relitigated decisions, approval chains that nobody can justify, meetings that happen because they are on the calendar, incomplete onboarding, poor performers receiving favorable treatment, knowledge concentrated in individuals with no succession plan. The presence of these behaviors doesn't mean anyone is trying to destroy the organization, it means nobody has deliberately built against them. They are the default, and correcting them is deliberate work.