Why Ometek has a 'rejected' status, not a 'wrong'.

When I was designing the submission flow, I got stuck on a word.

The flow itself was straightforward enough: student marks a problem as submitted, I review it, and then one of three things happens — I approve it, I mark it as done on their behalf (usually when we went through it together in a session), or I send it back. That third state needed a name. The obvious candidates were "wrong" or "failed". Both are accurate in a narrow technical sense. Neither is what I wanted on the screen.

I chose "rejected" instead, and I want to explain why that small choice matters.

The word you use is part of the system

Language isn't neutral inside a feedback loop. When a student sees "wrong", the grammar points at them — they were wrong, their reasoning was wrong, their intelligence was wrong. It attaches the failure to identity. "Rejected" points at the submission. The submission didn't pass this time. The submission goes back for revision. That's a transactional frame, not a moral one.

This isn't a subtle psychological trick I'm especially proud of. It's more like: I knew from coaching that kids who get stuck in a shame spiral after a wrong answer go dark. They stop submitting. They come to the next session having "not gotten around to" the problem. The silence is the tell. If the platform's vocabulary triggers that spiral, the whole review loop is poisoned before it starts.

"Rejected" keeps the relationship between the student and the work, not the student and their self-worth.

The rules I built around the word

Naming a state is one thing; designing the mechanics around it is another. A few decisions fell out of the "rejected is transactional" frame:

• No XP penalty. A rejected submission costs nothing. You were brave enough to submit; you don't get punished for my judgment call that it's not quite there yet. XP only moves in one direction on this platform: up, and only when work gets approved.
• No streak break. Activity streaks track the days you showed up. Sending something back for revision doesn't cancel that you showed up.
• The history stays intact. When a student fixes and resubmits, the system creates a new record rather than overwriting the old one. The original submission date is preserved. So the audit trail shows the journey — submitted, rejected, resubmitted, approved — not just the clean final outcome. I can see how long the fix took. The student can see the arc.

That last one matters more than it might seem. A student who resubmits within a few hours and gets approved didn't "fail" in any meaningful sense. They iterated. The record should reflect that, not erase it.

In practice, the turnaround on rejected submissions is usually hours, not days. Before I had the platform, "your solution isn't right" in a chat message could go unanswered for a week. Now the same feedback, delivered inside the system with a clear status change and a note, typically comes back the same day. The transactional frame seems to help.

The one thing I'm still not sure about

There's a decision I made that I revisit every few months: the "rejected" status is visible to parents.

The parent view on this platform is intentionally limited — they see activity, progress, rank, and the calendar of when their kid was working. They don't see my coaching notes or the full internal state of each problem. But the high-level status of an assignment — including whether something is currently sitting as rejected — is visible to them.

My reasoning was transparency: a parent who sees their kid is active but has a string of rejected items can ask about it from a place of curiosity rather than confusion. "I see you've been working on the segment tree set — how's that going?" is a better conversation than "the coach says you're making progress but I don't really know what that means."

The counter-argument is that "rejected" might read as "failing" to a parent who doesn't know the design intent behind the word. They didn't read this blog post. They see the label in a digest and worry.

I haven't changed it, but I haven't fully resolved it either. If you're building something similar, that's the tension worth sitting with: visibility to stakeholders is good, but only if those stakeholders have enough context to interpret what they're seeing.

Language is infrastructure

The word "rejected" is not the important part of the Ometek platform. The review system, the coach relationship, the problem quality — those are what actually matter. But words are infrastructure too. They shape the emotional environment in which everything else operates.

If the word your platform uses for "didn't make it" makes students defensive, or makes them feel judged rather than guided, the feedback loop stops working regardless of how good your problems are. The vocabulary of failure is worth choosing carefully.

I picked "rejected" because it keeps the conversation about the work. That's the only conversation worth having.