Reference

Inherited Requirements

This page is normative

This page is considered a core part of the Vultron Protocol. This is a normative section of the documentation.

The whole specification on one page

The specification is also published as a single page that holds every section and annex in order, for printing or for searching the whole text at once.

This page holds section 14.8 of the Vultron Protocol Specification, part of its Requirements Catalog. Each row is one requirement, and the rest of the documentation links a requirement to its row here.

14.8 Inherited Requirements

These are the rules Vultron inherits from the standards beneath it: ActivityStreams 2.0 (AS2), ActivityPub, and the Hypertext Transfer Protocol (HTTP). They cover addressing and delivery, HTTP status codes, and rules that only restate AS2, such as every object ID being an Internationalized Resource Identifier (IRI). Where Vultron asks for one form among several that a standard allows, the rule is a Vultron requirement on one of the pages before this one, not an inherited one.

Vocabulary Model

Requirements governing how ActivityStreams 2.0 vocabulary types are defined, registered, configured, and deserialized in the Vultron wire layer. The vocabulary model is the foundation of the inbound pipeline: every activity must be deserialized into a known vocabulary type before semantic extraction can assign it a domain meaning.

Serialization Rules

ID	Priority	Requirement	Related
VM-07-002	MUST	Serialized messages MUST use the ActivityStreams 2.0 property names, which are camelCase, never another spelling such as Python snake_case field names. ActivityStreams 2.0 defines its property names in camelCase, and the Vultron context defines the Vultron properties in the same form. A receiver that reads a message by those names does not find a snake_case key, so the value is lost. Using the defined names is what lets another implementation read the message.

Message Validation

Requirements for validating ActivityStreams 2.0 activities at the inbox handler boundary, covering ActivityStreams structure and semantic validation. Invalid activities are rejected with appropriate error responses before dispatch.

Activity Structure Validation

ID	Priority	Requirement	Related
MV-01-001	MUST	Incoming payloads MUST conform to ActivityStreams 2.0 structure Vultron messages are ActivityStreams 2.0 activities. Thus a payload that is not a correct AS2 activity has no defined meaning for the receiver. When the parser refuses the payload, the malformed input does not get to semantic extraction or to the handlers. These stages can then rely on the AS2 structure.

URI Validation

ID	Priority	Requirement	Related
MV-05-001	MUST	The system MUST validate that ID and reference fields contain valid URIs ActivityStreams 2.0 gives every id and every reference as an IRI, so a value that is not one is not a well-formed activity. Vultron inherits the rule.

Semantic Extraction

The inbox handler extracts semantic meaning from ActivityStreams activities by matching activity type and object type patterns. This semantic type determines which handler function processes the activity.

Pattern Matching

ID	Priority	Requirement	Related
SE-01-002	MUST	A receiver MUST cope with an object given either inline or as a URI reference, as ActivityStreams 2.0 allows. ActivityStreams 2.0 lets a sender give an object inline or by its URI, and conforming peers use both forms. If a receiver accepts only one form, it refuses or misreads correct messages from those peers.

Actor Knowledge Model

Defines the Actor Knowledge Model: a Vultron Actor's knowledge of the world is strictly bounded by the ActivityStreams 2.0 activities it has received. Actors must not assume recipients hold objects that were not explicitly included in prior activities; DataLayer access is private and non-shareable, and all inter-Actor communication occurs exclusively through the AS2 wire protocol.

Actor Addressing and Discovery

ID	Priority	Requirement	Related
AKM-05-001	MUST NOT	The absence of a local record of a peer actor MUST NOT prevent an actor from addressing an outbound activity to that peer. The peer's deliverable http(s) URI is sufficient for addressing; a fully resolved actor record is an enrichment (directory service), not a precondition for protocol participation. An actor often first learns of a peer only as a URI, for example in a recommendation or a report. If addressing required a local record, the actor could not invite or answer that peer until a directory had been consulted, which would make a directory service a precondition for taking part in a CVD case.

Code Style Specifications

Defines code formatting, import organization, and coding style standards for Python code in the Vultron project.

Datetime and Timezone Conventions

ID	Priority	Requirement	Related
CS-13-006	MUST	Wire-format datetime fields MUST serialize as RFC 3339 date-times with an explicit offset, so no naive or offset-free value reaches the wire. ActivityStreams 2.0 requires every date-time value to follow the RFC 3339 date-time form, in which the offset is mandatory. A peer cannot read a value without an offset as one instant, so it cannot compare it with other times. CS-13-005 holds Vultron's rules on which offset a timestamp carries.

Idempotency

Requirements for handling duplicate activity submissions gracefully, ensuring repeated identical requests produce the same outcome without unintended side effects.

Activity ID Uniqueness

ID	Priority	Requirement	Related
ID-01-001	MUST	All activities MUST have globally unique id field (URI) ActivityPub requires every object, activities included, to carry a unique global identifier; ActivityStreams 2.0 alone leaves id optional. Duplicate detection (ID-02) relies on it.

Object ID

Requirements for the format and handling of object identifiers throughout the Vultron system. Establishes full-URI IDs as the canonical form for all ActivityStreams objects and DataLayer records.

ID Format

ID	Priority	Requirement	Related
OID-01-001	MUST	All ActivityStreams object IDs MUST use full URI form ActivityPub requires every object it distributes to carry a publicly dereferenceable URI as its identifier, which a relative or bare identifier is not. ActivityStreams 2.0 alone only says relative references SHOULD NOT be used. Vultron inherits the ActivityPub rule.	Implements: VP-16-002 Implements: VP-16-003
OID-01-002	MUST	IDs MUST be unique within the issuing actor's deployment; cross-deployment uniqueness is achieved by requiring full URI form (OID-01-001) with a deployment-controlled authority component. Restates ActivityPub's identifier rule: an object's URI has an authority belonging to the server that originated it, so that server keeps it unique and uniqueness across deployments follows from the full URI form.

Response Format

The Vultron protocol uses ActivityStreams activities for both requests and responses. When handlers process inbound activities, they generate response activities (Accept, Reject, Update, etc.) sent to the originating actor or other participants.

Response Activity Structure

ID	Priority	Requirement	Related
RF-01-001	MUST	Response activities MUST conform to ActivityStreams 2.0 Responses travel through the same AS2 inbox pipeline as every other activity. A response that does not conform to AS2 cannot be parsed or matched to a semantic by its receiver, so the initiator would never learn the answer.

Response Delivery

ID	Priority	Requirement	Related
RF-06-001	MUST	Response activities MUST be delivered to the relevant actors' inboxes ActivityPub delivers every activity to the inboxes of its addressees; a response is no exception. Which actor a response goes to is Vultron's rule (RF-06-002).

HTTP Protocol Requirements

HTTP protocol requirements for the Vultron API, covering status codes, headers, and content negotiation.

Content-Type Validation

ID	Priority	Requirement	Related
HTTP-01-002	MUST	Inbox endpoint MUST accept application/ld+json; profile="https://www.w3.org/ns/activitystreams" Content-Type This is the media type ActivityPub names for delivery to an inbox. Vultron inherits the rule rather than defining it.
HTTP-01-003	MUST	Inbox endpoint MUST reject requests with invalid Content-Type using HTTP 415 HTTP defines 415 Unsupported Media Type as the answer to a request whose content is in a format the target resource does not support.

HTTP Status Codes

The status codes HTTP itself defines for each outcome, which Vultron inherits (foundation, http). Where HTTP leaves the choice open, as with 422 for a schema failure, the code is this codebase's choice and the spec is project.

ID	Priority	Requirement	Related
HTTP-03-001	MUST	The API MUST return 200 OK for successful reads. Standard HTTP success code for GET and other read operations.
HTTP-03-003	MUST	The API MUST return 202 Accepted for queued processing. Indicates the request was accepted but processing is deferred to a background job.
HTTP-03-004	MUST	The API MUST return 400 Bad Request for malformed input. Signals that the client submitted a syntactically invalid request that cannot be parsed.
HTTP-03-005	MUST	The API MUST return 404 Not Found for missing resources. Indicates the requested resource does not exist in the system.
HTTP-03-006	MUST	The API MUST return 405 Method Not Allowed for unsupported methods. Informs the client that the HTTP method used is not supported on this endpoint.
HTTP-03-007	MUST	The API MUST return 413 Content Too Large for oversized payloads. Rejects requests exceeding the configured payload size limit (see HTTP-02-001).
HTTP-03-008	MUST	The API MUST return 415 Unsupported Media Type for invalid Content-Type. Rejects requests whose Content-Type header is not an accepted media type (see HTTP-01-003).
HTTP-03-010	MUST	The API MUST return 429 Too Many Requests for rate-limit violations. Signals that the client has exceeded the permitted request rate and must back off.
HTTP-03-011	MUST	The API MUST return 503 Service Unavailable when it is temporarily unable to handle a request, such as while overloaded, under maintenance, or before the storage it needs is ready. HTTP defines 503 for a server that is temporarily unable to handle the request because of overload or scheduled maintenance, a condition expected to clear after some delay. Vultron inherits that rule. A transient error inside a request the server could handle is not that condition, so it does not draw this code.

Inbox Endpoint

The inbox endpoint is the primary entry point for actor-to-actor communication in Vultron. It receives ActivityStreams activities via HTTP POST, validates them, and queues them for asynchronous processing.

Endpoint Configuration

ID	Priority	Requirement	Related
IE-02-001	MUST	The endpoint URL MUST be discoverable from actor profile ActivityPub requires every actor object to carry its inbox property, so a peer finds the endpoint from the profile rather than by a URL convention, which also leaves each deployment free to place it.
IE-02-002	MUST	The endpoint MUST accept activities delivered to it by HTTP POST. ActivityPub delivers an activity to an inbox by HTTP POST. Vultron inherits the rule. That POST is the only method the inbox serves is this codebase's choice (IE-02-005).
IE-02-003	MUST	The endpoint MUST reject non-POST requests with HTTP 405 The inbox is a delivery target, not a mailbox other actors may read: ActivityPub grants an inbox read only to the actor's own authenticated owner, and Vultron has no authentication, so a GET here would open another actor's mail. The 405 covers both trailing-slash forms, and it does not fall out of having no GET route: the profile route is a path catch-all (/{actor_id:path}) that answers 404 to an unrouted GET, so the inbox path needs its own method refusal declared ahead of it.	Depends on: HTTP-03-001

Request Handling

ID	Priority	Requirement	Related
IE-03-001	MUST	The endpoint MUST validate Content-Type header The Content-Type header tells the receiver how to read the body. A body sent as another media type may not be an ActivityStreams document. If the inbox checks the header first, it can refuse such a body with a clear answer (HTTP-01-003) before it parses the body.	Depends on: HTTP-01-001
IE-03-003	MUST	Requests exceeding the maximum request body size MUST be rejected with HTTP 413. Rejecting oversized payloads with an explicit 413 prevents resource exhaustion and signals the limit violation to the sender.	Refines: IE-03-002 Depends on: HTTP-02-001 — HTTP-02-001's default limit decides when this 413 applies; HTTP-02-001 keeps only the limit, and the 413 answer stays here (MS-12-010)

Error Responses

ID	Priority	Requirement	Related
IE-07-001	MUST	The endpoint MUST answer with the status code HTTP defines for each transport failure: HTTP 400 for a malformed request, HTTP 405 for a method other than POST, and HTTP 413 for a request body over the size limit. HTTP defines these status codes for these failures. Any peer with an HTTP client understands them without knowledge of Vultron, so the inbox uses them as HTTP defines them.	Depends on: HTTP-03-001

Outbox

Requirements for actor outboxes, which hold response activities generated by handlers. Covers outbox structure, population, delivery, local and federated dispatch, idempotency, outbound reference dehydration, and outbox addressing rules.

Outbox Population

ID	Priority	Requirement	Related
OX-02-002	MUST	Each outbox activity MUST conform to ActivityStreams 2.0 structure Recipients are ActivityStreams 2.0 (AS2) and ActivityPub peers. A peer routes a body by its AS2 type, and it reads the terms of the body through @context. A body without that structure does not mean anything to the recipient.

Outbox Delivery

ID	Priority	Requirement	Related
OX-03-001	MUST	Activities in an actor's outbox MUST be delivered to recipient inboxes ActivityPub's delivery rule: a server posts each activity in an actor's outbox to the inbox of every addressee. Vultron inherits it.

Agentic Readiness

Requirements for API and CLI design that enable reliable interaction by automated agents and AI systems. Covers machine-parseable interfaces, structured response formats, and observable behavior that supports agentic workflows.

Actor Discovery Profile

ID	Priority	Requirement	Related
AR-10-002	MUST	The profile endpoint MUST return HTTP 404 when the actor is not found HTTP defines 404 Not Found as the answer to a request for a resource the server does not have (HTTP-03-005). Vultron inherits the rule.