Implemented checks and boundaries

This is an implementation note for the supplied 0.3.4 source. It separates executable behavior from the broader design in the manual.

What is checked

• The parser reads AIL/0.2 and AIL-PASSPORT/0.2 values and rejects malformed syntax and duplicate record fields.
• For M records, validation requires id, act, registry and body; checks act against A01–A10; requires ref for A05, A06, A09 and A10; and checks supplied confidence lies in 0–1.
• Recognized functions have argument-count checks, including three arguments for P.
• Strict registry validation rejects unknown identifiers beginning with ail:.
• Canonicalization removes display aliases and normalizes representation. It does not translate prose or resolve ambiguous meanings.

Known gaps

• Validation is not a closed application schema: it does not reject every unknown function or record type, require every identifier to be registered, or fully type-check all message fields.
• The registry field is required, but its value is not checked against the loaded registry by this validator. The caller must select and enforce its application profile.
• A valid proposition can still be false. Confidence is supplied by the sender; it is not a calibrated probability.
• Parsing a request never executes it. Authentication and authorization are the receiver’s responsibility.

Identity packets

Signature verification checks integrity under a corresponding key. An independently supplied expected fingerprint can recognize that key. A verified HTTPS anchor associates a key with control of that origin. None of these alone verifies a person’s legal identity or grants external permissions.

Inspect validator.py · Inspect packet.py · Inspect the tests