convocantsystems.com

Every privacy promise here is a mechanism you can go and look at.

Agora handles the conversations that happen at recovery-sector meetings. That material is protected more strictly than ordinary health records, under 42 CFR Part 2. The architecture treats that as a design input rather than a compliance afterthought, and the only place that difference ever shows up is in the mechanisms themselves.

So this page names them. Twelve promises, each one stated as the thing in the running system that keeps it, in language that survives being read by your counsel and checked by your engineers. Agora is built for HIPAA and Part 2 environments. That is a claim about how it was designed rather than a certificate, and the limits of what any architecture can do for you are set out in the middle of this page rather than buried under it.

Illustration: nested shells around a lit seam. No participant data.

Twelve promises, and the twelve mechanisms that keep them

Each row names a promise, then the thing in the running system that makes it true, then the identifiers a technical reviewer would look for. Two of the twelve can be shown rather than described, so they are.

  1. Nothing is captured silently.

    Capture cannot begin until the event’s consent posture is satisfied, and the visible recording indicator is bound to the actual capture state rather than to what an operator meant to happen. There is no state in which the system is listening and the room cannot tell.

    consent gate recording indicator

  2. Sensitive content is sealed before it is stored.

    Encryption happens in the application, not only at the disk: AES-256-GCM under envelope encryption, with a separate data key for every record. A database dump yields ciphertext, whether it was stolen, subpoenaed or simply misplaced.

    AES-256-GCM envelope + KMS

  3. Every read passes a deny-by-default gate.

    One policy decision point, which every path to sensitive data goes through. No entry in the matrix means denied, rather than unspecified. The order is fixed: gate, then log, and only then return. It also fails closed. If the policy service cannot be reached the answer is no, because a gate that opens when it is broken is not a gate.

    canAccess deny-by-default fail-closed

  4. Deletion is real.

    Retention windows drive an automatic sweep rather than a reminder to somebody. The sweep crypto-shreds: it destroys the record’s keys, which leaves the ciphertext permanently unreadable by anyone, including us. Deletion becomes a fact about the data that can be demonstrated, instead of a flag on a row that has to be believed.

    crypto-shred retention sweep

  5. Knowledge is preserved first.

    Before any transcript is shredded, a preservation run extracts what the community learned from it, meaning decisions, barriers, commitments and insights, each one carrying the verbatim evidence it rests on, into an archive under the same Part 2 protection as the transcript was: per-record keys, gated and audited access. The sweep refuses to shred without it. Retention is not allowed to cost a coalition its own memory.

    fails closed: no preservation, no shred

  6. The vendor gate is code.

    Every provider integration declares whether it requires a Business Associate Agreement. At runtime the system refuses to send protected data to a provider that has no recorded signed agreement, and a misconfiguration throws where it stands rather than degrading into a quiet disclosure. The paperwork is enforced by the thing the paperwork is about.

    requiresBaa runtime refusal

  7. History cannot be edited silently.

    An append-only audit log, hash-chained with SHA-256, over every sensitive read, capture start and stop, synthesis run, disclosure, retention shred and consent change. Metadata only, never content, so the log itself is not a second copy of the conversation. Verification walks the chain and re-derives it, which means tampering is not merely against the rules; it is arithmetically visible to anyone holding the log.

    sha256 chain GET /audit/verify

    Illustrative entries

    chain unverified

    Press Verify chain to re-derive every hash in this browser.

    Every hash below is a real SHA-256 of the entry shown, computed in your browser. Verify re-derives the chain; tamper alters one entry and re-derives it again. Metadata only, as in the product: sequence, action, actor, hash. No content, no participant, no utterance.

  8. Auditors see the trail, not the content.

    A dedicated role whose entire surface is metadata: who did what, to which record, when. Oversight without exposure, so that reviewing the handling of protected material is not itself another disclosure of it.

    auditor metadata-only

  9. Humans gate every AI output.

    Reports, briefings and extracted commitments are drafts until a named reviewer publishes them. There is no auto-publish path: not behind a feature flag, not for a trusted tenant, and not at three in the morning when a run finishes. Synthesized outputs run a de-identification pass, and a barrier finding is never attributed to a named organization until an analyst has confirmed it.

    draft → in review → published

  10. The public wall is structurally isolated.

    It draws from a separate publishable data path containing only explicitly published, non-sensitive aggregates. There is no route from the wall back to raw capture. This is not a permission that has been switched off. No query exists that could reach it.

    publishable path only

  11. Derived data is as sensitive as its source.

    An embedding of sensitive text inherits that text’s sensitivity, its retention window and its deletion cascade. A vector is not a loophole, and neither is a spreadsheet: an export is a disclosure, and it is logged as one.

    sensitivity inheritance cascade

  12. The rules police the codebase itself.

    Machine-readable constraints gate every change: milestone scope, provider isolation, no secrets in source. On top of that, a dedicated privacy-guardian review examines anything touching capture, storage or disclosure, with the authority to block it. This is the mechanism the other eleven depend on. It is what stops the privacy posture eroding one reasonable-looking pull request at a time as the product grows.

    automated gates privacy guardian

Every mechanism above is architecture rather than configuration. None of it is a setting a customer can be talked into switching off. The milestone-by-milestone status of the capabilities they sit under is on the Agora page.

What engineering cannot do for you

Engineering rules are the technical expression of legal obligations, not a substitute for them. Everything on the page above describes how this system behaves. None of it describes what your organization owes the people in the room, and no mechanism discharges that.

Production deployment requires all of the following, and they are people’s work rather than code’s:

  • Review by counsel practicing in health privacy.
  • A HIPAA Security Rule risk assessment.
  • Executed Business Associate Agreements with every service that touches protected content.
  • Consent language that satisfies 42 CFR Part 2 at the point of capture.

We can tell you what the system does, in as much detail as your reviewers want, and we would rather have that conversation early than late. What we cannot do is stand in for the review.

Nothing on this page is legal advice.

Where a safe path and a convenient one disagree, the convenient one does not get built.

Convocant engineering rules

Bring your reviewers.

The technical briefing is this page written for the people who will ask harder questions than it answers: the data flows, the threat model, the schema, and what we deliberately do not claim.

Request the technical briefing