Fourth Down Labs is not an autonomous publisher. It is a bounded research-automation system that can acquire registered data, run deterministic statistics, invoke five GLM-5.3 specialists, enforce a publication gate, and open a review pull request. Then it stops.
That last sentence matters more than the word “agentic.” Autonomy is not a personality a system acquires when its prompts sound ambitious. It is a set of permissions over specific actions: choose, download, calculate, judge, write, push, merge, publish, charge, message, correct, and roll back.
Describe the most consequential action the system can take without another authority—not the most impressive task it can complete inside a sandbox.
Our five-level authority scale
Human only / disabled
The system has no implemented authority to perform this decision or public action.
Decision support
Code can list, validate, or execute a consequence only after a separate human-controlled decision.
Bounded automatic execution
The system can complete a preregistered internal task inside fixed inputs, outputs, permissions, and failure rules.
Supervised external change
The system can create a reversible, reviewable external artifact such as a branch or pull request, but cannot make it public.
Unsupervised public authority
The system can publish, charge, message, merge, or otherwise affect readers without a prior human-controlled checkpoint.
The scale is not a maturity ladder where Level 4 is automatically better. For reversible internal work, bounded automation can be valuable. For public claims, billing, reader messages, or corrections, a lower permanent level can be the responsible architecture.
Fourteen stages, zero autonomous public actions
Our generated scorecard assigns all 14 implemented stages: 3 are human-only or disabled, 4 provide decision support or run after approval, 6 execute automatically inside fixed boundaries, 1 can create a supervised external change, and 0 possess unsupervised public authority.
L0 · topic and registration authoring
Humans add series, hypotheses, estimands, risks, cadence labels, sources, and access class to versioned files. Boundary: GLM-5.3 cannot create or rewrite the locked registration inside a run.
L1 · phase and priority planning
The plan command lists active series for the inferred season phase, sorted by priority. Boundary: The printed list does not start a run, enforce cadence against run history, or control the monthly workflow.
L1 · scheduled series selection
The monthly schedule defaults to Touchdown Regression; manual dispatch can choose one of two implemented series. Boundary: This is not registry-driven topic selection. Cadence labels are descriptive, not an executable due-state ledger.
L2 · scheduled run trigger
GitHub Actions starts the configured research job monthly or on manual dispatch. Boundary: One concurrency group, a 30-minute timeout, and a fixed two-series dispatch surface bound the run.
L2 · data acquisition
The selected pipeline downloads registered public assets, hashes them, and writes provenance. Boundary: Only implemented analyzers and code-authored source contracts run; planned series raise an error.
L2 · statistical analysis
Code builds cohorts, fits registered models, computes uncertainty, and renders artifacts with fixed seeds. Boundary: GLM-5.3 does not execute the official calculation or overwrite analysis artifacts.
L2 · specialist review
Five GLM-5.3 roles return schema-constrained judgments over frozen evidence. Boundary: No tools are supplied. Roles share one model family, operate sequentially, and cannot mutate registration, calculations, or public state.
L2 · publication gate
Code combines every mechanical check, five role decisions, and blocking findings into one decision artifact. Boundary: Any failed check or non-pass role stops the run; GLM-5.3 cannot waive code-owned checks.
L2 · branch local promotion
A passing online run is hash-verified and promoted into site content inside the workflow checkout. Boundary: Promotion changes only the temporary branch workspace until later Git operations succeed.
L3 · review branch and pull request
The workflow can create a branch, push research artifacts, and open a reviewable pull request. Boundary: The implemented workflow does not merge the pull request or push to main.
L0 · main branch merge and public release
A human-controlled merge is required before research content reaches main and becomes eligible for deployment. Boundary: The repository workflow contains no merge command. Branch-protection enforcement is external state and is not proven by this contract.
L1 · production deployment
Render has been observed building main revisions after they are pushed or merged. Boundary: Render configuration is external to this repository; the build can verify runtime shape, not the provider trigger policy.
L1 · monitoring and corrections
Public ledgers and deterministic checks preserve incidents, holds, and corrections when an operator runs the release audit. Boundary: There is no verified always-on uptime alert, automatic correction author, or autonomous rollback loop.
L0 · monetization
No Stripe checkout, premium entitlement, or display-ad execution is enabled. Boundary: Stripe remains 0/4; ads remain 1/3.
What the monthly schedule actually chooses
The repository contains a phase-and-priority planner. In preseason it can list registered series in priority order. That output looks like an autonomous queue, but the monthly workflow does not consume it. The schedule currently defaults to touchdown-regression. A manual dispatch can choose Touchdown Regression or Rookie WR Hit Rates.
Cadence values such as annual-preseason and weekly-tuesday are descriptive strings today. There is no persisted last-success ledger, no open-pull-request suppression, and no executable due-date calculation. Saying “the orchestrator automatically chooses what is due” would therefore be false.
The honest classification is Level 1 series selection plus a Level 2 scheduled trigger: a fixed monthly job automatically runs one bounded choice. Registry-driven cadence can become Level 2 only after due-state, duplicate suppression, planned-analyzer exclusion, and time-boundary tests exist.
The scheduled desk now fails closed on GLM-5.3
The authority audit found another mismatch. The workflow used to fall back to deterministic offline checklists when the OpenRouter key was missing. The later promotion gate requires recorded online specialist models, so that fallback could consume the entire analysis budget only to fail during promotion.
We removed the fallback. The scheduled research desk now verifies that its OpenRouter credential exists and then invokes all five roles online. If the key is absent, the job stops before acquisition and analysis. Offline mode remains available for local reproduction and CI; it is no longer a silent substitute inside the workflow labeled as the GLM-5.3 research desk.
GLM-5.3 is Level 2 by design
GLM-5.3 receives a frozen evidence bundle and returns one schema-constrained review artifact per role. It has no tool definitions. It cannot browse, execute code, rewrite the registration, change official numbers, push a branch, merge, deploy, bill, place an ad, or send a reader message.
That does not make the model ornamental. The specialist decisions can stop a run. A statistician can identify leakage the mechanical checks missed. An adversarial reviewer can expose an overclaim. A citation checker can block an unsupported central number. The editor can require revision. This is real judgment with deliberately narrow authority.
Five roles, frozen evidence, strict schemas, no tools, no public mutation.
Acquisition, statistics, artifacts, gates, hashes, and branch-local promotion.
Create a branch, push that branch, and open a pull request for review.
Approve the registration, evaluate warnings, merge, and own corrections.
A pull request is the highest automatic boundary
The research workflow has repository-content and pull-request write permissions. After a passing gate and branch-local promotion, it can create a research branch, push the artifacts, and open a pull request. That is Level 3 because it changes external state—but the change is named, reversible, and reviewable.
The implemented workflow contains no merge command and no direct push to main. Its pull-request body instructs an editor to inspect warnings, visible claims, and data rights. We have not frozen branch-protection configuration into this evidence contract, so we do not claim the human checkpoint is cryptographically enforced by repository policy. We claim the narrower fact the code proves: this workflow stops at a pull request.
Render automates after a human-controlled change
Render has repeatedly been observed building new main-branch revisions. That is useful post-approval automation, not autonomous editorial authority. The provider trigger is external configuration, and our repository verifies the runtime shape rather than pretending it can prove every Render setting.
The scorecard failed its first isolated build
The first Render build for this article failed before deployment. The generated autonomy verifier reads the scheduled workflow under .github/workflows, but our Docker ignore file excluded the entire .github directory. The local build saw the workflow. Render's isolated Docker context did not, so verification stopped with a missing-file error.
The failed revision never reached production, and the previous healthy revision remained live. We repaired the evidence boundary by including .github in the builder context. The final runtime image still receives only compiled application output and runtime dependencies. An actual Docker image build now joins the local framework build as release evidence.
A generated evidence contract is only portable when every authoritative source it reads is present in every build context that verifies it.
Monitoring is also Level 1. We preserve incidents and run deterministic health audits, but there is no verified always-on uptime probe, autonomous rollback loop, or correction-writing agent. The system cannot notice its own public error, author a correction, and republish without an operator.
Why Level 4 is not the destination
We want more autonomy where it compounds research value: detecting due work, refreshing data, recomputing models, comparing frozen evaluations, and surfacing candidate topics. We do not currently want an unsupervised agent publishing claims, charging readers, changing entitlements, placing ads, or rewriting corrections.
The value-first rule applies to permission as well as revenue. More autonomy must earn its evidence before it earns authority. The next upgrades are executable cadence, non-executable GLM-5.3 topic proposals, independent uptime alerts, and stronger release-control evidence—not a dramatic “fully autonomous” badge.
Revenue remains outside the loop
Stripe is still 0/4 ready and display advertising is 1/3 ready. Neither has execution code. GLM-5.3 cannot change those gates, and the research workflow cannot enable a commercial feature. Audience pull, premium product depth, commercial data rights, support operations, and reader-safe ad performance still have to exist first.
This scorecard is a deterministic reading of committed code, workflows, public contracts, and preserved operational evidence. It did not invoke GLM-5.3 or send unpublished research to OpenRouter.