As a cross-project catalogue entry, the only thing this page must guarantee is honest, non-duplicating visibility:

• Provenance is clear. The service is owned by BB; its build, agents, and pipeline are BB's, not Carol's.
• No false attribution. Carol's internal stack, agents, and build pipeline are NOT assumed for this service.
• The detail lives upstream. Functional guarantees for security and threat-vigilance are defined and maintained inside the BB project.

Vigilance's implementation lives in the BB project and is not documented here. BB is a Carol-adjacent project that runs the same broad shared Carolverse stack (Python 3 services behind nginx, SQLite datastores, systemd/cron for scheduling), but the specific technologies, datastores, and AI steps for this service are owned and recorded by BB. Treat anything beyond this as BB-internal until BB publishes it.

This is a cross-project catalogue entry, not a Carol-built pipeline. Vigilance is owned and operated by the BB project; its blocks, control plane, and team are defined there. The Carolverse catalogue carries it for visibility under the org-wide Carolverse architecture only — for the actual solution architecture, follow the service to the BB project.

• Project separation. BB and Carol are kept completely separate; this catalogue entry never pulls Carol internals into a BB service.
• Single source of truth. The authoritative design for Vigilance is BB's, not this stub — see the Carolverse Architecture page for the shared catalogue principle.
• Honest visibility. A cross-project entry states what is known and points upstream for the rest, rather than inventing detail.

• The catalogue correctly shows Vigilance as BB-owned and external to Carol's build.
• No Carol agent, droid, or pipeline is attributed to it.
• A reader can tell at a glance that the real architecture lives in the BB project and where to look for it.

• BB and Carol stay completely separate — this entry is for visibility only and carries no Carol governance over the service.
• Owner is BB. Ownership and accountability for Vigilance sit with the BB project.
• No invented internals. This page states only what the catalogue knows; BB internals are documented in the BB project, under BB's own process.

Current

• A cross-project catalogue entry for Vigilance — owner, status, and intent — surfaced in Carolverse for visibility, owned by BB.
• Security and threat-vigilance capability itself is delivered inside the BB project, where its agents and droids are defined; those are not enumerated here.

Future (on demand)

• BB to publish Vigilance's own architecture (technologies, blocks, team) so this catalogue stub can link straight to it.
• Tighter cross-project linking from this entry to the live BB project surface as it becomes available.

Vigilance has no Carol-side agent-facing tools — it is a BB service tracked here for visibility only.

• To operate or change Vigilance: go to the BB project, which owns the service and its process.
• To find it in Carolverse: this catalogue entry records ownership (BB), external status, and intent — and points back to BB for everything else.