You maintain a vulnerability tracker and want it to talk to your partners
You build or run the system where vulnerability reports and cases live: a tracker, a coordination platform, a disclosure portal, or an internal tool. Today your partners reach it through accounts on your system, or you reach theirs through accounts on theirs. This page is a reading path through the parts of this site that describe what your system sends, when it sends it, and where your own logic plugs in. Each section builds on the ones before it; read a numbered list in order and a bulleted list in any order.
Understand the shape of the integration
- What Is Vultron? — the protocol, its four senses, and what conformance means for your system.
- Capability Model — every decision the protocol leaves open, and the call-out point where your system answers it.
- Process Implementation Notes — where an existing ticket workflow's milestones map onto protocol messages.
Send your first message
- Tutorial: Submit a report to a Vultron actor — one report, sent to a running actor, end to end.
- Vultron and ActivityPub — the wire format every message uses.
- Message Semantics — what each message means to the participant who receives it.
- Protocol Event Flow — how a received message turns into state changes and replies.
Build against the contract
- Vultron Protocol Specification — the normative protocol, including the conformance claims your system can make.
- Message Types — every message, its fields, and when it is sent.
- Trigger API Reference — the endpoints your system calls to act on a case.
- Wiring a Capability into the Reference Implementation — replacing a stub decision with your own service.
- How-to Guides — the remaining task-oriented guides.