FluxEngine is the coach-outreach system inside Northline Recruiting, the made-up client name used on this site to protect the real company’s identity.

A recruit authorizes their Gmail account once. Staff choose college coaches from a live directory, write one message in the recruit’s voice, generate controlled wording variants, and launch a campaign. FluxEngine schedules and sends each email from the recruit’s own address, tracks opens and clicks, preserves unsubscribe and bounce suppression, and stops when identity or transport state becomes unsafe.

The system’s governing law is simple:

Nothing a coach can see should betray automation.

Everything else—variants, timing, ownership, footer design, directory matching, and the decision not to add a convenient Reply-To—exists in service of that sentence.

A successor, not a resurrection

FluxEngine descends from RecruitMail, an earlier system that sent more than 120,000 real messages before the company using it wound down.

That history matters because it supplied a mechanism already shaped by real inboxes: rolling sender caps, same-school spacing, token-revocation behavior, retry law, bot filtering, suppression, and the strange failure modes that do not appear until mail meets institutional infrastructure.

It is not FluxEngine’s production census.

The predecessor database remains a read-only archive. Its Google project is never reused. FluxEngine lives inside Northline’s application, database, API, and organization-owned Google project. Tokens were re-keyed from team identity to recruit identity. Staff became operators rather than senders. Historical mail stayed behind while suppression facts and contact facts crossed through a guarded importer.

This was a port of knowledge, not a copy of ownership.

The kid sends

Every coach-facing message leaves through Gmail as the recruit.

Staff create and operate campaigns, but they do not become the visible sender. Internal alerts use a separate transactional-mail channel. A Reply-To pointing elsewhere was rejected because it would expose the second actor. The unsubscribe mechanism is real, visible, and deliberately separated from the body by whitespace—but not hidden through matching colors, because hidden text is itself an automation and spam-filter signal.

The authenticity law also governs copy generation. Fifteen variants reduce message fingerprinting, but they do not manufacture fifteen different strategies. The message remains recognizably the recruit’s. Variation exists to keep infrastructure from mistaking legitimate individualized outreach for a single bulk template.

This is not theatrical personalization. The sender identity, mailbox, and delivery path are genuine.

The queue is a schedule

The predecessor engine interlaced recipients from different schools while it sent. In practice, three positions at thirteen seconds each yielded thirty-nine seconds—far short of the required 180-second gap before another coach at the same athletic department.

FluxEngine replaced that live improvisation with the Ariadne Thread.

Before the first Gmail call, a pure scheduling function—the Loom—assigns each queued message a concrete send_after time. Its governing expression advances time to the latest of three constraints: the previous send plus the ordinary delay, the last message to that school plus the school gap, and the opening of the recipient’s local business window.

The sender’s job becomes smaller and safer: find a due message, claim it atomically, recheck the transport laws, send it, and record the result. It does not continuously redesign the campaign while delivering it.

Current engine laws include thirteen seconds between ordinary sends, 180 seconds between coaches at the same school, a rolling cap of 450 per sender per day, a ceiling of 950 authorizations per launch, no more than three campaigns sending concurrently, and capacity for twenty active campaigns. The 950 ceiling counts attempts that have actually claimed authorization so a failure storm cannot turn the cap into a suggestion.

Re-spinning a campaign changes its times, not its order. After live use exposed the need, the re-spin also respects send history rather than laying a new schedule as though previous delivery never happened.

Authorization is atomic

A materialized queue is not permission to send.

Each message must be claimed inside the same transaction that authorizes the send. Transport must be enabled. Tracking and unsubscribe routes must be structurally mounted. The sender must remain inside its daily limit and cooldown window. Another campaign cannot already be using the same Gmail identity. A global kill switch can stop new dispatches without mutating campaign or message status and without destroying the untouched queue.

The kill cannot recall a Gmail request already in flight. The architecture names that boundary instead of promising magic.

This separation matters because an operator interface is not a security boundary. A button can say Launch while the server says no. Queue construction is allowed to continue while transport is stopped, because preparation and permission are different facts.

Suppression survives every import

Unsubscribe and bounce suppression are compliance data, not cleanup candidates.

A contact import can refresh a title, school, region, or phone number. It cannot silently make an unsubscribed coach sendable again. Queue construction excludes both bounced and unsubscribed contacts. Staff browsing excludes bounced contacts but may still show an unsubscribed one because visibility and sendability are deliberately different questions.

The importer has two operating modes: one historical load from the predecessor archive and a repeatable replacement path for later directory refreshes. A test harness for that replacement was one unguarded operation away from deleting all 8,042 imported coach-contact rows. A refusal guard stopped it at the full denominator.

The live system also treats the database API’s 1,000-row cap as a law. Every surface that can exceed it paginates explicitly or aggregates inside Postgres. A return of exactly 1,000 rows is presumed truncated, not celebrated as a convenient round total.

The selector that died on contact

Coach job titles are free-form strings: Head Coach, Assistant Head Coach, Assistant Coach (Linebackers), and thousands of institution-specific variations.

The first serious selector organized those titles into a cascading Role → Position interface with live counts. It shipped and died the same day somebody walked it in the browser.

Substring matching made “Head Coach” include assistants. A specification claimed an overshoot decision I had never made. The first correction attempted comma-stripped matching and tested clean against a fixture population where the relevant comma shape did not occur.

The live replacement is a flat checklist derived from terms actually present in the directory. It has no Role and Position headings, no free-text guess box, and no counts printed beside terms. Matching uses exact normalized title segments in JavaScript after an over-inclusive database prefilter.

On August 29, 2026, the selector offered 57 boxes. Every one returned at least one title. Those terms reached 7,738 of 8,101 non-blank titles; the 363 outside the set were the administrative tail rather than coaches the interface should pretend to classify. “Coaches” returned the same 8,102 contacts as no title filter. Exact Head Coach returned 805 rather than the prior substring result of 1,227.

The correction is a useful example of a recurring rule: a taxonomy does not become true because it produced a polished control.

Tracking data is adversarial by default

Opens and clicks are not clean human intent.

University and corporate mail infrastructure automatically opens messages and visits links for security. If those events are credited without inspection, the engagement layer promotes scanner behavior into a sales signal.

FluxEngine records public tracking events, marks bot-suspect patterns, and rolls back engagement previously credited when a cluster crosses the detection threshold. Scoring excludes suspect traffic. Suppression and unsubscribe remain independent of whether an event looked human.

The exact heuristics are a posture, not a permanent victory. Mail providers change privacy and security behavior on their schedule. The system therefore treats engagement as evidence with provenance rather than a clean count labeled interest.

Hard Wall

Northline owns the Google project, OAuth consent, database, and mail identities used by FluxEngine. The predecessor company’s cloud assets are never touched. Skip’s Google project and FluxEngine’s Google project are also separate, with distinct environment-variable families.

That distinction was not merely documented. The first live OAuth mint returned Skip’s client identity and a localhost callback because six environment reads used the plausible but wrong variable family. Six review passes missed it. The correction re-pointed the reads, then pinned the separation as an invariant.

FluxEngine requests the Gmail-send capability needed for delivery. A broader read scope required for later reply detection remains deferred rather than smuggled into the first verification filing. The August 28 proof census still contained only founder-controlled and fictional test sends. That was a dated pre-launch baseline, not the system’s current status. FluxEngine is now in active production use.

Where it stands

FluxEngine is mounted in the Northline production API and operator application and is running active campaigns. The OAuth flow, campaign builder, durable send worker, tracking and unsubscribe routes, contact importer, operator surfaces, transport gate, Ariadne schedule, and exact title picker are live. The credential-free suite closed August 29 at 255 passing tests.

The open edges are named. Google verification remains a human-controlled filing. One index-usage clock must mature before a leftover index can be removed. The suite still owes a proof that a green count cannot hide skipped assertions. A General selector term is logged rather than ruled. The family digest had only one internal recipient when last measured and is not presented here as a mature retention channel.

FluxEngine is the migration story I care about: preserve the behavior that real production taught, discard the ownership and architecture that no longer fit, and make the new system prove which inheritance is law rather than nostalgia.