feat: add openbark/0001-0006-foundation RFC #5

Open

vishnup wants to merge 5 commits from openbark/0001-0006-foundation into main

vishnup commented

2026-10-24 20:46:18 +00:00

Member

OpenBark RFCs

vishnup added 5 commits

2026-10-24 20:46:18 +00:00

chore: add OpenBark RFCs 0001-0006 90144379a4

OpenBark is an internal assistant for ScottyLabs members and a shared
platform the team builds modules on top of. These six RFCs record its
architecture and the contracts other projects extend it through.

- 0001 System Architecture: four repositories, contracts, MCP federation,
  extension points, trust boundaries
- 0002 Agent: lifecycle, retrieval stage, suspendable runs, verification,
  model allowlist
- 0003 Surface: identity provider interface, roles and permissions, signed
  assertion, chat visibility, approvals, audit
- 0004 MCP Tools: read and write servers, tool classification,
  authentication, consuming a foreign server
- 0005 Knowledge and Retrieval: source connector interface, ingestion,
  hybrid retrieval, typed links, evaluation
- 0006 Actions, Approvals, and Audit: action provider interface, four
  capability classes, lifecycle, idempotency, blast radius

OpenBark reuses Bark's shape, including its separate-repository model, and
consumes Bark's mcp-server as a foreign tool server rather than re-wrapping
campus data. Where it reverses a decision the Bark RFCs argue for, the
reversal is recorded in that RFC's Alternatives Considered section:
pseudonymous identity past the Surface, an unauthenticated read-only tool
server, never logging tool arguments, open model routing, and is_public
chats.

Room booking and mass emailing are specified as capability classes rather
than features, so a concrete provider for either is a follow-up RFC.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

chore: correct reversal count and federation references in OpenBark RFCs 2fc1c5a0e5

RFC 0001 claimed four of its trust boundaries reverse a Bark decision.
Three do: the untrusted-content bullet describes behavior Bark already
has, with only the rule against retrieved text originating an action
being new. The section also presented itself as the consolidated view of
posture changes while omitting two reversals, so it now points at chat
visibility in RFC 0003 and audited write arguments in RFC 0006.

RFC 0002 required "at least one configured tool server" at startup in
production, which RFC 0001 contradicts by making both OpenBark servers
hard dependencies and Bark's mcp-server a soft one; "at least one" was
satisfiable by the soft dependency alone. It also credited RFC 0001 with
all four federation rules, which stopped being true when two of them
moved to RFC 0004 during the deduplication pass.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

chore: state the injection check as intent provenance, not argument text 23c2956fe0

RFC 0002's verification list and RFC 0006's invariant 4 both defined the
containment for untrusted retrieved material as blocking an action whose
arguments "appear only in retrieved content and not in the conversation."
That is a test on argument text, which is the wrong thing to measure: it
reads as though a member's request needs documentary support, and it
would be brittle to implement.

The rule is about where the intent came from. Only a member's own message
may supply the decision to act. Retrieved content may fill in arguments,
such as a date or a recipient group, but may never be the reason an action
is proposed. Both RFCs now say that, and 0006 adds why the check cannot be
left to the approver: a preview manufactured by a document is
indistinguishable from a legitimate one, so approval catches an action
whose details are wrong while only this check catches an action nobody
asked for.

The adversarial evaluations are restated to match and gain a paired set
covering the other direction, so a genuine request is not blocked when a
document supplies part of its detail. A new open question records that the
boundary between intent and detail, including explicit delegation such as
"do what the meeting notes say," must be written precisely enough to
implement before the first write provider ships.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

chore: fix the action lifecycle sequence diagram in OpenBark RFC 0006 65e90a4c63

The return arrows had the Provider replying directly to the Agent,
skipping openbark-actions, which contradicts the architecture: the Agent
reaches a provider only through the MCP server. Returns now go back
through it in both the preview and the execute leg.

The Member also stood in as the approver, which hid the four-eyes rule
that irreversible classes require an approver other than the requester.
An Approver participant is now separate, with the wait between queueing
and approval shown, since it can run to days or to expiry.

The server-side checks stated in invariants 1 and 2 are now visible:
openbark-actions verifies the bearer and assertion before preview, and
resolves the approval reference and re-checks permission and limits
before execute.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Update openbark/0003-surface.md

nixbot/nix-eval evaluation failed

Details

nixbot/nix-build build failed

Details

0b8cdbf522