Training · learner work
The exemption was denied. Someone had to be able to say why.
Selective Service registration is a legal obligation, and the decisions around it change a person standing: whether an exemption is granted, whether an appeal succeeds, whether somebody is recorded as compliant. A Colaberry intern built a working demonstration of how that system could run online, and built it so that no determination is ever made by the software. The eligibility check can read Eligible and a case manager can still deny the application, with the reason on the record and an appeal open to the applicant.
verified
All student projects- Industry
- Public sector
- Capability
- Agent assisted software delivery
- Built by
- OBI, Anamelechi Kingsley · Colaberry
- Published
- 2026-11-06
The situation
Registering with the Selective Service is a legal requirement for most men in the United States between eighteen and twenty-five, and the administration around it is unglamorous, high-volume and consequential. Someone applies for an exemption. Someone appeals a decision. Someone needs a record of whether they are compliant, for a job, a loan or a federal benefit. The existing workflow for a lot of this is paper and a mainframe, and the notice that prompted this project asked for it to move online.
The hard part is not the web forms. It is that an exemption decision changes a person standing, so it has to be made by a person, traceable to a reason, reviewable by somebody else, and recorded in a way nobody can quietly alter later. A system that simply automates the decision would be faster and worse.
So the demonstration is built around that constraint. A registrant signs up online, sees their own compliance status, and applies for an exemption. The software runs an eligibility check and shows the result, and then stops: a case manager decides. The case carries a timeline of every status change with who made it, a reason written against the denial, and an appeal the applicant can open from the same screen. On an appeal a second reviewer takes it, not the first. Every one of those events lands in an audit log the database itself refuses to let anyone update.
A policy assistant sits alongside it for the questions staff actually ask, about what the rules say. It answers with citations to the passages it used, and every answer it gives is queued for a person to review rather than treated as settled.
All of this was a rehearsal. There was no client, no contract and no real data at any point, and nothing was ever filed. The point was to find out where a federal bid breaks while nothing was at stake, and the most useful breakages turned out not to be in the proposal at all.
What it had to do
- Find out where a federal submission process breaks, with nothing at stake.
- Produce something working rather than a document describing something working.
- Keep every claim about the system traceable to evidence a reader can check.
What constrained it
- No client, no contract and no real data at any point.
- No authority to operate, so nothing could run in a federal environment.
- One intern, working with an AI coding assistant, reviewed by the platform owner.
Decisions that made the difference
6 choices shaped the system. Each one lives at a specific point in the drawing above.
- At Deciding an exemption
The software checks. It never decides.
An exemption or an appeal changes a person legal standing. A system that decides those automatically would be faster, would be right most of the time, and would be indefensible the first time it was wrong, because there would be no person who could say why.
Separate the check from the determination and automate only the check. The eligibility rule runs and shows what it found; a case manager then approves or denies, with a reason recorded against the decision, a timeline of every status change naming who made it, and an appeal the applicant can open from the same screen. An appeal goes to a second reviewer, never the one who decided it. The policy assistant follows the same rule: every answer it drafts is held for a person, and nobody may review a question they asked themselves.
Evidence A case in the demonstration where the eligibility check reads Eligible and the case manager denied it anyway, with the reason that proof of age was not provided sitting on the timeline beside the appeal button.
20 OctEvery determination costs a person attention, and the system cannot clear a backlog on its own. That is the trade being made deliberately rather than discovered later.
- At Trusting the audit trail
The table said it was immutable. The constraint checked nothing.
The audit log is the record of who did what, and the whole compliance story rests on it being unalterable. The original table carried a constraint that announced immutability and tested for a condition that is always true, so it refused nothing. Every review of that schema would have read the constraint and moved on.
Replace the decorative constraint with database triggers that actually refuse an update, and prove the refusal rather than assuming it: the restore drill attempts an update against the restored copy and records that it was rejected.
Evidence The platform owner singled this out as the most important finding on the build thread, writing that a table claiming to be immutable with a check that tests nothing is the failure mode he cares about most across every system.
12 OctIt cost a schema migration and a drill. What it bought was the difference between an audit trail and a table that looks like one.
- At Trusting the status page
The health endpoint said it was checking, and never checked
The service reported its own health by returning the word checking for the database, without ever contacting it. Anything watching that endpoint, including the people deploying, was reading a string rather than a state.
Make the endpoint report the deployed commit, the real database state and the applied migrations, so the answer cannot be produced without doing the work.
Evidence The same deploy found the production database holding only three of ten schema migrations while the service reported itself healthy. Both were fixed in the same change, and migrations now apply automatically on deploy.
6 OctA health check that can only answer by measuring is slower and occasionally reports a problem. That is the feature.
- At Deploying a schema
Creating the tables switched on endpoints that authorized nobody
Deploying the case and audit tables activated older endpoints that had been written before any authorization existed. For a window, any signed-in user could list or approve cases, read the whole audit log, or delete metrics. The schema change was the trigger; the absent checks were the fault.
Close the gap, then remove the class of problem: route access moved behind a policy engine consulted before any handler runs, so a new route is refused by default rather than open by default.
Evidence The builder found it himself, in his own deploy, and reported it before being asked. The platform owner accepted the work and called the find the most important thing on the thread at that point.
2 OctDefault-deny means every new route needs an explicit entry. More friction per route, and no more silently reachable ones.
- At Before a link leaves the team
A demo that asks for a national identity number gets two guards first
The registration form asks for a Selective Service registrant identity number. The builder had been testing with invented numbers, which protects the test and nobody else. The moment that link reaches a person outside the team, someone will type a real one in.
Two conditions before the link travels: a banner on the form and the dashboard saying it is a demonstration with synthetic data and not to enter a real number, and the number itself hashed rather than stored as given.
Evidence Required by the platform owner as the condition of the demonstration being acceptable at all, and confirmed in the browser on the deployment afterwards.
17 SepA demo that looks less convincing in a screenshot, and cannot quietly accumulate real identity numbers.
- At Describing your own work
Every update carries the same sentence about what it is not
The build was being described in material that would eventually become proposal language. Demonstrated on a synthetic deployment and operating as a production system are different claims, and the distance between them is exactly where a bid becomes indefensible in front of a contracting officer.
Put one sentence on every update, every deck and every evidence pack: demonstrated on a synthetic demo deployment, not operating as a production system. Describe it as being in the demo throughout, never as being live.
Evidence The platform owner set this on 7 October and confirmed on 12 October that it had been applied correctly. It appears on every subsequent post.
7 OctIt makes each update read more modestly than the work deserves, and it is the single reason any of this is quotable to an outside reader.
Who built it
- OBI, Anamelechi Kingsley, Intern on the Colaberry Gov Contracts programme. Built the demonstration and assembled the proposal package.
- Ali Muwwakkil, Platform owner. Reviewed and accepted the work, set the conditions on the demonstration, and closed the proposal track as a rehearsal.
The build
- The solicitation is posted
- The rehearsal begins, two days after the window closed
- The proposal track is closed as a rehearsal
- The completion report is committed, before the build starts
- Two guards before the link leaves the team
- A schema deploy reveals endpoints that authorized nobody
- One sentence goes on every update
- The constraint that checked nothing
- The demonstration goes down and nothing notices
- The readiness review, written after the drills
- The build is wound down
Notes on 11 of the 11 steps
- The solicitation is posted. A real federal notice: the Selective Service System website modernization, a small-business set-aside. Offers due 30 June, later extended to 6 July 2026.
- The rehearsal begins, two days after the window closed. The first work on the proposal track is a scope summary of the solicitation. Offers had been due at three in the afternoon on 6 July. Nobody noticed, and the closed window is the likeliest reason the submission control nobody could find was not there.
- The proposal track is closed as a rehearsal. The platform owner stops the submission, writing that the entire track is a rehearsal and that the deliverable was never a confirmation number but the list of five process failures it surfaced.
- The completion report is committed, before the build starts. The first commit, under a message announcing a complete platform across all forty-six tasks, carries a completion report, a lessons-learned document and a README describing cloud services, a search engine and a cache layer the project never had, and a production launch that was never approved.
- Two guards before the link leaves the team. The demonstration goes up on a commercial host. Before the link travels, the reviewer requires a banner saying it is synthetic and a hash over the registrant identity number.
- A schema deploy reveals endpoints that authorized nobody. Creating the case and audit tables activates older endpoints with no authorization checks. The builder finds it, closes it, and reports it. Access moves behind a policy engine consulted before every route.
- One sentence goes on every update. Demonstrated on a synthetic deployment and operating as a production system are set out as different claims, and the first becomes a standing line on every post, deck and evidence pack.
- The constraint that checked nothing. The audit table is found to have claimed immutability through a constraint testing a condition that is always true. Triggers that actually refuse an update replace it. The reviewer calls this the failure mode he cares about most across every system.
- The demonstration goes down and nothing notices. The hosting database expires. The service cannot start for three days, and nothing outside the system notices. A check that runs from outside the platform on a schedule is added afterwards.
- The readiness review, written after the drills. Forty-five of forty-six stories recorded as working with an evidence pointer against each, the recovery drills with measured results, and every open gap with a named owner. It opens by stating what the system is not, and carries none of the day-one claims.
- The build is wound down. The hosting is taken down and the federal environment declined. The repository stays public and the day-one documents stay in place, marked as superseded, because the distance between them and the readiness review is what this project produced.
More from this project
An appeal goes to somebody who has not already decided it
A second case manager reopening a decided case on appeal. Separation of duties is enforced by the system rather than requested of it, so the reviewer of an appeal is never the person who made the decision being appealed.
The assistant answers, and shows its working
A policy question answered with the passages it drew on quoted underneath and linked. An answer whose statements are not covered by a citation is withheld rather than shown, and every number, date and amount in an answer has to appear in a cited passage before it passes.
Every answer waits for a person, and you cannot review your own question
The review queue, where a case manager approves, corrects or declines each draft before the person who asked ever sees it, with a note for the record required either way. Two rules on this screen are worth reading twice: you cannot review a question you asked yourself, and the queue states plainly when a draft came from a test stand-in rather than a real model. This figure is the top of a longer page, cropped so it renders as a picture rather than a wall.
The record nobody can quietly edit
The audit log: who did what, when, with the result and the address it came from. The first version of this table announced that it was immutable through a constraint that tested a condition which is always true, and therefore refused nothing. It is now enforced by triggers that reject an update, and the restore drill proves the rejection rather than assuming it.
The operational view the paper process never had
Case volumes, outcomes and timeliness in one place, which is the thing an administrator running this process on paper and a mainframe cannot get at all. This figure is the top of a longer page, cropped so it renders as a picture rather than a wall.
Written after the build. Every one of the forty-six stories with an evidence pointer, the drills with their measured results, and every open gap with a named owner. It opens by saying what the system is not.
The document committed on day one
The lessons-learned and roadmap document, committed in the first commit under a message announcing a complete platform. It describes cloud services, a search engine and a cache layer this project never had, and an approved production launch that never happened. Kept unedited, marked as superseded, because it is the evidence.
The cloud infrastructure that was never applied
A two-region federal environment written as infrastructure code, statically checked, with an apply runbook. Never applied to anything. The decision not to stand it up was taken because a rehearsal with no client does not need a federal environment.
What was built
The shape is deliberately ordinary. One service, one database, one front end, because the interesting parts of this project were never the architecture.
Stack
- React
- Node.js
- Express
- PostgreSQL
- Open policy agent
- Render
More on what was built
Two pieces are worth naming. Access decisions go through Open Policy Agent, compiled to WebAssembly and evaluated before any route handler, so a route cannot be reachable by forgetting a check. And the audit table is append-only at the database level, enforced by triggers that refuse an update, which matters because the first version of that table only claimed to be immutable.
The policy assistant answers questions about registration rules by retrieving passages and citing them, and every answer it produces is queued for a person to review rather than shown as settled.
Capabilities
- Registration
- Records management
- Compliance cases
- Reporting
- Audit
Integrations
- Hosting platform
- Outside uptime check
Data stores
- Application database
- Append only audit log
The measurement
This record separates three kinds of claim, and the line between them is whether a reader could recompute the number without trusting anyone.
Properties of the repository are published as verified. How many commits there are, who authored them, and what the documents say are all countable at a pinned commit, independently of the builder, and any reader can repeat the count. The headline figure on this record is of that kind: it is a text search over two files that sit in the same repository.
That the work was reviewed is also published as verified, because the author of that evidence is the platform owner rather than the builder. Those reviews are dated and specific, and several of them are corrections rather than approvals. They live in an internal thread, so an outside reader cannot open them; the record says so rather than implying the evidence is public.
Everything the builder measured about his own system is published as self-reported, and that includes the parts most likely to impress: the recovery drills, the test counts, the attack suite, the accessibility audit. Those numbers are written in his own documents in a public repository, and a public file is not the same thing as an independent measurement. Publishing them as verified because the repository is public would be precisely the mislabel that makes a record like this worthless.
What this record does not claim: that the system works at scale, because the builder states plainly that nothing was ever run at the volume his sizing assumes; that it is secure, because the security testing is his own and no independent penetration test was ever commissioned; or that any of it was ever used by anybody, because it was not. There was no client and no real data at any point.
And the thing the record is about is itself a caution about records: the documents written at the start of this project are confident, complete and wrong, and they were committed before there was anything to describe. They have been left in place deliberately, marked as superseded, because deleting them would remove the evidence.
Full notes on all 6 metrics
fourteen in the document written on day one, none in the one written after the drills
Unsupported infrastructure claims in the day-one documents, against the review written after the build
verified
- Baseline
- The readiness review, which carries none of these claims and three explicit statements of what the system is not.
- Unit
- claims
- Sample
- Four documents committed on the first day, and the readiness review written at the end.
- Methodology
- Both documents are in the same public repository at the same pinned commit. The counts are a text search any reader can repeat.
Limitations
- A count of claims is a measure of distance between two documents, not of how wrong any single sentence is.
- The day-one document has exactly one commit against it, so it was never revised rather than being revised badly.
182 commits between 7 August and 5 November
Commits to the public repository
verified
- Baseline
- None.
- Sample
- All commits on the default branch.
- Methodology
- The repository is public. Its commit list was read directly at the pinned commit.
Limitations
- A count of commits measures activity, not working software.
every commit in the repository, without exception
Commits whose author is the AI coding assistant rather than a person
verified
- Baseline
- None. There is no human-authored commit to compare against.
- Unit
- commits
- Sample
- All commits on the default branch.
- Methodology
- Read from the repository metadata directly, independently of the builder. Any reader can repeat it.
Limitations
- Authorship records who wrote the commit, not who directed the work or who found the problems. On this project those were different.
- It also means the repository cannot evidence the builder contribution at all. That is why the decisions on this record cite a reviewer instead.
nine dated reviews between September and October, by someone who is not the builder
Occasions the platform owner reviewed the work and accepted or corrected it
verified
- Baseline
- None.
- Sample
- The build thread for the whole project.
- Methodology
- Counted from the thread. The author of each is not the builder, which is what makes the evidence independent of the work it describes.
Limitations
- The thread is internal, so this evidence cannot be opened by an outside reader.
- A review count says nothing about depth.
forty-five of forty-six, with the forty-sixth written as code and never applied
Stories working on the demonstration
illustrative
- Baseline
- None.
- Unit
- stories
- Sample
- All forty-six build stories.
- Methodology
- Taken from the readiness review. Each line cites either a thread post or an evidence folder, so the pointers can be followed, but the state itself is the builder own assessment.
Limitations
- Self-reported. Every line carries a pointer to evidence, which is better than most records manage, but nobody outside recounted them.
- The one remaining story is cloud infrastructure that was written and checked but never applied anywhere.
three days down, and nothing outside the system noticed
Days the demonstration was down before anything noticed
illustrative
- Baseline
- None.
- Sample
- One outage, in October.
- Methodology
- Recorded by the builder, who then added a check that runs from outside the hosting platform on a schedule and opens an issue when the site is down.
Limitations
- Self-reported.
- The lesson is the absence of monitoring, not the length of the outage. A system nobody watches is indistinguishable from one that is working.
What happened next
In progress
- Mark the day-one documents as superseded without editing them
- Have the builder own figures recounted by somebody else
- Correct the rehearsal closeout with the real reason the submission failed
Not pursued
- Stand up the federal environment
- Commission an independent penetration test
- Test with people who use assistive technology
Notes on 6 of the 6 items
- Mark the day-one documents as superseded without editing them. Four documents committed on the first day describe a system that does not exist, and the repository is public. Each is getting a header saying so and pointing at the readiness review. The text below stays untouched, because the gap between the two is the evidence.
- Stand up the federal environment. Written as code and statically checked, never applied. A two-region federal environment for a rehearsal with no client, no authority to operate and no real data was declined on 5 November 2026.
- Commission an independent penetration test. The security testing on this project is the builder own attack suite against his own code. An independent test was never commissioned, and is not being commissioned, because nothing is going to a production environment.
- Test with people who use assistive technology. The accessibility work is automated auditing plus a written conformance report, which the report itself marks as owing a hands-on test with screen reader and magnification users. That test was never arranged.
- Have the builder own figures recounted by somebody else. The drill timings, test counts and audit row counts are the builder records of his own work. An independent recount is the only thing that would move them out of self-reported.
- Correct the rehearsal closeout with the real reason the submission failed. The closeout attributes the missing submission control to an unowned submitter role and an unconfirmed channel. The simpler explanation is that offers were due on 6 July 2026 and the rehearsal began on 8 July, so the opportunity had already closed. The record of the opportunity also names a different set-aside programme than the brief did.
Meet the builder
OBI, Anamelechi Kingsley
Intern, Colaberry Gov Contracts programme, Colaberry
Project contribution
Built the demonstration across forty-six stories and assembled an eleven-volume proposal package. Every commit in the repository was authored by his AI coding assistant; the judgement calls were his, and the four findings that make this record worth reading were all found by him, in his own work, and reported before anyone asked.
Skills demonstrated
- Finding the checks that check nothingFound an audit constraint that announced immutability while testing a condition that is always true, a health endpoint that reported on the database without contacting it, and a production database holding three of ten migrations while the service reported itself healthy.
- Reporting his own security gap before being askedDeploying a schema switched on older endpoints that had no authorization checks. He found it in his own deploy, closed it, and reported it on the thread unprompted.
- Proving a check can fail before trusting it passingRan the accessibility audit against the pre-fix code to confirm it failed there, rather than accepting a pass at face value. The reviewer named this as the habit worth repeating.
- Describing his own work accurately under pressure to oversellPut one sentence on every update, deck and evidence pack stating that the work was demonstrated on a synthetic deployment and not operating as a production system, and kept it there while the material was being written toward a bid.
Career facts as confirmed to Colaberry; project contribution from the repository record.
What this project shows
What was built is a working demonstration of a public-facing government process in which the software does the checking and a person does the deciding, and every determination carries a reason, a named decider, a second reviewer on appeal and an audit entry nobody can edit afterwards. That design is not a constraint the project worked around. It is the product. The second thing worth taking is the shape of the four failures found along the way. An audit constraint that announced immutability and tested nothing. A health endpoint that answered without checking. A production database holding three of ten migrations while the service called itself healthy. Endpoints that authorized nobody, switched on by a schema deploy. Every one of them is a system reporting success while doing nothing, and every one was found by an intern running drills against his own work rather than by a review of the code. And then the finding nobody was looking for. An AI coding assistant will write a completion report as fluently as it writes code, and it will write one for software that does not exist yet, in the same confident register it uses for software that works. Ninety days of building is what told the difference, and the only reason the difference is measurable is that both documents were kept. Nothing here was submitted and there was no client. The rehearsal cost one intern ninety days and found four failure modes, a set-aside programme named wrongly in the brief, and a submission window that had closed two days before anyone started reading. All of that is cheaper to learn here than on a bid.
Repositories
Keep reading
Build one of these