Bind ideas to evidence.
Use our open-source library of government meetings and records to create shareable artifacts.
About OntologyFeed →PUBLIC LIBRARYBind ideasto evidence.Use our open-source library of government meetings and records to create shareable artifacts.Studio is an early demonstration of OntologyFeed, an open-source system being built to let people create their own applications around connected information, reusable tools, and work supported by evidence.→↗Starting with Virginia · An independent OntologyFeed previewTHE PROJECT BLOGLatest from the blogRead the blog →Guides, examples and updates.Read the OntologyFeed blogCOMMUNITY WORKBrowse shared artifactsBrowse shared artifacts →Public work shared by its authors. Adapt an editable copy when the author permits reuse.Browse shared artifactsSOURCES BECOME USEFUL WORKThe same collection supports research, video editing, and legislative drafting. Bring them together in a project, with the original records close at hand.01 / VIDEOBrowseFind meetings, read available transcripts and explore Virginia law. Recordings and transcripts vary by collection.Browse records →02 / LEGISLATIONVideo EditorChoose transcript passages, check their timing and arrange clips from available recordings.Make a video →03 / CONNECTED WORKBill DrafterDraft amendments and new provisions for the Virginia General Assembly using Virginia Code text and available earlier proposals.Draft a bill →BROWSE BY COLLECTIONThe archive brings together state and local government meeting systems, including Virginia House and Senate recordings and local collections across Richmond and Hampton Roads. Virginia law and legislative records support the drafting workspace.Recordings, transcripts and word timestamps vary by collection.Browse all recordsFREERead the getting-started guide →Bring in a source.Browse records and use the editors without an account. Guest work is temporary.Build your project.Export an artifact file to keep a separate copy.Review and export.Check your bill preview or clip timing, then use the available export controls. Keep a JSON copy to continue editing later.PLANNED MEMBERSHIP$7 USD/monthSave and share artifacts, with server rendering when available. Paid access is planned.About accounts and rendering →Browse recordsOpen an editorAn archive you can build on.Explore meeting recordsFreeOntologyFeed Studio — Government records and video clipsBrowse government meetings and transcripts, make video clips. Explore for free, with account saving and video rendering planned at $7/month.GuideSource packagesEditorsBlogShared artifactsAccountOntologyFeed StudioA working preview of OntologyFeed.GuideEditorsIndependent of the Virginia General Assembly and the official Legislative Information System.STATE & LOCAL GOVERNMENTMEETING RECORDINGS & TRANSCRIPTSVIRGINIA LEGISLATIONSHARED WORKOne collection. Connected work.ILLUSTRATIVE PROJECTFrom hearing to proposalResearch → draft → explainNOTESStart with the question.What did the committee discuss, and what could change?BILL PROVISIONDraft against a source.Keep the selected Code text alongside your proposed amendment.MEDIA SEQUENCELet the meeting speak.Select passages, check the timing, and arrange your clips.Original sources stay unchanged.THE IDEA BEHIND ONTOLOGYFEEDOne collection of information. Many ways to build on it.Government records can support a meeting archive, a video editor, a legislative drafting tool, or an application someone else hasn’t imagined yet.OntologyFeed is being built to make those combinations possible. Sources preserve information and its origin. Reusable tools provide capabilities. Artifacts combine writing, media, and supporting evidence into work people can share and build upon.Studio demonstrates that approach with Virginia government information. The full OntologyFeed system will extend those principles to applications people can build, operate, and share themselves./studio-workspace.jpgIllustrative Studio workspace with a proposed bill provision beside synthetic source text.An illustrative Studio project, using synthetic source material. Notes, bill provisions, and video share one workspace.Open the Studio workspaceONTOLOGYFEED, IN PREVIEWSearch meetings and transcriptsSearch meetings and transcripts/homepage-meeting.jpgJoint Commission on Technology and Science meeting, October 8, 2026.Joint Commission on Technology and ScienceOctober 8, 2026TranscriptUm we want to welcome you to the joint commission on the um full commission of the Joint Commission on Technology and Science.shownshownshownshownhiddenshownVirginia legislative meetingsGeneral Assembly committees, commissions and interim studies./browse?observatory=virginia-legislative-observatoryGreater RichmondCity and county meetings in the Richmond region./browse?observatory=greater-richmond-government-archiveHampton RoadsCity and county meetings in the Hampton Roads region./browse?observatory=hampton-roads-government-archiveshownshownshownshownshown/homepage-meeting.jpgA public JCOTS meeting used in the video editor.Um we want to welcome you to the joint commission on the um full commission of the Joint Commission on Technology and Science.Example passage · October 8, 2026/workspace/video/homepage-bill.jpgVirginia bill editor with source law and a draft provision.Illustrative amendment in the live editor · Code § 2.2-3700./workspace/billshownshownshownshownRetry postsNo posts published yet.MORE FROM ONTOLOGYFEEDshownshownRetry shared artifactsNo shared artifacts yet.shownACCESS AND USEshownshownshownshownBrowseOntologyFeed Studio homeshownFROM THE BLOGFrom OntologyFeedUpdates, guides, and examples from OntologyFeed./blogRead the blog →shownAbout OntologyFeed →/aboutArticle PublishershownChoose an editorCreate a video artifactChoose a starting point for your bill.VideosBillsStart an article.Write with text blocks, preview your article, and share it when you are ready.Open article publisher →Code sectionsPrevious billsSearch meeting titlesFind Code sections by number or headingFind bills by number or titleFind one or more Code sections to amend. Choose the publication you intend to use.AreaFiltersSearchFinding records…RetryAvailable starting sourcesTranscript needed to edit.No matching records in this selection.Source pagesPreviousNextmeetings selectedsources selectedReview selectionRemoveOpen video editor →Open bill drafter →FROM THE BLOGSHARED ARTIFACTSSecurity and your dataHow OntologyFeed Studio runs, where your work is stored, which services are involved, and how saving, sharing and export work.Understand what stays in your browser, what reaches the server, and what becomes public.In your browserGuest drafts are temporaryWithout an account, your draft stays in memory for the current editor page. Leaving or reloading clears that session. Export JSON if you want an editable copy. Browsing records and requesting media still contacts the relevant services.Signed-in editing can keep local copiesSigned-in editing can keep project data and pending recovery copies in browser storage, separately from server saves. Server-side project encryption does not cover these browser copies. Use a trusted browser and device for private work.Browser MP4 export runs on your machineYour browser reads clip media directly from R2, encodes the video on your computer and writes the MP4 to the location you choose. The application handles metadata requests. Account saving is a separate operation.On the serverAccount and session recordsAccount information, password hashes, sessions and membership references are held in application-level databases, separately from private project content.Separate database for each projectEach saved project has its own SQLite database. Your account also has a repository database that keeps its project index and wrapped encryption keys. Clips and bill provisions are parts of a project, not separate databases.Private content is encryptedPrivate project content and retained versions use AES-256-GCM encryption. The server can decrypt that content to provide the service. This is not end-to-end encryption.Public government records stay separateSource databases are independent of account and project storage.Public records and transcripts are read through a separate SQLite source service. Source videos live in media storage. Adding an excerpt to a project does not make the original record private or change the source database.How video movesOriginal viewing, clip media and your exported file follow different paths.YouTube viewingWatch the original meeting with its synced transcript using the YouTube player.R2 clip mediaClip previews and browser exports read MP4 media directly from Cloudflare R2.Encode in your browserYour computer processes the selected clips and encodes your MP4. Keep the page open until it finishes.Download your MP4You control the downloaded file. Downloading does not remove any saved project or existing server output.Server exports use a persistent job queue. Unlike a browser export, an accepted server job can continue after you close the editor. The steps below explain acceptance, waiting, processing and delivery.Sharing is your choiceSaved projects start private. You choose what becomes public.Private account savePublic release by linkSharing publishes a released snapshot. Anyone with its link can read that public version, including an unlisted release.Optional discovery and reuseListing an artifact makes it discoverable in Browse. Permission to make an attributed editable copy is a separate choice.Your private working draft, its public release and other people’s copies are separate. Withdrawal cannot recall copies already downloaded or reused, and previously issued media links can remain usable until they expire.Services involvedThese services handle specific parts of Studio. Billing, hosted email and analytics depend on the installation’s configuration.ServicePurpose and information involvedYouTubeOriginal playback and thumbnails send requests from your browser to YouTube and its video/image services.Cloudflare R2Delivers source MP4 media to your browser. Public archive media is separate from owner-private server-rendered outputs, which use time-limited delivery links.StripeWhen billing is enabled, Studio sends your account email and billing references to Stripe. Payment details are entered on Stripe’s hosted checkout pages.Cloudflare email and VPS inboxesVerification and password-reset messages are sent through Cloudflare’s authenticated SMTP service from accounts@preview.ontologyfeed.org. Cloudflare processes the recipient address and message. Replies go to the existing admin@ontologyfeed.org inbox on our VPS mail service. Disposable tests use a private local mailbox instead.Self-hosted GoatCounterGoatCounter is the selected self-hosted public-page analytics service. Selected counts can include a referrer hostname, browser user agent and screen width, not editor draft content. The sender honors Do Not Track and Global Privacy Control. Studio requires its own provisioned site and scoped credentials; the status below describes this installation.Storage and encryption detailsPrivate project content, retained evidence and protected index projections use authenticated AES-256-GCM envelopes with wrapped keys. The SQLite files are not encrypted in their entirety: identifiers, timestamps, indexes and account records are not all covered by project-content encryption. Browser recovery copies, public releases and downloaded files are separate from that protection.Cookies, recovery and operational logsBetter Auth manages sign-in and password verification. Session cookies keep you signed in; hosted HTTPS uses secure cookies. Signed-in browser storage can retain editing and recovery data, which is not encrypted by the server’s project-content keys.Request throttling temporarily uses client network addresses. Built-in metrics summarize request counts, latency and traffic; application diagnostics use identifiers and statuses. Hosting proxies and external services can keep their own access logs. Log retention depends on the deployed configuration.Use the guides for editing and export, or open Account to manage sign-in and membership.Read the guidesAccount settingsWhen you request a server exportA request becomes queued only after the server accepts it and returns a job identity. A busy or rejected request has not entered the queue.Submit and validateThe server checks your verified account, membership, source timing and configured job limits. Busy or rejected requests show an error or retry state; your draft remains available.Accepted into the queueThe accepted job stores a snapshot of the requested sequence in the persistent SQLite queue. Later draft edits do not change that job. Once acceptance is confirmed, you can leave the page.Wait for an available workerAn authorized worker claims the job when capacity and queue policy allow. Queued means accepted and waiting, not actively encoding. The interface shows job status and progress when you return.Render the accepted snapshotThe worker validates the selected sources, reads the required media and uses FFmpeg to produce the video. This processing uses server resources rather than your browser.Store the private resultA completed output is stored in owner-private R2 storage and associated with the job. It is separate from the public archive originals and from your editable project.Return to history and downloadOpen Render history to check the result. The app checks current access before issuing a time-limited download link. Downloading creates another copy; it does not remove the saved job or output.You can request cancellation while a job is queued or running. A running worker must receive and finish handling that request; cancellation is not an immediate recall of an already downloaded result.If a worker stops reporting progress, the job can become interrupted. Retries are explicit, not an automatic promise of completion. Check Render history before submitting another export, especially after a connection failure where acceptance is uncertain.How the application runsThe interactive editors use React; public reading pages are server-rendered. Node.js handles accounts, project storage and metadata requests. A separate read-only SQLite service supplies public source records. Browser MP4 export uses WebCodecs and MediaBunny; requested server exports use FFmpeg workers. Record acquisition and transcription are separate operator processes.shownshownshownshownshownshownshownshownshownAbout OntologyFeed StudioAbout OntologyFeed Studio, its guides, project updates and security.Bind ideas to evidence.An open-source library of government records for creating shareable artifacts.GuidesAbout the projectStudio is the authoring application for OntologyFeed. Create artifacts that connect ideas to public evidence.It connects public source evidence with authored artifacts, so ideas stay connected to their sources.Security and your workFrom the blogNo published posts yet.View all postsshownshownshownArchitecture and dependenciesHow OntologyFeed Studio is built, its data boundaries and its locked software dependencies.The application structure and software versions behind OntologyFeed Studio.In your browserReact powers the interactive editors. Source viewing uses the YouTube player, while clip previews and browser MP4 exports read media directly from R2. WebCodecs and MediaBunny encode browser exports on your computer.Application serverNode.js handles authentication, membership, private project storage and metadata requests. Better Auth manages accounts. Private projects have per-artifact SQLite files and an owner repository index. A persistent queue assigns requested server renders to FFmpeg workers.Public sources and mediaA separate read-only SQLite service supplies public records and transcripts. Source-package acquisition and transcription are separate operator processes. R2 stores media; public archive originals and private rendered outputs have different access paths.How the application runsPublic reading pages are server-rendered. Interactive editors use React alongside specialized playback controllers for YouTube and transcript synchronization. Metadata requests go through the app to the separate SQLite reader. Private project reads and writes use a bounded background worker. Server renders run independently through the persistent job queue, with worker leases, progress reports and cancellation. Browser encoding remains on the visitor’s computer.Separate responsibilitiesBrowsing reads public records. Editing changes a project. Saving, publishing, browser encoding and queued server rendering are separate operations. Public source readers and acquisition jobs can evolve independently of account and project storage.Locked dependency inventoryVersions below are generated from the committed package manifests and npm lockfile. The inventory includes optional and platform-specific entries; it does not claim every listed package is loaded by every page or installed on every host.Architecture and dependenciesChoose meetings, select transcript passages, and arrange clips into one finished video artifact.
Loading meetings…
ACCESS AND USE
FREE
Free
Browse records and use the editors without an account. Guest work is temporary.
Export an artifact file to keep a separate copy.
PLANNED MEMBERSHIP
$7 USD/month
Save and share artifacts, with server rendering when available. Paid access is planned.
About accounts and rendering →FROM THE BLOG
Latest from the blog
Guides, examples and updates.
No posts published yet.
SHARED ARTIFACTS
Browse shared artifacts
Public work shared by its authors. Adapt an editable copy when the author permits reuse.