Bridge Council Schema
The Bridge Council is a protocol, not a product. This document defines the open technical schema so any organization can build it with any tools, any AI provider, and any infrastructure they already own. No vendor lock-in. No subscription hostage. No permission required.
The Core Principle: Protocol, Not Product
The Bridge Council must propagate the way email propagates — through an open standard that anyone can implement. The moment someone builds "Bridge Council™" as a proprietary SaaS product, the concept is captured and propagation dies. The value is in the standard, not the implementation.
This means:
Four Data Types
The entire Bridge Council operates on four types of data. Everything the system collects, processes, and produces falls into one of these categories. Standardizing these four types is what makes the protocol interoperable across any implementation.
1. Context Objects
Any piece of organizational information that enters the Bridge Council system. A Slack message, a code commit, a meeting note, a decision record, a document, an email. The raw material the system synthesizes from.
{ "id": "ctx_20260217_001", "type": "message | commit | decision | document | meeting | email", "source": "slack | github | notion | email | manual", "timestamp": "2026-02-17T18:30:00Z", "author": "person_id or system", "scope": { "team": "engineering-backend", "department": "engineering", "org": "acme-corp" }, "content": "[raw content or reference to source]", "tags": ["blocker", "timeline", "dependency"], "relations": ["ctx_20260215_042", "ctx_20260210_017"], "sensitivity": "standard | regulated | restricted" }
Context Objects are generated automatically by connectors (adapters that read from Slack, GitHub, etc.) or entered manually. The relations field links objects that reference each other — this is how the system builds the semantic graph over time. The sensitivity field enforces regulatory boundaries at the data level.
2. Synthesis Outputs
The processed understanding produced by the Bridge Council at each level. The output of running the question templates against the context objects. This is what people actually read.
{ "id": "syn_20260217_team_backend", "level": "team | department | org", "scope": "engineering-backend", "period": "2026-02-10 to 2026-02-17", "generated": "2026-02-17T19:00:00Z", "model": "claude-sonnet-4 | gpt-4o | llama-3 | any", "sections": { "architect": "[patterns, contradictions, dependencies found]", "translator": "[cross-boundary terms clarified, misalignments noted]", "synthesizer": "[unified state summary, connected pain points]", "sentinel": "[emerging risks, friction patterns, flags]" }, "sources": ["ctx_20260215_042", "ctx_20260212_003", "..."], "challenges": [], // domain liaisons flag disagreements here "propagates_to": "syn_20260217_dept_engineering" }
The sections field maps directly to the four Bridge Council roles. The challenges array is where Domain Liaisons and team members flag "that's not what's happening here" — the validation mechanism that prevents false coherence. The propagates_to field links this synthesis to the next level up, creating the vertical connection between team → department → org.
3. Query Records
Every question asked of the Bridge Council system, by whom, and what was returned. This is the audit trail and the intent-detection surface.
{ "id": "qry_20260217_019", "author": "person_id", "timestamp": "2026-02-17T14:22:00Z", "access_level": "team_member | team_lead | dept_head | executive", "query": "Why was the March deadline set? What constraints drove it?", "response_sources": ["syn_20260210_dept_eng", "ctx_20260108_decision_034"], "scope_accessed": "team + department_synthesis + historical_decisions" }
The Sentinel function reads the query records to detect intent trajectories. Individual queries are normal. Patterns of queries that systematically map competitive intelligence or probe access boundaries get flagged. The query record is also what enables the retroactive semantic graph search — "show me every thread that connects to this information node."
4. Pattern Flags
What the Sentinel detects. Contradictions between teams, emerging risks, anomalous query trajectories, usage death signals, capture attempts. These are the Bridge Council's immune system.
{ "id": "flag_20260217_003", "type": "contradiction | risk | trajectory | usage | capture", "severity": "info | warning | critical", "detected": "2026-02-17T19:15:00Z", "description": "Teams A and B solving same authentication problem independently", "evidence": ["ctx_20260215_042", "ctx_20260216_088"], "scope": "department:engineering", "status": "open | acknowledged | resolved | escalated", "resolved_by": "null | person_id", "resolution": "null | description of resolution" }
Pattern Flags with type: "usage" detect when the Bridge Council itself is dying — outputs not being read, queries dropping, challenges not being filed. Pattern Flags with type: "capture" detect when the system is being co-opted for surveillance or politics. The immune system watches the organism and itself.
Five Architecture Layers
The Bridge Council implementation stack has five layers. Each can be built independently with any tooling. No layer depends on a specific vendor for any other layer.
Adapters that read from existing tools and produce standard Context Objects. One connector per tool: Slack connector, GitHub connector, Jira connector, email connector, Notion connector, manual entry connector.
Connectors are open-source, community-built, and interchangeable. Writing a new connector means building one function: read from [tool] → output Context Object JSON. The library of connectors grows as the community contributes. Nobody owns the connector layer.
Minimum viable: Manual entry only. Someone copies relevant information into a shared document or JSON file. No automation required to start.
Where Context Objects, Synthesis Outputs, Query Records, and Pattern Flags live. This can be anything: a local folder of JSON files, a SQLite database, a PostgreSQL instance, an S3 bucket, an enterprise data lake. The schema defines the data format, not the storage medium.
Requirements: The organization must own the storage. Full export must be possible at any time. No external party holds the data. Backup and degradation protocols are the organization's responsibility.
Minimum viable: A shared folder with JSON files organized by date and scope. Literally a directory structure on a local drive.
The AI that processes Context Objects using the question templates and produces Synthesis Outputs. This is any LLM — cloud API or local model. The schema defines what goes in (Context Objects + question templates) and what comes out (Synthesis Outputs with the four-role structure). Any model that can do this works.
Model switching: Because the input and output formats are standardized, organizations can switch AI providers without losing their Bridge Council history. All prior Synthesis Outputs, Context Objects, and Pattern Flags remain intact. Only the engine producing new synthesis changes.
Minimum viable: Copy-paste relevant context into any AI chat interface. Ask the question templates. Save the output as a Synthesis Output file. No API integration required to start.
How humans interact with the Bridge Council. This can be a custom application, a chatbot interface, a shared dashboard, or a simple document library with search. The interface enforces the access model — showing each person the context objects, synthesis, and historical records appropriate to their scope.
Query routing: When a person asks a question, the interface determines their access level, retrieves relevant synthesis outputs and context objects within their scope, passes the query to the synthesis engine, and records the interaction as a Query Record.
Minimum viable: A shared folder structure where team members can see their team's folder, team leads can see the department folder, and everyone can see the historical decisions folder. Search = Ctrl+F.
The immune system. Runs on the same synthesis engine (any LLM) but with a different question set: instead of "what patterns exist in this team's context?" it asks "what patterns exist in the query records, usage metrics, and cross-scope flags?" It watches the Bridge Council itself for capture, false coherence, usage death, and anomalous access patterns.
Self-monitoring: The Sentinel produces its own Pattern Flags, which are visible to all appropriate access levels. The Sentinel cannot be silenced by any single person because its outputs propagate to multiple levels simultaneously.
Minimum viable: A monthly review where someone reads through the query records and synthesis outputs and asks: "Is anyone using this? Are the outputs accurate? Is anyone misusing access?" The Sentinel function can be a human practice before it's an automated system.
Three Implementation Paths
Every layer has a minimum viable version that costs nothing and requires no new tools. The Bridge Council scales from manual practice to automated infrastructure, and every point on that spectrum is a real Bridge Council.
Context: copy relevant information into shared docs. Storage: organized folder structure. Synthesis: paste context into any AI, ask question templates, save outputs. Access: folder permissions. Sentinel: monthly human review. Cost: $0. Time to set up: one afternoon. This is a real Bridge Council. It's manual, slow, and functional.
Context: connectors auto-pull from Slack, GitHub, etc. Storage: SQLite or PostgreSQL. Synthesis: scheduled API calls to any LLM with question templates. Access: simple web interface or shared dashboard. Sentinel: automated pattern detection on query records. Cost: LLM API usage only ($10-100/month for most mid-size orgs). Time to set up: a few days of engineering. This is a production Bridge Council for organizations with basic engineering capability.
All layers automated, real-time connectors across all organizational tools, dedicated storage with encryption and compliance controls, multi-model synthesis engine with failover, custom query interface with role-based access, automated Sentinel with real-time pattern detection and alerting. This is what a 500+ person organization builds when the Bridge Council becomes critical infrastructure. Can be built in-house or contracted — but the schema remains open and the data remains theirs.
Anti-Capture Design
The Bridge Council protocol is designed to resist capture at every level — commercial, political, and technical.
Commercial capture resistance: The protocol is open. The schema is published. The connectors are community-built. Any organization can self-supply without paying anyone. Commercial services can offer convenience (managed setup, hosted infrastructure, premium connectors) but can never offer capability that the open protocol doesn't provide. If a vendor disappears, the organization's Bridge Council continues unchanged. The data is theirs. The schema is public. They switch vendors or self-host.
Political capture resistance: Synthesis outputs propagate to multiple access levels simultaneously. No single person can intercept, filter, or redirect the council's outputs. The Sentinel watches for co-option. The historical transparency flows bidirectionally — leadership is seen by the system the same way teams are.
Technical capture resistance: Model-agnostic synthesis means no AI provider can hold the organization hostage. Storage-agnostic data means no database vendor can lock them in. Connector-agnostic input means no workplace tool is required. Full data export is a core requirement, not a feature. Vendor lock-in is architecturally impossible because every layer is interchangeable.
The economics of an open protocol: Commercial services can exist on top of the Bridge Council protocol the same way email hosting services exist on top of SMTP. Gmail doesn't own email. Fastmail doesn't own email. A managed Bridge Council service doesn't own the Bridge Council. The organization can always leave because the protocol is open and the data is theirs. This is the only business model that allows the concept to propagate without being captured.
Adoption Economics
The Bridge Council must be worth it from day one with zero financial commitment. Not "free trial." Actually free. Forever.
The schema is open. The connectors are open. The question templates are published in the Operating System document. The synthesis can run on any AI tool including free tiers or local models. A team that runs the question templates weekly using a free AI chat and stores the outputs in a shared folder is already running a Bridge Council.
The value isn't in the tooling. The value is in the practice. Asking the right questions across the right boundaries at the right cadence — that's what creates coherence. The tools are interchangeable. The practice is what matters.
This means adoption has no gate. No procurement process. No enterprise sales cycle. No pilot program approval. A single team can start tomorrow. They don't need permission from their organization. They don't need budget. They need a shared folder and the question templates. If it works — and it will — it spreads. Other teams adopt it. The department notices. The pattern propagates upward exactly the way the operating system describes.
Bottom-up adoption is the design. Not top-down mandate. The Bridge Council proves itself at the team level before anyone in leadership has to decide anything.
The Bridge Council is a protocol, not a product.
Four data types. Five architecture layers. Three implementation paths. Zero vendor lock-in. Full data sovereignty. Open specification. Free forever.
The concept propagates through adoption, not through sales. The schema is published here. The question templates are in the Operating System document. The blueprint is in the companion document. Everything an organization needs to start — from a single team running manual synthesis to an enterprise deploying full infrastructure — is open, free, and theirs.
The organizations that build the Bridge Council will own their own coherence. Not rent it. Not subscribe to it. Own it — the way you own a practice, not a product. That's the only model that lets this scale to every organization that needs it. Which is all of them.