ARCHIVED SOURCE · SCRIPTS AND NETWORK DISABLED
Doc RLY-HB-1842 / Handbook / Operations copy
Issued 14 Aug 2026 / Supersedes issue 06
Station OPS-2 / Shift B
Relay
Deployment and operations platform for AI agents

AI Deployment Handbook

Software operations documented with the discipline of a technical field manual. This copy records the production deployment of agent Research-04, build RLY-1842, revision 07.

Rev 07 State verified
Deployed 14:32
Page ops / 01–08
01
01.0 / Record
01.0 / Identity

Deployment Record

The active production record for this issue. Values below describe the agent presently under operational control, not a summary of fleet health.

Unit record / Research-04 Sheet 01-A
Agent Research-04 Unit id
Build RLY-1842 See 03.1
Environment Production IAD-03
State Verified Marked
Deployed 14:32 14 Aug 2026
Rev 07 Current

Cross-ref / Procedure 02 / Specification 03 / Change 05 / Note A 06

This record is the heading of the working copy. Subsequent sections explain how the deployment was performed, what configuration it carries, which other agents share the environment, and what changed between revisions 05 and 07. Do not treat the verified mark as a substitute for the evaluation gate in stage 03 of the procedure.

02
02.0 / Procedure
02.0 / Sequence

Deployment Procedure

Complete stages in order. Each completed stage receives a recorded state and a timestamp. The current stage is marked Current. Do not skip a stage to reach Deploy.

Figure 01 — Deployment flow Seven numbered stages in a single horizontal procedure: validate configuration, resolve tools, run evaluation, verify permissions, deploy, observe, and sign off. 01 02 03 04 05 06 07 Validate Resolve Evaluate Permissions Deploy Observe Sign off CALL 01 CONFIG CALL 02 TOOLS CALL 04 SCOPE — see Note A before 05 CALL 07 RECORD
Fig. 01 — Deployment flow View / procedure axis
  • 01 Validate configuration against the specification sheet.
  • 02 Resolve registered tools and connector health.
  • 03 Run evaluation. Production requires a pass.
  • 04 Verify permission scope before execution.
  • 05 Deploy the signed build to the target environment.
  • 06 Observe live behavior against expected bounds.
  • 07 Sign off. The record becomes revision history.
Caution / 02.4

Production agents require evaluation approval before deployment. Do not advance stage 05 until stage 03 is recorded complete and the evaluation threshold in specification 03.2 is satisfied. See Note A.

  1. 01
    Validate Config
    Confirm the intended build against the specification sheet before any tool is resolved.
    1. 01.1 Confirm model identifier matches RLY-REASONING-7.
    2. 01.2 Confirm context window, timeout, and region pairing.
    3. 01.3 Confirm environment is Production and not a leftover staging bind.
    Current
  2. 02
    Resolve Tools
    Register connectors required by Research-04. Unresolved tools block evaluation.
    1. 02.1 Load the tool manifest attached to build RLY-1842.
    2. 02.2 Confirm each connector answers a health check.
    3. 02.3 Record missing scopes for stage 04 rather than ignoring them.
  3. 03
    Run Evaluation
    Execute the evaluation suite against the production threshold. A failed evaluation is a stop, not a warning.
    1. 03.1 Run suite RLY-EVAL-07 against the resolved tool set.
    2. 03.2 Compare results to threshold 0.92 / rev 06.
    3. 03.3 If the suite does not pass, do not continue. See 07.
  4. 04
    Verify Permissions
    Confirm the permission scope granted in revision 05 is complete for every resolved tool.
    1. 04.1 Inspect the permission plate for each connector.
    2. 04.2 Confirm write paths are limited to the production corpus.
    3. 04.3 Confirm no staging credential remains bound.
  5. 05
    Deploy
    Promote build RLY-1842 to Production. The deploy command is recorded; it is not implied by a green indicator.
    1. 05.1 Issue deploy against environment Production / IAD-03.
    2. 05.2 Confirm the running build identifier returns RLY-1842.
    3. 05.3 Record the deploy timestamp on sheet 01-A.
  6. 06
    Observe
    Watch the first operating interval. Observation is a recorded activity, not a dashboard glance.
    1. 06.1 Confirm task throughput remains inside expected bounds.
    2. 06.2 Confirm no permission denial appears in the execution log.
    3. 06.3 Confirm memory write is session-bound as specified.
  7. 07
    Sign Off
    Close the procedure. Sign-off writes revision 07 into the change record and marks the unit Verified.
    1. 07.1 Enter operator identity and station.
    2. 07.2 Confirm the change record lists this deployment.
    3. 07.3 Release the working copy as issue 07.

Sequence state / Stage 01 current / No completion stamps

03
03.0 / Spec
03.0 / Sheet

System Specification

Nominal configuration for Research-04 as deployed in revision 07. This is a specification sheet. It is not a set of metric cards.

03.1 / Runtime identity
Parameter Nominal Note
Model RLY-Reasoning-7 Build RLY-1842
Context 128000 Tokens
Tools 11 registered Manifest 07
Memory Session + long-term store Bound
Timeout 240 Seconds
Region IAD-03 Production
Version 2.7.14 Relay core
03.2 / Evaluation and control
Parameter Nominal Note
Eval threshold 0.92 Rev 06
Eval suite RLY-EVAL-07 Required
Eval gate Required for production See Note A
Tool permissions Restricted write / corpus A Rev 05
Max concurrency 4 Sessions
Retry policy 3 / exponential backoff See 07
03.3 / Retention and observation
Parameter Nominal Note
Log retention 90 Days
Trace sample 1.0 production Full
Observe window 15 Minutes min.
Operator station OPS-2 Shift B
Rollback build RLY-1838 Rev 06

Changed values retain revision notation. Threshold 0.92 and permission scope are the two outstanding marks from issues 06 and 05.

04
04.0 / Records
04.0 / Fleet sheet

Agent Records

Agents sharing the Relay control plane. Research-04 is the subject of this issue. Other rows are adjacent operating records, not decorative status tiles.

Agent Rev Task Env State Updated
Research-04 07 Literature synthesis Production Verified 14:32
Support-12 04 Ticket classification Staging Active 13:18
Intake-03 11 Document extraction Production Verified 12:04
Review-08 02 Policy compliance Production Hold 11:47
Dispatch-01 09 Routing and handoff Production Verified 10:22
Ledger-06 05 Cost attribution Staging Eval 09:55
Archive-02 03 Retention sweep Production Inactive 08:14
Watch-15 01 Anomaly notice Production Current 14:28

Review-08 remains on hold pending evaluation approval. Ledger-06 is in evaluation on staging and must not be promoted against this procedure. Watch-15 is under observation only.

05
05.0 / Change
05.0 / History

Change Record

Revision history is a first-class record. Issue 07 is the production deployment verified at 14:32. Prior revisions remain in force as the explanation of how the current configuration was reached.

Rev Date Section Description
01 02.18.26 03.1 Initial issue. Research-04 entered as a staging agent under build RLY-1801.
02 04.07.26 03.3 Observation window set to 15 minutes. Log retention set to 90 days.
03 05.22.26 02.0 Deployment procedure expanded from five stages to seven. Sign-off added as a recorded stage.
04 06.30.26 03.1 Model updated to RLY-Reasoning-7. Context raised to 128000 tokens.
05 07.28.26 03.2 Tool permissions changed. Write paths restricted to corpus A. Staging credentials unbound.
06 08.09.26 03.2 Evaluation threshold updated from 0.88 to 0.92. Suite designation became RLY-EVAL-07.
07 08.14.26 01.0 Production deployment verified. Build RLY-1842 marked Verified at 14:32, station OPS-2.

Rev 05 tool permissions changed. Rev 06 evaluation threshold updated. Rev 07 production deployment verified.

06
06.0 / Note
06.0 / Margin

Annotation

Operational notes are attached to the procedure, not floated as tips. Open the note from the reference in the body. The leader and the right-hand sheet belong to the same mark.

Stage 05 of the deployment procedure is gated. The operator advancing a production agent must be able to point to a completed evaluation, not to a personal judgment that the configuration “looks right.” The rule is written once and referenced wherever Deploy appears.

Trigger is keyboard reachable. Revealed note appears in the annotation margin with a revision-colored rule. Relationship is leader plus sheet, not a tooltip bubble.

When the note is closed, the margin holds the identifier only. When it is open, the full instruction occupies the annotation column and remains visible while the operator continues through the procedure. Closing the note does not clear any completion stamps recorded in section 02.

07
07.0 / Fault
07.0 / Diagnostic

Failure Procedure

Use this sheet when a tool cannot execute after configuration appears valid. Mark each diagnostic step complete. The fault is not cleared until validation is rerun.

Symptom
Tool execution unavailable.
Possible cause
Permission scope incomplete.
Related rev
05 — tool permissions changed. Confirm the restricted write path was applied to every connector, not only the primary corpus tool.
Stop condition
If inspection shows a missing connector rather than a missing scope, halt this sheet and return to stage 02 of the deployment procedure.
Figure 02 — Diagnostic path Three diagnostic stages in sequence: inspect configuration, verify connector, rerun validation. A branch returns to deployment procedure stage 02 if the connector is absent. 01 02 03 Inspect config Verify connector Rerun validation IF CONNECTOR ABSENT → RETURN 02.0
Fig. 02 — Diagnostic path View / fault axis
  1. 01
    Inspect Configuration
    Open the permission plate for the failing tool. Compare the granted scope with revision 05.
    1. 01.1 Confirm the tool is listed in the build manifest.
    2. 01.2 Confirm the environment bind is Production / IAD-03.
    3. 01.3 Confirm the write path names corpus A and no other store.
    Current
  2. 02
    Verify Connector
    Prove the connector is present and answering. A missing connector is a different fault from an incomplete scope.
    1. 02.1 Issue a connector health check from station OPS-2.
    2. 02.2 If the connector does not answer, return to procedure 02.0 stage 02.
    3. 02.3 If the connector answers and still cannot execute, continue.
  3. 03
    Rerun Validation
    After scope is corrected, validation must be run again. Do not return directly to Deploy.
    1. 03.1 Return to deployment procedure stage 01 and re-validate config.
    2. 03.2 Re-resolve tools. A corrected scope can change the manifest.
    3. 03.3 Re-run evaluation if any permission change was written.

Diagnostic state / Step 01 current / No completion stamps

08
08.0 / Product
08.0 / Explanation

Product Explanation

Relay is a deployment and operations platform for AI agents. It exists for teams who need to put an agent into a real environment, keep a record of what was deployed, and still be able to say, weeks later, why a permission looks the way it does. The product is not a chat window and it is not a dashboard of glowing services. It is the working copy used to inspect, perform, verify, and diagnose agent operations.

An agent in Relay is treated as a unit under procedure. It has an identity, a build, an environment, a revision, and a state that can be marked. Those five facts are enough to locate the unit in the fleet and enough to stop a careless promotion. Everything else in the handbook — the specification sheet, the evaluation gate, the change record, the failure path — exists to keep those facts honest.

08.1 What Relay records

Relay records configuration as a specification, not as a collection of tiles. Model, context window, registered tools, memory binding, timeout, region, and version are written so an operator can read them in one pass and compare them to the running unit. When a value changes, it keeps a revision mark until the next issue absorbs it. The point is not to decorate change. The point is to make change inspectable.

Relay also records work as a sequence. Validate, resolve, evaluate, verify permissions, deploy, observe, and sign off are stages with names, because skipping any one of them produces a different kind of failure than the others. Evaluation is the hard gate for production. A unit that has not passed the current threshold does not become a production agent by accumulating other green marks.

08.2 Who uses this handbook

This copy is written for the operator at a station, the reviewer who must approve a production promotion, and the person who arrives after a fault and needs a procedure rather than a narrative. It assumes the reader can follow numbered steps, compare a live value to a sheet, and write a timestamp when a stage is finished. It does not assume the reader wants to be entertained by the interface.

Research-04, the subject of issue 07, is a literature-synthesis agent. It reads from corpus A, writes session memory, and must not retain working notes beyond the bound store. The same handbook structure is used for intake, review, dispatch, and ledger agents. The tasks differ. The discipline does not.

08.3 How to read a deployment

Start at the deployment record. Confirm the agent, build, environment, state, time, and revision. Move to the procedure only after those six fields match the unit you intend to touch. Use the specification sheet as the authority for runtime values. Use the agent table to see neighbors that might share a connector or a permission plate. Use the change record to understand why the current issue looks the way it does. If a tool cannot execute, do not invent a repair. Open the failure procedure and mark the diagnostic steps as you complete them.

Annotation is part of the document, not a hint layered on top of it. Note A is the production rule: evaluation approval is required before deployment. The caution in the procedure restates that rule at the point of action. If those two references ever disagree, stop and correct the handbook before correcting the agent.

08.4 What Relay is not

Relay is not a terminal costume, a command-center mural, or a generic product site with feature columns. It does not replace operational judgment with a single health score. It does not hide state in color. If a stage is current, it is labeled current. If a stage is complete, it is labeled complete and given a time. If a value changed, it carries a revision. The software is the procedure made durable enough to share a shift.

Issue 07 closes the production deployment of Research-04. The next issue will open when the specification changes, when a fault forces a procedure revision, or when another agent is promoted under the same gate. Until then this copy remains the operating record.

End of handbook body / Return 01.0 for the unit record / Return 02.0 to repeat the sequence