A structured-output prompt that demands one citation per claim will fabricate a citation when the model has nothing to cite — because the schema gave it no legal exit. The answer is an escape vocabulary: INSUFFICIENT_CONTEXT, SOURCE_UNAVAILABLE, UNABLE_TO_VERIFY. A model that can return any of those will not invent a source to avoid breaking the contract. That design decision sits at the center of this build. A briefing tool's failure mode is not a missing feature — it is a confident wrong brief someone acts on.
Starting point
This started as a Genesis idea surfaced in June 2026 — a decision-of-record system, not another AI search interface. The category exemplars we worked from were Glean and Dust: both show what connecting an organization's sources and delivering cited answers looks like in practice. Neither was the product we set out to build. Glean is a general-purpose enterprise search box; the cited answer lands in a chat interface and stays there, with no durable record of what informed the decision. Dust brings the same cited-output ergonomics in a general assistant frame with the same gap. The target we worked toward is narrow: the world already has tools that gather context and answer with citations, and the world already has tools where humans type decision records after the fact. Briefcrew is the attempt to automate the second step using the output of the first.
The editorial direction came early and shaped everything after it: calm, trustworthy, editorial. A brief should read like a well-sourced memo — decision-grade, not a flashy chatbot. That framing settled the design system (Playfair Display and Lora, a dark-red primary on paper white, flat surfaces, no shadows) and it settled the architecture: one cited brief per trigger, not an open-ended chat interface. The design direction we chose had never been calibrated on a real build before; the design fidelity pass at the end of the pipeline was its first validation. It cleared twenty-two of twenty-two routes without a violation.
Reading the market
Glean is the dominant general enterprise search product, praised for retrieval speed and breadth across 2026 G2 reviews. The consistent complaint in that review set is specific: hallucinations in chat mode, results too broad, pricing that compounds opaquely at scale. The hallucination complaint is the one that matters — answers are not always trustworthy. That is the market signal the build works from.
A boundary worth naming: AI governance platforms (Credo AI, IBM watsonx.governance, Holistic AI) document the AI system's own behavior — a compliance record of how the tool operated. Briefcrew documents the human decision the AI system helped inform. Buyers arrive conflating the two; the distinction is load-bearing for anyone facing an audit. Meeting-notes tools — and Notion AI, which already extracts decisions — are a different product entirely: they transcribe and flag, they do not gather and synthesize before the decision.
The gap the build targets sits between two product categories that have not intersected: the cited-context-gather side, where Glean and Perplexity Enterprise both deliver retrieval, and the decision-record side, where decisionlog.ai, Cloverpop, and incident.io ship immutability and provenance trails but expect a human to author the record. On pricing, the field runs from a cheap AI assistant floor that Briefcrew deliberately positions above, through a general agent-platform mid-tier, to an enterprise-search tier that carries significant seat minimums alongside its accountability value proposition. The product's own plans are DB-driven and re-priceable by the buyer from the admin panel.
The buyers with the strongest pull toward a product in this category are wherever "what did we know when we decided X, and where did it come from" is a purchased requirement — someone loses a job, fails an audit, or faces legal exposure without the answer. Incident response and SRE teams under SOC2 and ISO 27001, board and executive governance under SEC Item 106 and SOX, and finance and legal functions under GDPR Article 22 all sit in that position. EU AI Act record-keeping obligations are raising category attention, though Article 12 covers high-risk AI systems' own logs, not business decision documentation — the boundary is worth stating because buyers conflate the two.
The decisions that shaped it
The citation chain the product ships has four layers, not one.
At the model layer: the system prompt carries both a per-claim [cite:N] contract and the escape vocabulary — INSUFFICIENT_CONTEXT, SOURCE_UNAVAILABLE, UNABLE_TO_VERIFY — as permitted responses when context is thin. Without the escape vocabulary, a schema that demands citations produces fabricated citations: the model is given no legal way to say it doesn't know, so it invents a source rather than break the contract. The escape words are the exit door. A fabricated citation in a decision record is not a UX failure — it is a reputation-ending event for a product whose entire value is accountability.
Below the model: if semantic retrieval returns zero document chunks above the 0.70 cosine threshold, the language model is never called at all. The pipeline sets status to refused_insufficient_context, generates a structured refusal server-side, writes the immutable record, and delivers the brief as a documented "we had nothing to go on." The refusal joins the permanent record. The decision that there was insufficient context is itself traceable and durable.
Above the model: a server-side scan runs after synthesis and before the brief is committed. Any claim that arrives without a valid [cite:N] marker is dropped. The model is asked to comply, and then checked. Non-compliance costs the claim, not the brief — an unsourced sentence is deleted, not published.
The surviving claims become citations. cite.ts resolves each [cite:N] to an inline [S{N}] marker plus a citation_map JSONB entry carrying source type, source title, excerpt, connector, and the timestamp when the source was read. The reader of any brief can see precisely what document was cited, which integration it came from, and when it was fetched.
The records that result are immutable by three independent mechanisms. A row-level policy forbids UPDATE outright. A BEFORE UPDATE trigger raises an exception on any update path before it reaches the row. No PATCH, PUT, or DELETE handler exists in the codebase; it was never written. The decision_records table carries no updated_at column — the schema refuses to model revision. Status changes (archive, resolve, reopen) append to a separate decision_events table; the original record is never touched. This was verified live: an org-admin PATCH request to decision_records returns 200 with zero rows changed and the value unchanged. A delivery link can point to the record before the record is inserted, because the record ID is pre-generated and the delivered_at timestamp is written at insert — no post-insert update is ever needed, and immutability is preserved.
The connector architecture follows from the trigger model. On-demand briefs have a requesting user. Scheduled and event-based briefs do not — a cron job has no auth context. A per-user OAuth token model breaks the moment a scheduled trigger fires with no active user. Connector credentials are therefore org-level: one shared token per source per org, encrypted AES-256-GCM, connected by an org admin and never stored plaintext. V1 ships Slack via bot token install and Notion via internal integration API key as live connectors. Google Drive and Gmail were evaluated and deferred — Google's sensitive-scope verification runs two to six weeks for new multi-tenant applications, with additional timelines for restricted scopes. The connector order was set by what could ship without waiting on a third-party review queue.
Brief synthesis runs asynchronously via a message queue. Retrieval and synthesis take thirty to ninety seconds, which exceeds serverless function timeouts. The endpoint acknowledges the brief generation request immediately — returning a brief ID and queued status — enqueues the job with a deduplication ID, and a separate consumer handles retrieval through record commit. The trigger layer ships three modes: on-demand from the brief-generation page, scheduled via org admin configuration, and event-based at the Business plan tier. Double idempotency — a uniqueness constraint on the scheduled task plus a queue-level deduplication ID keyed to the trigger and date — guards against duplicate briefs from re-fires.
What fought back
The retrieval architecture was not planned as a pre-indexed vector store. It was forced by a third-party constraint. Slack's conversations history API is capped at one request per minute for new non-Marketplace applications — a limit that has been in place since May 2025. A brief drawing on five Slack channels would spend five minutes retrieving before synthesis began. Scheduled pre-indexing became mandatory: connector sync populates a vector store on a schedule, each chunk tagged with its source, connector, and fetch timestamp. A rate limit in someone else's API decided the core retrieval design.
The Notion connector shipped with a documented limitation. V1 uses an internal integration API key, which gives access only to pages explicitly shared with the integration — not the full workspace. A multi-tenant deployment that wants workspace-wide access needs OAuth public integration, not an internal key. The research identified this as a live tension during planning. The build decision stood, and the constraint is surfaced in the product's connector setup help text.
The citation model remains an open question. There is no definitive benchmark for how reliably any given language model follows per-claim citation contracts — whether it places markers correctly and returns the escape vocabulary when context is thin rather than inventing sources. The synthesis model ID is configurable from the platform's settings table, not hardcoded, for two reasons: a model endpoint went stale during development (a previously working model version returned 404), and the right model for citation faithfulness has not been established empirically. The dual embedding provider (OpenAI text-embedding-3-small as primary, OpenRouter as fallback) follows from the same instability concern — both resolve API keys from the platform settings store rather than from environment variables.
What shipped
Briefcrew ships as a complete multi-tenant decision-of-record platform: Slack and Notion as live context sources, a per-org vector store with HNSW indexing and per-plan chunk caps, a grounded cited synthesis engine with pre-LLM abstention and server-side uncited-claim scanning, cited brief delivery to Slack and email, and every result — including documented refusals — committed as an immutable decision record. Three trigger modes are active at launch: on-demand, scheduled, and event-based at the Business tier. Row-level security enforces the org-admin and member role split throughout — admins see all records in their org, members see their own. Zero unwaived security findings shipped; auth guards were verified on every authenticated segment with real per-role credentials.
A buyer who deploys Briefcrew runs it on their own domain, against their own LLM and embedding keys, on their own database. Per-tenant connector tokens are connected by each org's admin at runtime. The accountability artifact is a byproduct of the brief, not a second thing someone has to remember to write. Three DB-driven plans ship with the build and are re-priceable by the buyer from the admin panel.