Guide

Getting Data Into and Out of CounterAegis

Identity events go into Countersig, content events go into ProvenanceAI, and normalized event payloads go into CounterAudit for sealing and chain verification. What comes out are verifiable proof artifacts for legal, compliance, and regulator workflows.

Two-minute version

Data in: identity + policy data, content + lineage data, normalized event payloads.

Data out: policy decisions and audit trails, provenance registration and verification records, sealed evidence packets and regulator-ready exports.

Mental model: who acted (Countersig) + what changed (ProvenanceAI) + can we prove it (CounterAudit).

What users add, by product

  • Countersig: agent identity config, authentication provider setup, destination allow and deny policy rules, group assignments.
  • ProvenanceAI: content files or hashes for registration and verification, plus optional metadata and labels.
  • CounterAudit: connector_id, org_id, and raw_event JSON payloads for evidence sealing.

Entry points (where data goes in)

  • Browser entry: Countersig frontend, ProvenanceAI frontend, CounterAudit operations dashboard.
  • API entry: ProvenanceAI /api/register, /api/verify, /api/batch-verify; CounterAudit POST /v1/audit/ingest, POST /v1/connectors/register, PATCH /v1/connectors/:connector_id.
  • Integration entry: Countersig and ProvenanceAI export scripts push into POST /v1/audit/ingest; CounterAudit sends closed-loop risk triggers to Countersig at /integrations/counteraudit/debt-events.

Exit points (where data comes out)

  • CounterAudit verification: GET /v1/audit/verify/:packet_id, GET /v1/audit/chain/:org_id, GET /v1/audit/packets.
  • Evidence exports: npm run export:regulator, npm run packet:regulator, npm run verify:bundle.
  • Countersig outputs: policy decisions, audit trails, SIEM streams (JSON/CEF/Syslog).
  • ProvenanceAI outputs: registration records, verification results, lineage and compliance manifests.

CounterAudit ingest, step by step

  1. Connector normalization converts source event format into canonical packet fields.
  2. Deduplication check prevents duplicate packet inflation from repeated retries.
  3. AES-256-GCM sealing encrypts packet payloads using sealing keys.
  4. Hash chaining links each packet to the prior packet for that organization.
  5. Optional RFC 3161 timestamping adds independent time attestation.
  6. Packet is persisted and response returns packet_id and entry_hash.

Quick reference: what to call and when

  • Register agent: Countersig frontend/API with identity + org + auth config.
  • Set policy: Countersig frontend/API with allow/deny and group assignments.
  • Register content: ProvenanceAI /api/register with file or hash.
  • Verify content: ProvenanceAI /api/verify with file or hash.
  • Record event as evidence: CounterAudit POST /v1/audit/ingest with connector_id, org_id, raw_event.
  • Verify packet: CounterAudit GET /v1/audit/verify/:packet_id.
  • Verify org chain: CounterAudit GET /v1/audit/chain/:org_id.
  • Export regulator bundle: npm run export:regulator.

Note: endpoint names can vary by version and deployment profile. Use your deployment API references for the final contract, and use this guide as a user-level flow map.