📦 EVERY ENTRANT GETS A FEEDBACK FILE 📦 🔍 HOW WE READ THESE We cloned every repo and pinned it to its last commit before the deadline. Seventeen of eighteen had nothing after it. Then we did what the rubric asked, for every entry. We read the schema in reference/ first. We found the rule for a field with no source. We ran your folder three times: on the input you shipped, on that input with something the schema needs cut out, and on that input with irrelevant material stapled on. Then we picked five claims from your own output and found where each one came from in the input. That trace table is in your file. Five claims, five locations. You can see exactly where we looked and what we found. Every entrant shipped an input. That alone made this the most checkable field we have judged. 📚 WHAT THE FIELD TAUGHT Three lines split eighteen builds: ✅ The degraded test broke almost nobody. The rubric expected most entries to fail here, handing back a shorter document when the input ran short. Seventeen of eighteen kept the full shape and marked the gap. Name the hard case precisely and this community builds for it. ✅ The one way to lose held for seventeen of eighteen. The brief named it: put something in the output that was not in the input. We traced five claims in every entrant's own committed output. One entry had it. The near misses all had the same shape. The quote was real, and the value, the link or the sentence written next to it was not checked. Sixteen entries ship a checker, and we planted a fault in every one. Fourteen caught it by name. The two that missed had that same blind spot. ✅ Drop nothing turned into keep everything. Seven builds have a contract that cannot ignore anything, so a stapled email became a compliance row, a speaker, or an allergen. Every leaked line was quoted and cited, so nothing was invented. It was still noise on the page. Coverage and noise rejection pull in opposite directions, and only a few builds wrote down which one wins.

🎁 $1,000 IN EDUBAWARE CREDITS 🎁 One winner takes it. 📋 THE CHALLENGE Build a folder-based AI translator that takes one kind of work and turns it into another kind of work. Same shape in, same shape out, every time. Not a summarizer. Not a writer. A converter with a contract. This week's deliverable is one translator folder that someone could drop into a Claude project, feed it the input it expects, and get back the output it promises. Every time. Without surprises. 🎯 PICK YOUR CONVERSION The conversion is yours. Pick one you do by hand right now and hate. A few sparks to get you thinking: - 📞 Sales call transcript → CRM notes in your team's exact fields - 📝 Long-form essay → LinkedIn carousel, slide by slide - 🎙️ Meeting recording → product requirements doc - 🔬 Research paper → investor one-pager - 🐛 Bug report thread → Jira ticket with repro steps - 📧 Customer email → support ticket with severity and category - 📊 Spreadsheet export → weekly status update - 📖 Interview transcript → case study draft - 🧾 Receipt photos described in text → expense report line items - 📋 Discovery call notes → SOW first draft The more locked-down the output, the better. "Turns notes into a doc" is not a contract. "Turns discovery call notes into a five-section SOW where section 3 is always scope exclusions" is. 🔥 THE ANGLE THIS WEEK Last comp was The Auditor. Every finding cited a provision so a reader could open the standard and check. The comp before that was The Cartographer. Every card cited a file and a line so a reader could open the source and check. The Translator is the same discipline, one more time. Every line in the output traces to a line in the input. ↔️ A translator has three properties that a summarizer does not: 1. The output has a fixed shape. Same fields, same order, same format, regardless of what the input looked like. If the input was messy, the output is still clean. If the input was short, the output still has every field, marked empty where there was nothing to fill it.

Following along here, I have just secured a very large project. "Turn our messy internal documents into an ICM system allowing us to automate large swathes of manual admin". Before I met with the prospect, I'd been re-watching and reading everything that's going on in this community. I wouldn't have had the confidence or baseline knowledge to approach a project like this without this group! I wanted to pass on a huge thanks to Jake and the team. I'll share what I am building (as much as I can) and no doubt I will have a ton of questions!

We're down to the last 7. Enrollment closes Saturday, September 5th. Cohort kicks off September 12th. Once these are gone, the doors shut. No exceptions. - 12 weeks - 3, 3 week sprints - 3 cohorts - $250k+ in prizes - Eduba's first ever AI certification - Access to all 3 cohorts recordings, not just yours. You'll be building alongside the people in this community who decided to stop watching and start doing. First come, first served. No waitlist. No holds. Want to talk it through first? Grab a call: https://lyceum-academy.com/booking-page Ready to lock in your seat? Go here: https://whop.com/checkout/plan_MfAFNOmEEXHg7 Already in? Read this. A lot of you still haven't sent in your onboarding form. @Shirsho Guha is handling onboarding and he needs your form to get you set up before the 12th. Get it to him ASAP. Don't be the person scrambling the night before we start. See you on the 12th!!!

💰 $500 CASH 💰 One winner takes it. 📋 THE CHALLENGE Build a folder-based AI auditor that checks something against a specific standard and reports where it falls short. Not your opinion of what's good. An actual standard that exists in the world. This week's deliverable is one auditor folder that someone could drop into a Claude project and use to check their work against the rules of their industry. 🎯 PICK YOUR STANDARD The standard is yours. Pick one that actually exists. Pick one you could point someone to. A few sparks to get you thinking: - ♿ WCAG 2.1 AA accessibility audit of a web page - 🔒 GDPR audit of a privacy policy or data flow - 📋 SOC 2 readiness audit of a security policy doc - 📄 Contract audit against standard SaaS data-handling clauses - 🏗️ Code audit against a specific style guide (PEP 8, Airbnb JS, Google Java) - 🏥 HIPAA audit of a patient intake process - ♻️ Brand compliance audit against a published brand guideline - 📊 Financial model audit against FAST modeling standards - 🎓 Grant proposal audit against a specific foundation's published criteria - 📱 App Store submission audit against Apple's review guidelines - 🧾 Invoice audit against a client's stated payment terms The more specific the standard, the better. "Audits for quality" is not a standard. "Audits a React component against the WCAG 2.1 AA success criteria" is. 🔥 THE ANGLE THIS WEEK Last comp was The Cartographer. Forty of you built maps where every card cited a file and a line, and we cloned the territory to check the cards against source. The ones that held up were the ones a stranger could verify. The Auditor is that same discipline pointed at a rulebook instead of a codebase. ⚖️ Every finding cites a provision the way every card cited a line. The standard is the territory. The audit is the map of where the artifact sits against it. Three things separate a real audit from an opinion: 1. The standard is external and citable. Your auditor should be able to say "this fails WCAG 2.1 success criterion 1.4.3" not "this contrast looks low to me."