The policy engine is built. The developer on-ramp was never poured.

Station70, Inc. calls itself "The Security Backbone for the enterprise" and calls Gatekeeper the "AI human & agent control plane," sold under the line "AI security at the speed of business." The product is real and deep: a deny-by-default policy engine, a zero-knowledge (ZK, end-to-end encrypted) secrets vault, and a Model Context Protocol (MCP) gateway, backed by a web3-custody heritage the company states plainly — "protecting billions in digital assets" — now extended to the enterprise, with System and Organization Controls 2 (SOC 2) Type 2 certification, annual penetration testing, a Trail of Bits cryptography audit, and hardware-attested policy enforcement. The strength is not in question.

What is missing is the developer surface. Gatekeeper mediates every credential, tool, and system request an AI agent makes — but a developer cannot try it without talking to sales. There are no public docs, no SDK, no quickstart, no code samples, and no "View on GitHub." The strongest policy story on the market is sitting behind a contact form. That is the setup, and it is the entire reason this proposal exists.

The one stat scoreboard. Exactly one scoreboard exists across this whole proposal, and it lives here. Every value is a verifiable product-shape fact or an explicit gap — no number is a traction, funding, revenue, or customer figure; all of those are instrument. The final 0 is the honesty-as-trust-engine punch: it is stated as a number rather than a hedge, because to a security buyer a candid zero is more credible than a soft claim.

Quote the company to itself. The bridge from Station70's crypto-custody heritage to an agent-governance developer motion is already in the company's own words. Its blog names "AI/agent governance" as one of three infrastructure gaps enterprises must now close, and argues — about custody, but the logic transfers exactly — that stripping out "the policy layer" is "a liability, not a feature." Gatekeeper is that policy layer for agents. The company already believes the thesis. What it has not yet built is the on-ramp that lets a developer feel it in five minutes instead of five emails.

The window. Two clocks are running at once, toward each other. The first is the product clock: Gatekeeper is finished enough to govern real agent traffic. In this session it did — an agent connected a downstream service, hit the deny-by-default wall, cleared a policy decision, and completed a real call through the gateway. The engine is not a roadmap promise; it runs today. The second is the category clock: AI agents are crossing from demos into production, and the question every security and platform team is now asking — what is this agent allowed to do, and how do we prove it stayed in bounds? — is exactly the question Gatekeeper answers. Station70 says so in its own words, naming "AI/agent governance" as one of three enterprise infrastructure gaps to close, and tying it to a hard date: the European Union's Markets in Crypto-Assets (MiCA) and Digital Operational Resilience Act (DORA) regimes became enforceable July 1, 2026.

The window is the gap between those two clocks: the engine is ready and the demand is arriving, but the developers who would wire agents through it have no way in. Whoever publishes the first credible agent-governance quickstart, SDK, and reference architecture sets the default that teams reach for. Right now that surface is empty — so it is winnable, and winnable cheaply, because the hard part (the product) is already built.

The opening, stated as verifiable gaps (each checkable on Station70's own properties today): (1) No public developer docs, API reference, SDK, quickstart, or code samples — the deepest technical artifact is a whitepaper gated behind a contact form. (2) A 100% sales-led funnel — every call-to-action routes to Contact Sales, an on-page anchor, the architectures page, or the Trust Center; there is no "Sign up," "Start free," "Read the docs," or "View on GitHub." (3) No public changelog, roadmap, or developer/community channel. (4) A split Gatekeeper narrative, mid-pivot — a 2026-07 site review found the main site's product page still telling the earlier transaction-firewall story while the new gatekeeper.station70.com subdomain tells the AI story ("The Credential Layer for AI"); a prospect gets two different narratives depending on where they click. One conclusion: a developer who wants to try Gatekeeper today cannot, and a product whose entire value is "connected ≠ allowed" is uniquely punished by that. The fourth gap sharpens the timing: the company is visibly mid-pivot, so whoever shows up now with docs, a quickstart, and a coherent developer narrative is not decorating a finished story — they are writing it.

The honest caveat. Now is the moment if a bottoms-up developer motion fits a sales-led, security-first, web3-heritage buyer at all — and that is a live question, not an assumption (GAPS.md G8). The commercial bridge below argues directly how a developer motion feeds the existing enterprise sales funnel rather than replacing it. The window is real; the appetite is worth confirming in the first conversation, not assumed on the page.

Positioning. Gatekeeper is the policy-evaluated control plane that sits between an AI agent and every downstream service it touches — GitHub, Slack, Notion, PostHog, Stripe, and the rest — so that "connected" never means "allowed." Instead of handing an agent a long-lived token per service and hoping its prompt behaves, an agent's request is evaluated in real time against a stacked, deny-by-default policy (org rules and user rules, keyed on any of twelve dimensions), the underlying secret is released from a zero-knowledge vault only as a scoped, time-bound credential injection for that one call, high-blast-radius actions escalate to a human quorum / four-eyes approval, and every decision lands in a complete audit trail wired for eDiscovery and security information and event management (SIEM). The wedge is not "one more connector directory" and it is not "cheaper tokens" — it is the enforcement seam that turns an agent's raw capabilities into governed, revocable, provable ones. That is the same claim Station70 already makes for itself — "AI human & agent control plane," "deny by default," "AI security at the speed of business" — pointed squarely at the moment an agent reaches past its scope.

Wording and scope gaps (confirm with Station70 — do not ship as fact). Station70's own site frames Gatekeeper around MCP + REST/gRPC and "scoped / time-bound credential injection" — it does not use the word "OAuth" verbatim. This document therefore describes Gatekeeper in the site's language and reserves "OAuth" only for the alternative teams use today. The live gateway does surface per-service OAuth-style scopes in services, so the mechanism is OAuth-adjacent — but "policy-evaluated OAuth gateway" is to confirm with Station70 (GAPS.md G1), not asserted fact. The Arcade/Composio-style column describes the category, not any one vendor's current feature set (G9). And the marketing site does not list PostHog, though the live gateway does expose it as a downstream service (G2) — the comparison leans on the live surface.

An outside-in, hands-on dogfood of the live Gatekeeper MCP gateway (gw.gatekeeper.station70.com), run from an ordinary agent operator's seat — no insider access, no product walkthrough. Every quoted string below is real tool output captured in-session.

Why lead a DevRel proposal with a bug report? Because Gatekeeper's category is trust. A control plane earns adoption the same way it earns a security review: by being candid about where it stops you and why. So the field notes are the trust engine of this whole proposal — the one section a skeptical, sales-led buyer can't fake and can't dismiss.

The five-minute path I actually took. The discovery loop is three tools — services → list_tools → invoke — plus a policy-introspection triad (policy_get, policy_eval, context_reflect) and an audit_query trail. I exercised six of them live.

1. services — clean inventory, honest connection state. One call returns every downstream service, its connected boolean, and its requestable scopes:

`` posthog connected granted_scopes: [ ...74 scopes... ] github not connected requestable_scopes: [repo, read:org, read:user, ...] hubspot not connected notion not connected ``

PostHog came back connected with a granted-scope list; GitHub, HubSpot and Notion sat at not connected with no dangling error state. PostHog alone exposes ~120 requestable scopes. Scoping is real, per-service, and inspectable before you ever make a call. Good.

2. reauth / reauth_status — the connect flow (worked, in the authoring session). reauth({service}) returns a connect_url; after authorization, services flips the service to connected. A service never finished authorizing stayed not connected — no half-open state. Good.

3. invoke — and the wall. With PostHog successfully connected with broad scopes, the first real call — invoke → PostHog exec — came back:

`` policy denied: no policy decision ``

Connected, scoped, authorized… and denied. The lesson every operator learns the hard way at this exact moment: connected ≠ allowed.

policy_get — the whole stack was empty. Every layer of the four-layer policy stack carried no rules (org, org_svc, user, user_svc all has_policy: false).

policy_eval — a dry run confirmed the verdict without side effects. It returns the decision for a hypothetical call — allow / deny / approval_required — names the layer and rule that fired, and writes no audit record. Re-run live for these notes it returned:

``json { "action": "allow", "chain_name": "org-fallback", "rule_name": "org-default", "eval_time_ms": 13, "note": "Simulated — no downstream call was made, no audit record was written." } ``

A 13ms, zero-side-effect "would this be allowed?" primitive is genuinely agent-native. Excellent — and under-marketed.

context_reflect — the raw ctx the policy sees. It dumps the exact input object your evaluate(ctx) function receives — request, client, credential.scopes, live agent counters, forwarded http.headers. The downstream Authorization header is never present in ctx — the gateway strips it. Credential isolation is observable, not just asserted. Good.

audit_query — the log that told the truth on itself. The most persuasive thing I saw all session. It showed the real exec call round-tripping at outcome: "allowed", response_status: 200 — and also surfaced the policy-administration events:

`` policy.chain.rule.set chain: org-fallback label: "Org default · deny" → policy.chain.rule.set chain: org-fallback label: "Org default · allow" ``

The deny-by-default wall the authoring session hit and the allow-fallback my live re-run saw are the same org-fallback chain rule, set to deny then allow, each change stamped with its rule hash. For a zero-knowledge control plane, an audit log this honest about its own configuration changes is the product's core promise, demonstrated. Excellent.

The one friction, named plainly. policy denied: no policy decision is correct security behavior wearing terrible onboarding. Deny-by-default is exactly what a control plane should do. The failure is entirely first-run: the connect flow never warns you a policy is still required; the error names no console, rule, or next step; and there is no policy-write tool on the MCP surface, so the agent that hit the wall cannot climb it — a human must add a rule out-of-band (the web console). Time-to-first-successful-call dies in that gap.

What genuinely impressed — credit where due. Signal mode is real agent-native design: calling invoke with proxy_args.on_auth_required = "signal" returned HTTP 200 with a structured body (approval_required + event_id + approval_url) instead of a hard 401; a headless agent polls reauth_status(event_id), which auto-executes the original call once approved. policy_eval as a no-side-effect pre-flight (13ms, no audit record) is the kind of primitive framework authors build whole products around. State handling is clean, and the audit log is candid enough to record its own policy edits.

The honest takeaway. The engine is right and the entry is dark. Deny-by-default is correct; the onboarding that leaves a connected, scoped agent staring at no policy decision is missing. That gap is the single clearest, most demonstrable activation opportunity in the product. For a control plane, the honest field note is the trust engine.

Tools exercised live this session: services, policy_get, policy_eval, context_reflect, audit_query. reauth, reauth_status, invoke, and signal-mode approval observed in the authoring session. Product-fact gaps (OAuth-vs-scoped-injection wording; PostHog's listing status) are tracked in GAPS.md — instrument, don't invent.

The order is deliberate: prove the thing is trustworthy before asking anyone to onboard; make onboarding survivable before scaling distribution; scale distribution before trying to manufacture enterprise references or list on a marketplace. Two conventions hold throughout: the metric is named, the number is instrument (every baseline and target is measured in Phase 1 per GAPS.md G5, and any number that does appear — e.g. the 5-minute activation target — is a design goal we set, never a claimed Station70 figure); and the one north star is not restated here — each initiative's metric is an input to it.

How the seven sequence. 1 (Trust Engine) earns the right to ask anyone to try the product. 2 (Activation On-Ramp) makes trying it survivable. 3 (SDKs) and 4 (Reference Architectures) lower the cost of the second, third, and tenth governed call. 5 (Community Loop) keeps those calls recurring. 6 (Cohort) converts recurring use into the enterprise references Station70 lacks, and 7 (Ecosystem Listings) widens the top of the funnel once the funnel actually holds water. Each hands the next a precondition; none is graded on the one before it; and every one is an input to the single north star. No initiative assumes an open-source or bounty model without flagging the licensing question (GAPS.md G6).

This is the DevRel program roadmap — the release ladder the developer-relations motion itself ships against. It is not this proposal's build ladder, and not the microsite's own publication ladder (the Publication ladder below); those describe how the document gets made, while this describes how the program compounds once it is funded.

How to read this ladder. Each release carries exactly one non-vanity Primary KPI and a single numeric Exit gate. You do not begin the next release until the current gate clears: no acquisition spend before the funnel is instrumented, no scaling before the loop retains, no monetization before the loop scales. Version numbers skip on purpose — 0.1, 0.3, 0.5, 1.0, 1.3, 2.0 — a compounding cadence; a skipped number signals each cut clears a gate worth more than the last.

Every threshold below is a commitment, not a current fact. No Station70 traction figure exists in any source, so every numeric exit gate is a target to calibrate against the Phase-1 baseline the moment instrumentation goes live (GAPS.md G5 — instrument, don't invent). Where a release depends on something only Station70 controls — a paid-tier general availability (GA) date, self-serve signup going live — the ladder states the dependency as a hard gate rather than inventing a date (GAPS.md G7).

Where the two signature initiatives land. The security/audit proof series (the trust engine, Initiative 1) is placed in Fix & Activate, at v0.3 — deliberately early, because a governance product earns trust fastest by publishing reproducible proof (including its own onboarding weaknesses) before it asks anyone to scale on it. Enterprise controls (v1.3) and the managed-services upsell (v2.0) are placed last, in Monetize & Compound — after the loop demonstrably activates and retains, and only once the external GA gate clears.

⛔ v1.3 is the hard-gated late release. It cannot begin until Station70's paid-tier/self-serve GA dependency is live. Until then, v1.3's start date is instrument / to confirm with Station70, not a date we invented (GAPS.md G7); v2.0's managed-services revenue is downstream of the same dependency. Every Primary KPI is a KPI that matters — TTFV, activation, north-star WAA growth, retention, attributed pipeline, attributed revenue — never signups, connectors configured, registered agents, page views, or repository stars.

This is the measurement contract for the whole program: one north star, an anti-vanity funnel where every stage pairs a KPI that matters against the vanity metric we refuse to report, and — in the DevRel stack — the instrumentation that measures each stage. For a sales-led, security-first buyer, the fastest way to lose the room is a slide of up-and-to-the-right vanity charts.

The one north star, stated verbatim, exactly as in the cover note — and in no third location anywhere in this document:

> North star: Weekly active agents completing policy-evaluated calls through Gatekeeper — calls that pass both the org policy stack and the user policy stack and complete successfully — weighted toward approval-gated and spend-capped calls.

Read the definition literally — every clause is load-bearing: Weekly active agents, not humans and not accounts — the unit of value is an autonomous agent doing real work, counted weekly. Completing policy-evaluated calls — a call that was evaluated against policy and then ran; an attempt that never reached evaluation does not count. Pass both the org policy stack and the user policy stack — the two-stack evaluation is the product's whole thesis. And complete successfully — a permitted call that then errors downstream is not value delivered; we count the round trip, not the green light. Weighted toward approval-gated and spend-capped calls — the high-trust calls are worth more than a read; this weighting rewards the calls a buyer actually loses sleep over.

Baseline & target: instrument. No Station70 traction figure exists in any source; we never invent one. The first job of the pilot is to stand up the counter, not to promise a curve (GAPS.md G5). Why this instead of the obvious numbers. The north star is deliberately not signups (an email address is not an agent doing governed work), not connectors configured (a service can be connected and still have every call denied — we saw exactly this live: PostHog came back connected while an ordinary invoke was refused — connected ≠ allowed), and not followers, stars, or page views (attention, not adoption). It sits deep in the funnel on purpose: it is the one number that can only move if the product actually works for a developer end to end.

The through-line. The left column of the funnel below gets harder as you go down; the right column gets easier. A program optimizing for the right column looks great on a dashboard and sells nothing. This proposal is accountable to the left column, and the deepest row on the left is the north star.

Each funnel stage is measured by exactly one instrument, so no number is double-counted and every stage has a named owner-of-record. The two stages closest to the north star are measured by Gatekeeper's own audit trail — no marketing tool can see a policy-evaluated call, and that is the honest tell: the number that matters most is a product-telemetry number, not a growth-hack number.

audit_query is a live Gatekeeper MCP tool exercised in the field notes. Sapient, Reo.dev, Beehiiv, and Luma are the reusable instrumentation stack carried from the basis proposals; their Station70 account setup and baselines are instrument, not assumed (GAPS.md G5).

A SWOT is only worth reading if the weaknesses are real. A security buyer trusts the vendor who names the seam first. This is the honest read, scored against the competitive set the brief names — raw per-service OAuth, an Arcade/Composio-style tool gateway, MCP gateway / secrets-broker vendors, and DIY in-house policy engines. The strength axis throughout is the one Station70 can prove and the convenience-first alternatives cannot: zero-knowledge (ZK) custody, an independent Trail of Bits cryptography audit, SOC 2 Type 2, and a web3-custody heritage that has protected billions in digital assets. Station70 itself has since declared a fifth frame: the new Gatekeeper page positions against password managers and enterprise privileged-access management (PAM) — "built for AI, not retrofitted from humans" — which corroborates the category-level approach here without naming vendors. Beyond that declared frame the competitive set is not in any research source, so every specific claim about a named competitor's current feature set is flagged GAP (G9) — to verify before it reaches a buyer.

Battlecards — four cards, one per competitor, each with the competitor's pitch, where they are genuinely strong, our counter, the honest when we win / when we lose, and the proof to bring. Vendor-specific claims flagged GAP (G9).

1 · vs. Raw per-service OAuth. Their pitch: "It's free, standard, already there — just grant the agent a token per service." Strong when: one service, one agent, one trusted operator, no compliance surface. Our counter: OAuth scopes are coarse and granted once at connect time; the agent holds the raw secret; there is no request-time policy, human step-up, or spend cap, and the audit trail is scattered. When we win: the moment there is more than one agent, more than one service, or any auditor. When we lose: single-service, single-developer, zero-compliance setups. Proof to bring: the live dogfood — a connected, broadly-scoped service still returning policy denied: no policy decision.

2 · vs. Arcade/Composio-style tool gateways. Their pitch: "One integration, hundreds of tools, great DX — connect once and your agent can call everything." Strong when: breadth and speed-to-first-call are the goal (their connector catalog, docs, and self-serve onboarding are real advantages Gatekeeper does not have yet — W1/W3 stated honestly). Our counter: convenience-first gateways optimize for access; Gatekeeper optimizes for governed access — the ZK vault, deny-by-default depth across 12 dimensions, built-in quorum / four-eyes approval, and the Trail of Bits / SOC 2 stack (GAP G9: verify any named gateway's policy/approval depth). When we win: regulated, high-blast-radius, or write-heavy workloads. When we lose: a fast-moving team that wants many connectors and a five-minute quickstart today. Proof to bring: signal mode's agent-native approval flow.

3 · vs. MCP-gateway / secrets-broker vendors. Their pitch: "We already sit in the path and hand your agent the credential it needs." Strong when: the requirement is secure credential delivery and routing. Our counter: a broker answers "can the agent get the secret?"; Gatekeeper answers "should this specific call happen — now, by this identity, on this resource, within this spend cap, or does it need a human?" That is policy engine + approval + audit on top of ZK injection (GAP G9). When we win: when the buyer needs decisioning and provability, not just delivery. When we lose: when the requirement genuinely is only secret storage and rotation. Proof to bring: policy_eval — a real decision layer, not just a delivery layer.

4 · vs. DIY in-house policy engines. Their pitch: "We don't put a third party in our critical path" (Threat T3 made concrete). Strong when: the team has real security engineering capacity and an institutional refusal to route credentials through any vendor. Our counter: DIY means you own correctness, coverage, rotation, revocation, the approval UX, and the audit pipeline — forever — and must prove all of it to your own auditors; Gatekeeper is the same seam, already audited by Trail of Bits, SOC 2 Type 2, and hardware-attested, including the ZK property that Station70 cannot read the secret. When we win: when the true cost of building and certifying a policy-plus-custody plane is priced honestly — including on-prem in the customer's own VPC or a managed dedicated instance. When we lose: a team with the depth and mandate to build it, for whom no external control plane will ever clear the "not in our critical path" bar. Proof to bring: the reproducible scope-breakout demo.

GAP flags on this section: the competitive set is unverified beyond Station70's own declared frame of password managers and enterprise PAM (G9); "OAuth" is used only for the alternative in Battlecard 1, never as Gatekeeper's own public term (G1); the live dogfood round-tripped a real query through PostHog but the marketing site does not list it (G2); and neither the Gatekeeper page's own trusted-by wall nor the company-wide customer list may be presented as Gatekeeper proof until Station70 attributes it and grants permission (G3).

DevRel is usually pitched as a top-of-funnel awareness play. For Gatekeeper it is the opposite: a proof factory that manufactures, on a schedule, the three things Station70's sales-led motion is missing today — a technical champion inside the account, a Gatekeeper-specific reference the deck can name, and attributable pipeline the team can trace to a channel instead of a guess. The developer motion does not replace the enterprise sale. It feeds it.

The objection, said out loud (G8): Does a sales-led, security-first, web3-heritage buyer even want a bottoms-up developer motion? Three reasons the developer motion fits this buyer specifically — not despite the sales-led, web3 heritage, but because of it: (1) The person who adopts an agent control plane is a developer — even in an enterprise. A platform or AI-engineering team wires Gatekeeper in before Procurement sees a quote; bottoms-up DevRel is how that technical champion gets created and equipped. (2) The web3 heritage is an asset, not a mismatch. Crypto-custody is one of the most developer-dense, proof-obsessed buyer cultures in software — "don't trust, verify" — and a program whose Initiative 1 is a reproducible security proof harness speaks that culture's native language. (3) It feeds the funnel it does not replace. Every artifact resolves into an input the existing sales-led motion consumes: a proof that pre-clears a security review, a reference that fills the case-study gap, a product-qualified lead with a live governed call already made. G8 stays a live discovery-call question.

Design-partner cohorts manufacture references on a schedule. Station70 has no Gatekeeper-specific case studies today — the new Gatekeeper page carries a trusted-by logo wall, but none of it is an attributable Gatekeeper story (G3). A 12-week cohort of 8–10 companies gets white-glove integration and office-hours access, and in exchange each partner commits — up front, in writing — to a case study, a quotable result, and a public Demo Day. The metric is deliberately publishable references with named permission, never "applications received" or borrowed company-wide logos.

The proof series feeds the enterprise sales funnel. In an enterprise governance deal, the longest pole is the security review. The Trust Engine proof series (Initiative 1) is built to pre-clear exactly that review: a public, re-runnable harness told entirely in real Gatekeeper MCP tool calls and their actual outputs, so a skeptical security engineer can reproduce the enforcement rather than trust a screenshot. The review that used to begin at zero now begins at "we already reproduced the scope-breakout denial ourselves."

Managed services turns DevRel into attributable pipeline. The managed-services tier (priced in the engagement) is a line item with a dollar figure attached: a first-integration engagement plus an ongoing retainer, in which the DevRel-created relationship converts directly into billable revenue. It is attributable because each engagement is sourced from a specific developer relationship the program can name. This is the v2.0 "Monetize & Compound" arc, hard-gated on Station70's paid-tier GA dependency (G7).

Owned distribution → attributed acquisition via UTMs. The reason this program can promise attributed pipeline is a day-one owned channel: dabl.club, ~85,000 developers. Every link into a Gatekeeper on-ramp carries a UTM, tracing a click end to end: dabl.club UTM-tagged click → account resolved (Reo.dev) → first policy-evaluated call (Gatekeeper's own audit_query trail) → sales opportunity. Privacy discipline holds: UTMs tag the channel and campaign, never personal data in the URL. Attribution we cannot prove is not attribution; it is a vanity metric wearing a suit. Every outcome number is instrument — measured once the program is live.

Two framings of the same operator, so Station70 picks the container rather than the scope: a low-commitment fractional pilot priced by the hour (the front door, and the recommended CTA), and a three-door founding-hire path for standing the full DevRel function up around it. Every price here is Colin's own offer, not a Station70 fact — no gap flags needed on these numbers.

Frame 1 · The fractional pilot — one operator owning Activation end to end and assisting on Awareness. Flat $150 per hour across every tier; the tier only changes how many hours and for how long. Start with the $6K pilot — deliberately the smallest real thing: enough to stand up the counter and produce a defensible activation baseline, cheap enough that it never needs a committee. Everything above it is a renewal decision made after the number exists.

Frame 2 · The founding-hire path — three doors into the same work; the substance is identical behind each. Recommended: B → A. A 90-day paid pilot that converts to a founding hire is the two-way door — it de-risks the single most expensive, hardest-to-reverse decision (a founding DevRel hire) by letting the Phase-1 funnel decide the conversion. The $6K pilot and the $155K 90-day pilot are not competing offers; they are the same staircase at two different heights.

The resource model. The three-door prices cover Colin's fee only. Standing up the entire DevRel program — team plus program budget — is a separate number, stated two ways: the full-fat build (≈ $1.6M) and a deliberately cheaper startup-friendly ramp (≈ $900K–1.0M) that scales the spend into the traction. Both are real offers, not an anchor-and-discount trick.

The managed-services upsell turns the DevRel line item from a cost center into attributable revenue — the same reference-architecture and integration work that activates developers, sold as a managed governance-integration service to enterprise accounts already in Station70's funnel. It is an upsell option, not part of the pilot.

There is exactly one thing to decide, and it is deliberately the smallest real one.

> Scope the pilot. A one-month, $6,000 fractional engagement — the Pilot tier — that stands up the activation instrument, ships the flagship "connect your first downstream service through Gatekeeper in 5 minutes" quickstart, and reports one honest activation number.

That is the whole request. Not a founding-hire commitment, not a program budget, not a year. A single month, priced small enough to approve without a committee, self-terminating on a measured baseline. Everything larger — the three-door B → A founding-hire path, the full build, the managed-services upsell — is a renewal decision made after the number exists. The first move toward it is one 30-minute call to agree the single activation number the pilot will report and the on-ramp it will instrument. There is no competing secondary CTA here on purpose. The proposal asks for one yes, to one small, reversible thing.

Why Colin — the two assets that de-risk this specific engagement. A day-one owned distribution channel: dabl.club is ~85,000 developers Colin already operates — earned reach, not a rented list, the reason this program can promise attributed pipeline (every link carries a UTM that resolves end to end to a first policy-evaluated call). A repeatable DevRel operating system, already run: this is the same playbook Colin has authored for prior programs (Tenki, AISA, Nebius, Coral) and shipped for CrewAI, Memori, Glean, and Perplexity — the deliverable format itself (a canonical strategy document plus a deployable microsite, not a slide PDF) is the product, refined across those engagements. And the field notes are proof-of-work, not promises: a real dogfood of the live Gatekeeper MCP tools that hit an actual policy denial and reauth-scope friction.

Conflict disclosure. Stated up front, per the honesty discipline: Colin operates dabl.club and has run or authored DevRel programs for other companies. None conflicts with a Gatekeeper engagement, and any live competing engagement is disclosed before it starts — never discovered mid-contract. Fee and program budget are always quoted as separate lines, so there is no hidden markup and no divided loyalty to find later.

This proposal is outside-in v1: every Station70 fact cites docs/research/, and every unknown — leadership titles, the exact DevRel role, funding and traction baselines, the competitive set, OSS/licensing posture, the paid-product GA date, and the appetite for a bottoms-up motion — is tracked in docs/proposal/GAPS.md, marked instrument or to-confirm, never invented.*