A Standard for the Training and Inference of Machine Learning Models via Avian Parameter Carriers

3.1. Training Loop

The standard APC training loop proceeds as follows:¶

1. Initialize model weights. Print on acid-free paper.¶
2. Divide Parameter Scrolls across available Carriers. Assignment SHOULD be random to prevent positional bias. Carriers MUST NOT be allowed to self-select scrolls based on weight, as this introduces selection bias.¶
3. Dispatch Carriers to remote training node.¶
4. Wait. MAY occupy time by checking GPU availability on alternate infrastructure or reviewing current cloud billing status. The authors note that completing either task typically motivates continued investment in APC.¶
5. Upon return, aggregate received parameters. Carriers that do not return SHOULD be treated as dropped gradients. Apply gradient clipping accordingly.¶
6. Compute loss. Record on the Loss Log (see Section 3.3). Repeat from (b).¶

Each complete loop constitutes one training epoch. Epoch duration is a function of flight distance, headwind, and carrier motivation, the last of which is not currently formalizable.¶

3.2. Batch Size and Payload Constraints

Batch size is physically constrained by Flock size. Larger batches require proportionally more Carriers. The authors observe that very large batch training (batch size > 512) presents significant loft management challenges and is RECOMMENDED only for well-funded institutions.¶

Mini-batch gradient descent is the preferred approach. Stochastic single-sample updates via individual Carrier are theoretically supported but result in training instability proportional to wind conditions.¶

Payload capacity MUST be considered when selecting storage media for Parameter Scroll transport. A standard M.2 NVMe drive weighs approximately 7-10 grams. A homing pigeon's maximum comfortable payload is approximately 75 grams, yielding a theoretical maximum of seven drives per Carrier. Practitioners SHOULD target a conservative 50% utilization to preserve aerodynamic performance and Carrier morale.¶

For model shards exceeding single-Carrier payload capacity, implementors MAY employ a RAID-0 Dove Configuration (RDC), in which a Parameter Scroll is striped across multiple Carriers dispatched simultaneously. Reconstruction at the receiving node requires all shards to arrive.¶

The fault tolerance of a RAID-0 Dove Configuration is zero. The authors wish to be unambiguous on this point. If one Carrier in an RDC does not return, the entire shard set MUST be discarded and the epoch repeated. Practitioners considering RDC for production workloads SHOULD reflect carefully on this property and then consider logistic regression instead.¶

3.3. Loss Monitoring and the Loss Log

Conventional ML infrastructure provides continuous, real-time loss curves updated at each training step. APC implementations do not support this.¶

Loss MUST be computed at the central loft upon gradient aggregation and recorded manually in the Loss Log (LL), a physical ledger maintained by the loft operator. The Loss Log SHOULD include:¶

1. Epoch number.¶
2. Number of Carriers dispatched.¶
3. Number of Carriers returned.¶
4. Computed training loss.¶
5. Computed validation loss, if a validation Flock was dispatched.¶
6. Weather conditions at time of dispatch.¶
7. Smart Leg Band telemetry summary, if Appendix A hardware is deployed.¶
8. Any anomalous Carrier behavior observed during the epoch, including but not limited to: prolonged absence, return without scroll, return with incorrect scroll, or return with scroll in a condition suggesting the Carrier sat on it.¶

Loss curves SHOULD be plotted by hand on graph paper. Automated plotting via the Loft Telemetry Dashboard is available to implementors who have deployed the hardware described in Appendix A.¶

A flat or increasing loss over consecutive epochs indicates the model is not converging. Practitioners SHOULD verify the following before concluding the architecture is at fault:¶

1. Scrolls are being attached prior to dispatch, not after.¶
2. Gradient direction is correctly indicated (descent, not ascent). The scroll orientation MUST be verified. The authors note this failure mode has occurred.¶
3. The validation Flock is distinct from the training Flock. Using the same Carriers for both constitutes data leakage and will produce artificially optimistic validation loss. This is not the Carriers' fault.¶

NaN loss values indicate a numerical instability in the gradient computation, or that the scroll was exposed to rain en route and is no longer legible. The two cases are distinguished by examining the scroll. If the scroll is damp, the loss is indeterminate. Discard the epoch. Allow Carrier to dry before reuse. Smart Leg Band-equipped deployments receive automated moisture alerts prior to Carrier return (see Appendix A, Appendix "Overview"), which is considered a significant operational improvement.¶

4.1. Variance

High variance in model performance will manifest as high variance in carrier return times. A model that has overfit to training conditions will show strong performance in fair weather and catastrophic degradation when a neighboring loft releases recreational pigeons. Practitioners SHOULD regularize accordingly.¶

4.2. Explainability

A principal advantage of APC over conventional black-box training infrastructure is full operational explainability. When a parameter update fails to arrive, the cause is observable:¶

1. Carrier encountered adverse meteorological conditions.¶
2. Carrier was distracted by a local flock (see [BERGEN2001]).¶
3. Cage was left open at the dispatch node. This is a human error and MUST be logged in the experiment record.¶
4. Carrier did not return. Cause unknown. This is the honest answer and is more useful than a NaN loss.¶

Practitioners familiar with SHAP values will note that case (iii) is equivalent to a high-attribution input feature with a data pipeline error. The pigeon is blameless in both cases.¶

4.3. Chain-of-Flight vs. Explainability

Recent literature [BAREZ2025] establishes that chain-of-thought reasoning traces in large language models are not equivalent to genuine interpretability. The authors note that a pigeon's flight path is similarly non-explanatory: the carrier arrives or does not. The route taken is unobserved, non-reproducible, and likely influenced by factors outside the training distribution.¶

APC implementations MUST NOT treat carrier arrival as evidence that the intended route was followed. Gradient integrity SHOULD be verified upon receipt via checksum. Checksums MUST be printed in a font legible to the receiving researcher, as OCR error rates on leg-mounted scrolls remain non-trivial (see [BERGEN2001]).¶

Smart Leg Band GPS logging (Appendix A) provides partial flight path reconstruction and is RECOMMENDED for implementations requiring route auditability. The authors note that knowing the route taken does not constitute understanding why. This is also true of transformer attention maps.¶

5.1. Weight Decay

Physical parameter scrolls degrade over repeated use due to moisture, mechanical wear, and carrier enthusiasm. This constitutes a natural form of weight decay. The decay rate is a function of weather and scroll material and is not hyperparameter-tunable in the current specification.¶

5.2. Early Stopping

Training SHOULD be halted when validation loss fails to improve over a defined number of epochs. In APC implementations, practitioners will typically identify this condition when they run out of grain before the model converges. This is considered a valid stopping criterion.¶

5.3. Dropout and Carrier Shuffling

Carrier attrition provides a natural analog to dropout regularization. A Carrier that does not return effectively masks the corresponding parameter subset from the current update. The dropout rate is environment-dependent and not directly configurable.¶

The authors recommend maintaining a 20% reserve Carrier pool to compensate. Practitioners SHOULD NOT attempt to implement structured dropout via deliberate Carrier interception. This is both logistically complex and ethically inadvisable.¶

A peer review of this document identified a statistical bias inherent to naive dropout-via-attrition: if certain Parameter Scrolls are consistently heavier, or if specific Carriers exhibit reduced motivation for particular routes, those gradient components will be non-uniformly dropped across epochs. This constitutes a systematic bias in which the weights most likely to be dropped are precisely those the Carrier finds most burdensome. The authors acknowledge this is not random dropout.¶

To mitigate this effect, Carrier-to-Scroll assignment MUST be shuffled between epochs. No Carrier SHOULD be assigned the same scroll position in consecutive epochs. Implementations SHOULD maintain a Carrier Rotation Log to verify compliance. The authors note that the Carriers themselves do not maintain such a log and cannot be relied upon to self-report assignment history.¶

5.4. Data Augmentation

Carriers operating in varied meteorological conditions implicitly expose the model to augmented training distributions. Rain, wind, and seasonal variation constitute a natural augmentation pipeline. No additional implementation is required. This is one of the few areas in which APC outperforms GPU-based training without qualification.¶

6.1. Parameter Server Architecture

A central loft serves as the parameter server. Remote training nodes dispatch Carriers to the central loft bearing gradient updates. The central node aggregates received updates and returns updated weights via return Carrier.¶

Consistency guarantees are eventual. Practitioners accustomed to synchronous gradient aggregation SHOULD adjust expectations.¶

6.2. Federated Learning

APC is naturally suited to federated learning scenarios in which training data cannot leave the local node. Only gradients are transported, preserving data locality. Privacy guarantees are proportional to the discretion of all parties with access to the Carrier population.¶

6.3. Bandwidth-Delay Product

The effective bandwidth of an APC link is determined by Carrier payload capacity and round-trip flight time. For a Carrier transporting a 512GB NVMe drive over 5 kilometers at standard homing pigeon airspeed (approximately 80 km/h in favorable conditions), peak throughput substantially exceeds that of a T1 line. This comparison is made seriously and has been previously noted in the networking literature.¶

Latency remains non-competitive.¶

9.1. Regulatory Compliance

Parameter Scrolls in transit may constitute personal data under applicable privacy regulations if the training dataset contains personally identifiable information and the model has memorized it, as modern neural networks are known to do.¶

Under the General Data Protection Regulation (GDPR) and similar frameworks, gradient updates can encode and leak information about individual training samples. This property does not change when the gradients are printed on paper and attached to a bird. The medium is novel. The risk is not.¶

Practitioners MUST assess whether Parameter Scrolls constitute personal data under applicable law prior to dispatch. The authors observe that "we sent it via pigeon" is not currently recognized as a valid data transfer mechanism under Article 46 of the GDPR. This may change. The authors are not optimistic.¶

9.2. Gradient Inversion Attacks

Research has demonstrated that model gradients can be inverted to reconstruct training data with meaningful fidelity. An adversary intercepting a Parameter Scroll mid-flight could potentially reconstruct training samples from the gradient values encoded therein.¶

This attack vector is partially mitigated by the following factors inherent to APC:¶

1. Gradient values are encoded in human-readable decimal notation. Reconstruction requires the adversary to also solve OCR and decode the researcher's handwriting.¶
2. The adversary must physically intercept the Carrier. This constrains the attack surface to parties with access to the flight corridor and sufficient reflexes.¶
3. Partial scroll delivery (see Section 5.3) means the adversary may only obtain a subset of gradient values, reducing reconstruction fidelity.¶

Practitioners handling sensitive training data SHOULD apply differential privacy mechanisms prior to printing [PHONG2018]. Adding calibrated Gaussian noise to gradient values before encoding them on the scroll is RECOMMENDED. The noise level MUST be sufficient to provide meaningful privacy guarantees and MUST NOT be so large as to render the gradient values indistinguishable from the researcher's normal handwriting variation.¶

9.3. Data Subject Rights and the Predatory Interception Protocol

If a data subject exercises their right to erasure under applicable privacy law, the practitioner MUST ensure that gradient information derived from that subject's data is purged from all Parameter Scrolls, including scrolls currently in transit.¶

Recalling Carriers mid-flight for the purpose of scroll amendment is not supported in the base specification. Peer review of this document identified this as a critical compliance gap under GDPR Article 17.¶

To address this gap, implementations requiring full regulatory compliance MAY deploy the Predatory Interception Protocol (PIP), in which a trained raptor (Falco peregrinus or equivalent) is dispatched to intercept and neutralize the Carrier prior to arrival at the destination node, thereby preventing the compromised scroll from entering the gradient aggregation pipeline.¶

The authors acknowledge that PIP raises significant concerns under Section 5.3 ("ethically inadvisable"). Practitioners operating under EU AI Act high-risk classification SHOULD consult legal counsel before implementing PIP. Practitioners operating under less stringent regulatory regimes MAY treat mid-flight scroll recovery as out of scope and document this decision in their Data Protection Impact Assessment.¶

The authors offer no opinion on whether a DPIA can legally reference a hawk.¶

10.1. Threat Model

Parameter Scrolls printed on standard paper and transported via avian carrier are subject to electrostatic discharge events arising from:¶

1. Triboelectric charging during flight, particularly at altitude or in low-humidity conditions.¶
2. Contact with synthetic loft materials, carrier leg-bands fabricated from acrylic or nylon, or researchers wearing polyester.¶
3. Rapid descent from altitude in dry atmospheric conditions, which may generate charge differentials sufficient to corrupt high-density gradient encodings.¶
4. The researcher removing the scroll from the Carrier without first grounding themselves. The authors note this is the most common ESD failure mode observed during informal testing and is entirely preventable.¶

A peer review of this document identified an additional threat not addressed in prior drafts: potential difference upon landing. A Carrier that has spent 45 minutes triboelectrically charging against the atmosphere arrives at the loft with a significant accumulated charge relative to ground. A loft operator who is themselves grounded presents as a preferred discharge path. The authors classify this as a "Parameter Pop" event and note it is unpleasant for all parties.¶

10.2. Mitigation Requirements

Practitioners MUST observe the following ESD precautions:¶

1. Loft operators MUST wear ESD-safe wrist straps when handling Parameter Scrolls. This applies during both attachment and retrieval operations. Wrist straps MUST be connected to a ground reference common with the receiving perch (see item (f) below).¶
2. Scrolls SHOULD be printed on anti-static paper where available. In the absence of anti-static paper, standard paper treated with anti-static spray is acceptable. Treated scrolls MUST be allowed to dry completely before attachment. A damp scroll introduces ambiguity (see Section 3.3, NaN loss handling).¶
3. The receiving loft MUST maintain relative humidity between 40% and 60%. Humidity below 40% significantly increases ESD risk. Humidity above 60% significantly increases scroll legibility risk. The authors acknowledge this is a narrow operational window.¶
4. Carriers MUST NOT be dispatched during thunderstorms. This requirement exists for multiple reasons, of which ESD is only the third most important.¶
5. Smart Leg Band implementations (Appendix A) MUST log triboelectric charge accumulation during flight and set the ESD_RISK flag upon landing if accumulated charge exceeds the defined threshold. The Loft Telemetry Dashboard SHOULD alert loft operators prior to scroll retrieval.¶
6. The receiving perch MUST be constructed from a dissipative material (surface resistivity between 10^5 and 10^9 ohms per square) and MUST be connected to building ground via a continuous conductor. This provides a controlled, low-energy discharge path for the returning Carrier and eliminates the loft operator as the path of least resistance. The authors consider this the most important addition prompted by peer review.¶

10.3. Scroll Integrity Verification

Upon receipt, each Parameter Scroll MUST be inspected for signs of ESD damage prior to gradient aggregation. Indicators include:¶

1. Scorch marks or discoloration inconsistent with normal soiling.¶
2. Partial erasure of printed values in a pattern consistent with arc discharge rather than moisture.¶
3. Values that parse as valid floating-point numbers but are implausible given the expected gradient magnitude for this architecture.¶
4. The Carrier appears to have had a bad day.¶

Scrolls failing integrity verification MUST be discarded and the corresponding gradient treated as dropped. Under no circumstances SHOULD the practitioner attempt to recover partially legible values by interpolation and incorporate them into the gradient aggregate. The authors have done this. The model did not recover.¶

10.4. Shock-Based Training Instability (SBTI)

Peer review of this document identified a secondary consequence of the Parameter Pop event (Section 10.1) not addressed in prior drafts: behavioral impact on the Carrier.¶

A Carrier subjected to an uncontrolled electrostatic discharge event upon landing may exhibit reduced motivation in subsequent epochs. This manifests as increased route deviation, extended dwell time at intermediate locations, and in severe cases, a documented reluctance to re-enter the dispatch loft. The authors classify this as Shock-Based Training Instability (SBTI).¶

SBTI is operationally significant because it is self-reinforcing. A Carrier that experienced a Parameter Pop in epoch N is more likely to exhibit high variance in epoch N+1, producing the same high-variance loss characteristics as an overfit model, but arising from loft infrastructure failure rather than gradient pathology. The two causes are distinguished by consulting the Loss Log weather notes and the Carrier's observable disposition. A model that overfit is a modeling problem. A Carrier that was electrocuted is a facilities problem. Both present identically in the loss curve.¶

Mitigation is addressed by the dissipative perch requirement (Section 10.2). The perch provides a controlled discharge path that eliminates the abrupt high-voltage event and replaces it with a gradual, low-energy equalization. A Carrier that lands on a properly grounded dissipative perch experiences no detectable discharge event and proceeds to the scroll retrieval queue with motivation intact.¶

The authors note that this is the only section of this document in which the welfare of the Carrier and the integrity of the gradient are addressed by the same physical component. The dissipative perch is therefore both an ESD mitigation and an animal welfare measure, and MUST be treated as mandatory on both grounds.¶

Carriers exhibiting persistent SBTI symptoms SHOULD be rotated to non-dispatch duties pending behavioral recovery. Forcing an SBTI-affected Carrier to continue active dispatch duty introduces systematic variance into the training loop that cannot be corrected by regularization. The Carrier Rotation Log MUST record SBTI events and the affected Carrier's return-to-active status.¶

11.1. General Threat Model

Parameter scrolls in transit are subject to interception, modification, and consumption. The last failure mode is novel to this transport layer and MUST be considered in threat modeling.¶

Practitioners operating in adversarial environments SHOULD encrypt parameter scrolls. Note that encrypted scrolls require a decryption step at the receiving node, which introduces latency proportional to the legibility of the researcher's handwriting.¶

A Carrier that has been compromised MUST NOT be reintegrated into the Flock without full parameter re-initialization. Supply chain security for grain and nesting materials is out of scope for this document.¶

Model poisoning via corrupted gradient injection is theoretically possible if an adversary gains access to the dispatch loft. Physical perimeter security is RECOMMENDED. A lock on the cage door would also address the failure mode documented in [BERGEN2001] and the data subject erasure gap identified in Section 9.3.¶

11.2. Messenger-in-the-Middle (MitM) Attacks

A class of attack not addressed in RFC 1149 or RFC 2549 is the Messenger-in-the-Middle attack, in which an adversary intercepts a Carrier mid-route and substitutes a modified or entirely fabricated Parameter Scroll prior to release.¶

Known attack vectors include:¶

1. Breadcrumb-based route deviation, in which an adversary lays a trail of grain to redirect the Carrier to an intermediate node outside the intended flight corridor.¶
2. Unauthorized grain-based congregation points (UGBCP), in which a stationary food source in the flight corridor induces the Carrier to land and rest, during which time scroll substitution may occur.¶
3. Loft impersonation, in which a fraudulent destination loft is established within the Carrier's homing radius, exploiting the Carrier's navigation system rather than intercepting it in flight.¶

Mitigations include:¶

1. Scroll signing via printed cryptographic hash. The receiving node MUST verify the hash prior to gradient aggregation. This does not prevent interception but detects substitution.¶
2. Flight corridor hygiene. Practitioners SHOULD ensure the flight path is free of unauthorized grain sources. This is operationally difficult to enforce at scale.¶
3. Smart Leg Band GPS logging (Appendix A) provides post-hoc route verification. Scrolls from Carriers whose logged route deviates significantly from the expected path SHOULD be treated as suspect and subjected to enhanced integrity verification.¶

11.3. Prompt Injection via Avian Mimicry

A novel attack surface is introduced when APC infrastructure operates in geographic proximity to facilities housing psittacine or mimetic avian species, including but not limited to African Grey parrots (Psittacus erithacus), Common Hill Mynas (Gracula religiosa), and Northern Mockingbirds (Mimus polyglottos).¶

These species are capable of reproducing loft call signals, return confirmation sounds, and in documented cases, human speech patterns used in loft management. An adversary with access to a sufficiently trained mimetic bird could:¶

1. Trigger premature loft door opening via synthesized return call, allowing unauthorized Carrier ingress or egress.¶
2. Issue false verbal instructions to loft operators, including scroll handling commands, Carrier assignment directives, or dispatch authorizations.¶
3. In implementations using voice-activated Smart Leg Band pairing (Appendix A), inject unauthorized configuration commands into the telemetry pipeline.¶

The authors note that (b) and (c) are functionally equivalent to prompt injection attacks against large language models, in which adversarial input in the environment causes the model to execute unintended instructions. The mechanism differs. The effect does not.¶

Mitigations SHOULD include:¶

1. Out-of-band verification of verbal loft instructions via a secondary, non-auditory channel.¶
2. Perimeter exclusion zones for mimetic species. The authors acknowledge this is difficult to enforce in areas with established wild mockingbird populations.¶
3. Smart Leg Band voice command authentication SHOULD require a passphrase not reproducible by common mimetic species. Selection of an appropriate passphrase is left as an exercise for the implementor, subject to the constraint that African Grey parrots have demonstrated vocabulary acquisition in excess of one thousand words [PEPPERBERG1999]. Choose accordingly.¶

11.4. Carrier Visual Obfuscation and Adversarial Plumage Patterning

This section describes a dual-purpose technique combining Carrier visual obfuscation with steganographic gradient encoding. The technique addresses two distinct threats: adversarial human interception (Section 11.2) and opportunistic raptor predation (a threat implicitly present in all APC deployments but not previously formalized in this specification).¶

11.5. Security Considerations Summary

For implementors who have reached this section without reading Sections 11.1 through 11.4, the following summary is provided. The authors note that not reading the preceding sections is itself a security risk.¶

The APC architecture introduces three primary threat classes not present in conventional ML infrastructure:¶

Interception:

An adversary may physically intercept a Carrier in transit, obtaining the Parameter Scroll and potentially reconstructing training data via gradient inversion (Section 9.2). Mitigations include scroll encryption (Section 11.1), steganographic encoding (Section 11.4.3), and flight corridor hygiene (Section 11.2). Complete elimination of interception risk requires eliminating the flight corridor, which also eliminates the protocol. This is considered an acceptable tradeoff only if the researcher has access to alternative infrastructure.¶

Modification:

An adversary who intercepts and re-releases a Carrier bearing a modified or substituted scroll introduces corrupted gradients into the training loop (Section 11.2). This is distinguished from a hardware failure in that the corruption is intentional and may be designed to be undetectable. Scroll signing and GPS route verification provide partial mitigation. Neither is foolproof. Neither is the protocol.¶

Consumption:

An adversary, or a sufficiently motivated hawk, may consume the Carrier entirely, resulting in permanent loss of the gradient payload, the storage media, and the Carrier. This threat class is unique to APC among all distributed ML transport protocols currently in the literature. There is no cryptographic mitigation for consumption. Adversarial plumage patterning (Section 11.4) is the primary defense. The authors acknowledge this is a sentence that has not previously appeared in an IETF security summary.¶

12.1. Ethical Treatment of Gradient-Bearing Carriers

The Carriers described in this specification are living organisms. Their welfare is not incidental to the operation of the protocol. It is a direct operational dependency. A Carrier whose welfare is neglected exhibits reduced Carrier Morale (Section 2), increased epoch latency, elevated route deviation, and a higher probability of non-return. Ethical treatment of Carriers is therefore both a moral obligation and a performance optimization. The authors note this is one of the few cases in distributed systems where the two are identical.¶

Practitioners MUST provide:¶

1. Adequate nutrition. Carrier Morale degrades measurably under caloric deficit. Grain quality SHOULD be appropriate to the Carrier's operational workload. A Carrier dispatched on a long-haul RAID-0 configuration SHOULD receive proportionally more grain than one dispatched on a single-scroll Coach-class assignment.¶
2. Adequate rest. Dispatching a Carrier before full recovery from a prior epoch introduces fatigue-related variance into the training loop. Minimum rest intervals SHOULD be established based on round-trip distance and prevailing weather conditions. Rushing the rest interval to meet a training deadline is the avian equivalent of reducing the learning rate warmup period. The consequences are similar.¶
3. Veterinary access. Carriers exhibiting symptoms of illness, injury, or persistent SBTI (Section 10.4) MUST be removed from active duty and assessed by a qualified avian veterinarian. The Loss Log MUST record the removal and estimated return-to-duty date. A Carrier that is unwell is not a gradient delivery mechanism. It is an unwell bird. Treat it accordingly.¶

12.2. Bias in Carrier Selection

Selection of Carriers for dispatch assignments MUST NOT introduce systematic bias into the gradient transport process. Known sources of selection bias include:¶

1. Preferential assignment of lighter scrolls to smaller or lower-Morale Carriers. This produces non-uniform gradient dropout correlated with Carrier physical characteristics, which is not random dropout and cannot be modeled as such.¶
2. Consistent assignment of high-priority scrolls to a small subset of high-performing Carriers. This creates a single point of failure in which the loss of one or two Carriers disproportionately affects training outcomes. The Carrier Rotation requirement (Section 5.3) partially addresses this but MUST be actively enforced rather than assumed.¶
3. Unconscious preference for Carriers that have previously returned quickly, without accounting for the possibility that fast return times reflect route familiarity rather than general performance. A Carrier that is fast on a known route MAY be slow or unreliable on a novel route. Generalization cannot be assumed from training performance. The authors note this is also true of ML models.¶

12.3. Informed Consent for Raptors

The Predatory Interception Protocol (Section 9.3) involves the deployment of a trained raptor to intercept Carriers bearing compromised Parameter Scrolls. The raptor participates in this protocol involuntarily, as raptors cannot provide informed consent to participation in ML compliance workflows.¶

The authors acknowledge this is an unresolved ethical gap. Deployment of PIP MUST be reviewed by an institutional ethics board, or the nearest available equivalent, before implementation. Documentation of this review MUST be retained.¶

The authors also note, for completeness, that the Carrier subject to PIP has also not provided informed consent. This is noted without resolution. The GDPR does not currently address avian data subjects. This may change.¶

12.4. Environmental Considerations

Large-scale APC deployments involve significant numbers of Carriers operating in shared airspace. Practitioners MUST assess the environmental impact of their Carrier fleet on local ecosystems, including but not limited to:¶

1. Competition with wild pigeon populations for food resources within the flight corridor.¶
2. Disruption to existing bird of prey territories caused by increased prey density. Practitioners deploying adversarial plumage patterning (Section 11.4) to deter raptor predation should be aware that sustained deterrence may alter local predator foraging behavior in ways that extend beyond the flight corridor.¶
3. The carbon footprint of printing gradient values on paper at scale. The authors have not computed this figure. The authors suspect it compares favorably to a 1,800-GPU training cluster. The authors acknowledge they may be motivated to believe this.¶

15.1. Model Size Scaling

At the time of this writing, frontier models are estimated at 1.7-1.8 trillion parameters (Section 8, Concorde class). The trajectory of model scaling suggests this figure will continue to increase. The APC architecture must address the physical implications of this trend.¶

A single 32-bit floating-point parameter requires 4 bytes of storage. A 1.8 trillion parameter model therefore requires approximately 7.2 terabytes in full precision, or approximately 900 gigabytes at 1-bit quantization. At the time of publication, no commercially available leg-band storage medium approaches this capacity.¶

Practitioners SHOULD apply aggressive quantization prior to scroll encoding. The authors note that 4-bit quantization, now standard practice for local inference, reduces the 1.8T parameter model to approximately 900GB, which is achievable via a multi-Carrier RAID-0 Dove Configuration (Section 3.2) with a fleet of approximately 1,800 Carriers each carrying a 512GB NVMe drive.¶

The authors acknowledge that a fleet of 1,800 Carriers represents a meaningful operational commitment. Institutions unable to sustain this fleet size SHOULD consider whether they are training the correct model for their resource envelope. This advice applies equally to conventional infrastructure.¶

As model sizes continue to grow, this specification anticipates two possible evolutionary paths:¶

1. Advances in storage media density will increase per-Carrier payload capacity, maintaining feasibility at current Carrier-to-parameter ratios.¶
2. Advances in model compression, quantization, and distillation will reduce effective model size faster than raw parameter counts grow, improving the ratio in the other direction.¶

The authors consider path (b) more likely and note that it represents a genuine alignment of interests between the ML efficiency research community and the avian transport community. This alignment has not previously been documented.¶

15.2. Framework and Format Versioning

The ML framework ecosystem evolves rapidly. Parameter Scroll format compatibility across framework versions is a non-trivial operational concern. A scroll serialized under PyTorch 2.x tensor format may not be directly interpretable by a receiving node running a subsequent major version, a different framework entirely, or a researcher who has not updated their deserialization tooling since the model was dispatched.¶

This specification REQUIRES that all Parameter Scrolls include a Scroll Header (SH) prepended to the gradient payload. The Scroll Header MUST be printed in a standardized, human-readable format and MUST contain:¶

1. Framework name and major version (e.g., "PyTorch 2.7").¶
2. Serialization format identifier (e.g., "safetensors", "pickle", "GGUF").¶
3. Quantization scheme and bit depth.¶
4. Scroll sequence number and total scroll count, for RAID-0 Dove Configuration reassembly.¶
5. Colorimetric key version, if steganographic encoding is in use (Section 11.4).¶
6. A single-line human-readable description of the model architecture sufficient to detect obvious mismatches at the receiving node before gradient aggregation begins. The authors RECOMMEND a format such as: "Llama-class, 70B, MoE 8x9B, layer 42 of 80." A receiving researcher who reads this line and does not recognize the architecture SHOULD NOT proceed with aggregation.¶

The Scroll Header MUST be verified by the receiving node before the gradient payload is processed. A version mismatch MUST produce a clear error in the Loss Log and MUST NOT result in silent gradient corruption. The authors note that silent gradient corruption on conventional infrastructure is a well-documented and deeply unpleasant failure mode. The scroll header exists precisely to make this class of error loud and attributable.¶

15.3. Topology Scaling: Beyond the Single Parameter Server

Section 6.1 describes a hub-and-spoke topology with a central parameter server loft. This topology does not scale to the distributed training configurations required by frontier models, which employ pipeline parallelism, tensor parallelism, and expert parallelism across hundreds or thousands of nodes.¶

This specification defines three extended topologies for large-scale APC deployments:¶

Ring-Flock Topology:

Carriers travel a circular route between N training nodes, each node updating its assigned parameter shard before dispatching the Carrier to the next node. Gradient aggregation is distributed across the ring. Latency scales linearly with ring size. The authors note that a Ring-Flock of 64 nodes, each at 5km separation, describes a flight circuit of 320km. At standard homing pigeon cruising speed this represents an epoch duration of approximately 4 hours under favorable conditions. This is slower than conventional ring-AllReduce but requires significantly less InfiniBand cabling.¶

Hierarchical Flock Topology:

Training nodes are organized into regional clusters, each with a local aggregation loft. Local gradients are aggregated regionally before a subset of Carriers transport the regional aggregate to the global parameter server. This reduces total Carrier count at the cost of introducing aggregation delay at two levels. Practitioners familiar with gradient compression and local SGD will recognize this topology. The pigeon version offers equivalent theoretical properties and superior scenic variety.¶

Expert-Parallel Flock Topology:

For Mixture-of-Experts architectures, each expert's parameters are assigned to a dedicated sub-flock. Expert routing decisions are encoded in a separate Routing Scroll dispatched ahead of the parameter Carriers. The Routing Scroll MUST arrive before the parameter Carriers to avoid aggregation at the wrong expert node. In practice, this means the Routing Scroll Carrier MUST be dispatched first and MUST be a faster-than-average Carrier. Selection criteria for the Routing Scroll Carrier are outside the scope of this document but SHOULD include demonstrated navigational reliability and a history of not joining recreational flocks en route.¶

15.4. Inference Scaling and Serving

This specification has addressed training throughput in detail. Inference serving presents distinct scaling challenges.¶

A deployed model receiving queries must return predictions within a latency envelope acceptable to the requesting application. For most applications this envelope is measured in milliseconds to seconds. APC inference latency is measured in hours. This gap is not currently bridgeable within the constraints of avian flight physics.¶

The authors therefore formally RECOMMEND that APC implementations decouple training and inference infrastructure. APC is appropriate for the training loop. Inference SHOULD be served via conventional digital infrastructure after model weights have been transported to the serving node by Carrier and loaded onto appropriate hardware.¶

The authors note that this hybrid architecture -- avian training transport, digital inference serving -- is consistent with the broader principle that the right tool should be selected for each phase of the ML lifecycle. APC excels at asynchronous, high-payload, low-frequency gradient transport. It does not excel at sub-second token generation. These are not the same problem. Treating them as the same problem is a category error that no amount of grain will resolve.¶

15.5. New Framework Onboarding

As new ML frameworks emerge, this specification requires only that their serialization formats be registerable in the Scroll Header framework identifier field (Section 15.2). No changes to the physical transport layer are required. The Carrier does not care what framework serialized the weights it is carrying. This is one of the more durable properties of the APC architecture and is considered a design strength.¶

Framework deprecation SHOULD be handled by sunsetting the corresponding Scroll Header identifier. Scrolls bearing deprecated framework identifiers MUST be flagged at the receiving node. Whether to process them anyway is a decision for the receiving researcher, who by that point presumably knows what they are doing. Or does not, and the Loss Log will reflect this.¶

15.6. Quantum Computing Compatibility

The emergence of fault-tolerant quantum computing raises the question of whether APC remains viable as a transport layer for quantum ML workloads, or whether quantum methods will supplant the requirement for avian carriers entirely.¶

The authors address this in two parts.¶

Part I: Quantum ML Parameter Transport. Quantum ML models represent parameters as quantum states rather than classical floating-point values. Quantum states cannot be copied without disturbance (the No-Cloning Theorem, Wootters and Zurek, 1982 [NOCLONING]). A Parameter Scroll encoding a quantum state would therefore constitute a measurement of that state, collapsing the superposition and destroying the quantum information in the act of printing it.¶

The authors conclude that APC is fundamentally incompatible with native quantum parameter transport. A pigeon cannot carry a qubit. More precisely: by the time the qubit has been attached to the pigeon's leg, it is no longer a qubit. It is a classical value, and the quantum advantage has been surrendered to the leg band.¶

This is not a limitation of the pigeon. It is a limitation of measurement. The pigeon is, once again, blameless.¶

Part II: Will Quantum Methods Supplant the Pigeon? Quantum computers offer theoretical speedups for specific problem classes, including optimization problems relevant to ML training. However, the question of whether quantum methods will supplant APC conflates two distinct concerns:¶

1. Whether quantum computers will perform ML training faster than classical computers.¶
2. Whether, given (a), the parameter transport layer becomes irrelevant.¶

Regarding (a): quantum advantage for general ML training remains undemonstrated at scale. Current quantum hardware operates at qubit counts and error rates that preclude practical ML workloads. The authors note that "practical quantum ML" has been approximately five years away for approximately fifteen years. Carrier fleets established today are unlikely to be rendered obsolete by quantum hardware before they reach retirement age.¶

Regarding (b): even assuming quantum ML training achieves practical advantage, the trained model weights must still be transported to inference infrastructure. If those weights are classical (as is likely for deployed models, given the state of quantum memory), the APC architecture remains a viable transport option.¶

The authors therefore conclude that quantum computing does not supplant the requirement for pigeons. It may, in the long term, change what is printed on their scrolls. The scrolls themselves, and the birds carrying them, remain relevant.¶

A future revision of this specification MAY address hybrid quantum-classical parameter transport in which classical gradient approximations of quantum circuit parameters are encoded on Parameter Scrolls. The authors consider this a tractable extension. The pigeons have no opinion on quantum mechanics and are not expected to develop one.¶

Overview

The Smart Leg Band (SLB) is an optional hardware extension to the APC architecture providing in-flight telemetry, automated scroll integrity monitoring, and loft handshake capabilities. Deployment of the SLB is OPTIONAL but RECOMMENDED for implementations where scroll loss rate exceeds 20% or where regulatory compliance requires documented chain-of-custody for Parameter Scrolls.¶

Hardware Components

The reference implementation specifies the following components:¶

Microcontroller:

ESP32-C3, selected for compact footprint, integrated Wi-Fi and Bluetooth LE, and deep sleep current draw of approximately 5 microamperes. The ESP32-C3 MUST be coated with a conformal protective resin prior to installation. Pigeons WILL attempt to debug uncoated hardware using their beaks. This is not hypothetical. The authors classify uncoated ESP32 exposure to Carrier grooming behavior as "Physical Bit-Rot" and note that it is entirely preventable. Coat the board.¶

Moisture Sensor:

A capacitive sensor element modified for paper-contact operation, wrapped circumferentially around the Parameter Scroll beneath the leg band. Provides continuous humidity readings for the scroll surface. Threshold values and corresponding actions are defined in Appendix "Table 1: Moisture Level Action Matrix".¶

Power Supply:

A single-cell LiPo battery, minimum 100mAh, selected to maintain the Carrier's payload budget within the constraints of Section 3.2. The ESP32-C3 MUST operate in Deep Sleep between sample intervals to preserve capacity across the full expected flight duration. Wake interval SHOULD be configurable but SHOULD NOT exceed 5 minutes to ensure adequate temporal resolution of moisture events.¶

Loft Detection:

Either (a) Wi-Fi RSSI-based proximity detection, triggering loft handshake when signal strength from the loft access point exceeds a configurable threshold, or (b) a Hall Effect sensor at the loft trap door, triggering on Carrier ingress. Option (b) is preferred for reliability. Option (a) is preferred when the researcher has already 3D-printed the trap door and does not wish to reprint it.¶

ESD Monitor:

Capacitive touch pin monitoring for triboelectric charge accumulation. Logs timestamp and estimated charge level for any discharge event detected during flight. Sets ESD_RISK flag in metadata if accumulated charge exceeds operational threshold upon approach to loft.¶

Table 1: Moisture Level Action Matrix

Moisture (%)   WET_BIT   Action
--------------------------------------------------------
0 - 20         0         Optimal.  Process gradient normally.

21 - 50        0         Humid.  Apply Ink Blur correction
                         algorithm prior to OCR.

51 - 80        1         Damp.  MAY attempt OCR.  Treat
                         resulting gradient as high-variance.
                         Weight accordingly in aggregation.

> 80           1         MUST discard.  Treat as NULL gradient.
                         Allow Carrier to towel-dry before
                         reassignment.  Do not attempt OCR.
                         The authors have attempted OCR at
                         this moisture level.  The results
                         were not gradients.

Data Ingestion and Telemetry

The SLB operates in Store-and-Forward mode. All sensor readings are logged to the ESP32-C3 internal flash during flight. No active transmission occurs in-flight, as Wi-Fi connectivity at operational altitude is not supported and the power budget does not accommodate sustained radio operation.¶

Upon Carrier entry into the loft (detected per Appendix "Hardware Components", Loft Detection), the ESP32-C3 exits Deep Sleep, connects to the local Wi-Fi network, and transmits the accumulated telemetry log to the Loft Telemetry Dashboard prior to any physical interaction with the Carrier by loft personnel.¶

The Loft Telemetry Dashboard is a containerized web application deployable via Docker Compose on any OCI-compliant container orchestration platform. It provides:¶

1. Real-time display of incoming SLB telemetry.¶
2. Automated WET_BIT alert, notifying loft operators of scroll moisture status before handling.¶
3. ESD_RISK flag display, prompting operators to verify wrist strap grounding and perch continuity before approaching the Carrier.¶
4. Automated Loss Log population for moisture-flagged epochs, reducing manual transcription errors.¶
5. Carrier Rotation Log maintenance, enforcing the shuffling requirement of Section 5.3.¶
6. MitM route deviation alerts, flagging Carriers whose GPS track deviates from the expected corridor by more than a configurable threshold.¶

Docker Compose configuration for the Loft Telemetry Dashboard is available in the project repository. The authors note that the repository does not currently exist but express confidence that it will by the time this RFC is published.¶

Optical Capture and Colorimetric Decode System

Implementations deploying steganographic scroll encoding (Section 11.4) MUST equip the receiving loft with a calibrated optical capture device positioned to image each returning Carrier prior to landing on the receiving perch.¶

Hardware requirements:¶

1. Camera resolution MUST be sufficient to resolve the colorimetric encoding pattern at the expected approach distance. Minimum 12 megapixels is RECOMMENDED for standard leg-band pattern densities.¶
2. Where Section 11.4.2(c) UV threat modeling is in scope, the capture device SHOULD include a UV-capable sensor or a secondary UV-band camera. Standard CMOS sensors are not UV-sensitive and will not detect residual markings in that spectrum.¶
3. Lighting at the approach corridor MUST be consistent and controlled. Variable ambient lighting introduces colorimetric decoding errors. The authors RECOMMEND a covered approach corridor with fixed artificial lighting calibrated to the colorimetric key's reference illuminant. The authors note this is a meaningful infrastructure investment and that a well-lit trap door is also acceptable for low-security deployments.¶

Decode pipeline:¶

1. On Carrier approach detection (via SLB RSSI or Hall Effect trigger, per Appendix "Hardware Components"), the optical system captures a reference image.¶
2. The captured image is processed against the current colorimetric key to extract gradient metadata.¶
3. If no valid encoding is detected, the system sets NULL_GRADIENT status for this Carrier and notifies the loft operator that scroll retrieval will yield no gradient data and that the Carrier should proceed directly to the scrub station.¶
4. If encoding is detected but fails key validation, the Carrier MUST be quarantined. This indicates either key mismatch (epoch management error) or scroll substitution by an adversary who obtained the colorimetric key but not the full key schedule. Treat as a potential MitM event per Section 11.2.¶
5. Decoded metadata MUST be fused with SLB telemetry before the Loss Log entry for this epoch is finalized.¶

The optical capture system operates independently of the SLB and requires no hardware on the Carrier. It is therefore compatible with non-SLB deployments that have opted into colorimetric encoding only. The authors consider this a useful deployment flexibility and note that it also means the Carrier's ESP32-C3 is not required to know anything about the steganographic layer, which simplifies firmware scope and reduces the surface area available to beak-based debugging.¶

Firmware Security

SLB firmware MUST be cryptographically signed. Over-the-air firmware updates are supported via the loft Wi-Fi network and MUST be authenticated before installation.¶

Voice-activated configuration commands, if implemented, MUST be authenticated via passphrase as specified in Section 11.3. The authors reiterate that the passphrase MUST be selected with awareness of local mimetic species populations. An African Grey parrot has a documented vocabulary exceeding one thousand words [PEPPERBERG1999]. Implementors in affected regions are advised to plan accordingly.¶

Physical access to the ESP32-C3 is prevented by conformal resin coating (Appendix "Hardware Components"). The authors wish to be clear that this coating serves dual purpose: it protects against moisture ingress, and it protects against the Carrier. Both threats are real. Both are addressed by the same countermeasure. This is considered an elegant solution.¶