jonathanwestmoreland.com

Tag: Axon

  • Speaking to Bend City Council About Axon and Police Accountability

    Speaking to Bend City Council About Axon and Police Accountability

    A public comment on police technology, public safety, and accountability.

    This video shows my public comment to Bend City Council regarding two connected concerns: the proposed expansion of Axon police technology and the police response after a bullet was fired into my mother’s apartment.

    My concern is not only whether new policing tools are useful. It is whether the City has strong enough oversight, transparency, auditing, data protections, and accountability in place before expanding police technology contracts.

    The same public safety system that asks residents to trust expanded technology must also be able to respond clearly, urgently, and accountably when a bullet enters someone’s home. That experience shaped why I believe Bend should slow down, ask harder questions, and build stronger safeguards before expanding surveillance or police technology systems.

    Why this matters

    Police technology decisions are not just purchasing decisions. They shape how public safety works, how data is collected, how evidence is handled, and how residents are asked to trust government systems.

    Before expanding Axon or any similar system, Bend should have clear answers about:

    • What data will be collected;
    • Who can access it;
    • How long it will be retained;
    • How searches and usage will be audited;
    • How errors, misuse, or weak responses will be reviewed; and
    • How residents will know whether these systems are actually improving safety.

    Technology can support public safety, but it cannot replace accountability. In fact, the more powerful the technology becomes, the stronger the oversight needs to be.

    Watch the public comment here:
    Speaking to Bend City Council about Axon expansion and police accountability

  • Other Cities Are Already Asking Better Questions

    Other Cities Are Already Asking Better Questions

    Part 8 of the Bend Surveillance Oversight series.

    Bend does not need to invent police surveillance oversight from scratch.

    Other cities are already asking the same basic questions:

    • Who approves surveillance technology before it is used?
    • What data is collected?
    • How long is it kept?
    • Who can search it?
    • Can outside agencies access it?
    • Can vendors change settings or activate new features?
    • Does the public receive annual reports?
    • Can elected officials review the system before it expands?

    That is the important lesson.

    The issue is not whether every city has reached the same conclusion.

    They have not.

    The issue is that communities across the country are realizing that police technology should not expand faster than public oversight.

    Austin: surveillance technology should require public rules

    Austin offers one useful model.

    In February 2026, the Austin City Council passed a resolution called the Transparent and Responsible Use of Surveillance Technology Act, or TRUST Act.

    The resolution directed the City Manager to return with an ordinance regulating the adoption, acquisition, deployment, use, and review of surveillance technology by city departments.

    That matters because it shifts the question from one contract at a time to a broader public framework.

    Bend could take the same approach.

    The public question should not only be whether a single contract sounds reasonable.

    The broader question should be what rules apply before surveillance technology is acquired, expanded, renewed, or materially changed.

    Mountain View: vendor assurances were not enough

    Mountain View, California offers another useful lesson.

    In January 2026, the City publicly stated that it had discovered unauthorized queries and potential access to Mountain View ALPR data.

    The City said Police Department staff had met with Flock Safety leadership about “the security and control of our data,” and said it was “upset and disappointed with how our data was accessed.”

    That example matters because it shows why vendor assurances are not enough.

    The lesson for Bend is simple:

    Do not wait for a data-sharing problem before creating data-sharing rules.

    Pima County: cost and AI concerns can cross political lines

    Pima County, Arizona offers another example.

    Reporting in early 2026 described the Pima County Board of Supervisors rejecting a proposed $45 million contract expansion involving Axon technology and AI tools.

    Reported concerns included cost, AI expansion, and whether the investment made sense for the Sheriff’s Department.

    That example matters because surveillance oversight is not only a privacy issue.

    It is also a budget issue.

    Public safety dollars are limited.

    Every dollar spent on bundled technology, AI tools, cloud subscriptions, hardware refreshes, and add-on features is a dollar not spent somewhere else.

    That does not mean technology is never worth funding.

    It means elected officials should ask hard questions before long-term commitments become automatic.

    Ferndale: public pressure can lead to stronger oversight

    Ferndale, Michigan offers another useful example based on reporting about local ALPR oversight discussions.

    Reporting described residents raising concerns about license plate reader expansion and city officials discussing stronger policies.

    That is important because public oversight often improves when residents ask specific, grounded questions.

    Community engagement does not have to stop technology.

    It can improve the rules that govern technology.

    The pattern is bigger than one vendor

    This is not only about Axon.

    It is not only about Flock.

    It is not only about ALPRs.

    It is not only about body cameras.

    It is not only about AI.

    The larger issue is how cities govern powerful surveillance systems once cameras, cloud storage, software subscriptions, data-sharing, analytics, and vendor platforms become part of public safety operations.

    A city can support public safety and still insist on public oversight.

    Those goals are not opposites.

    What Bend can learn

    Bend can learn at least five things from other cities.

    1. Oversight should happen before deployment or expansion, not after controversy.
    2. Citywide rules are better than one-off contract debates.
    3. Data-sharing limits should be explicit and enforceable.
    4. Vendors should not be the only source of truth about how systems work.
    5. Annual public reporting builds trust without exposing sensitive case details.

    These examples do not prove that Bend has the same problems.

    They show why Bend should adopt safeguards before problems occur.

    Bend can ask better questions now

    Police technology can be useful.

    But useful tools still need rules.

    If other cities are asking stronger questions about surveillance technology, Bend can too.

    The question is not whether Bend should copy another city word for word.

    The question is whether Bend should create its own public framework before future expansions become harder to unwind.

    Better questions today can prevent harder problems tomorrow.

    Further reading

    Series links

  • AI Police Reports and the Audit Problem

    AI Police Reports and the Audit Problem

    Part 5 of the Bend Surveillance Oversight series.

    Police reports are not ordinary paperwork.

    They can shape criminal charges, court proceedings, plea negotiations, public records, insurance claims, disciplinary reviews, and a person’s ability to defend themselves.

    That is why AI-generated police reports deserve careful public oversight.

    The issue is not whether officers should use better tools.

    The issue is whether official police records remain accurate, reviewable, and auditable when artificial intelligence is involved.

    What AI police report tools do

    AI police report tools can use body-camera audio, transcripts, officer input, or other records to generate a draft narrative.

    That may sound helpful.

    Police officers spend a lot of time writing reports, and many departments are looking for tools that reduce paperwork.

    But a police report is not just a summary.

    It is an official law enforcement record.

    If AI helps write that record, the public should know:

    • what information the AI used,
    • what the AI produced,
    • what the officer changed,
    • whether the officer verified every factual statement,
    • whether the original AI draft was preserved,
    • whether errors can be reconstructed later, and
    • whether defense attorneys, prosecutors, judges, or oversight bodies can review the process.

    Without those safeguards, AI report-writing creates a serious audit problem.

    Why the original AI draft matters

    Imagine an AI tool creates a draft police report from body-camera audio.

    The officer reads it, edits it, and copies the final text into the official report system.

    Then the original AI draft disappears.

    Later, a defendant, attorney, judge, journalist, auditor, or oversight board wants to know whether a questionable sentence came from the officer, the transcript, or the AI system.

    If the original AI draft was not preserved, there may be no way to answer that question.

    That is the core problem.

    The concern is not only that AI can make mistakes.

    The concern is that AI mistakes may become embedded in official records without leaving a trace.

    What a basic audit trail should include

    A reasonable AI police report policy should require preservation of:

    • the original AI-generated draft,
    • the body-camera audio or transcript used to generate it,
    • the prompt or settings used,
    • timestamps,
    • the officer’s edits,
    • the final submitted report,
    • supervisor edits if any, and
    • a clear label showing that AI assisted in the drafting process.

    This should not be controversial.

    If AI saves time and improves accuracy, the audit trail should show that.

    If AI introduces errors, the audit trail should make those errors detectable.

    Either way, preserving the record protects the public, defendants, officers, prosecutors, and the City.

    Bend should set rules before using AI reports

    This post does not claim that Bend currently uses AI-assisted police report-writing.

    The point is that AI report-writing is already being marketed to law enforcement agencies, and cities should set rules before these tools become routine.

    Bend should not wait until after AI-generated police reports become common to decide how they should be governed.

    A strong local policy would say:

    1. No AI-generated police report may be submitted without officer review and certification.
    2. The original AI-generated draft must be preserved.
    3. All officer edits must be logged.
    4. The report must disclose that AI assisted in drafting.
    5. Prosecutors must be notified when AI was used.
    6. Defense attorneys must be able to obtain relevant AI drafting records through normal discovery.
    7. AI report tools may not be used for serious incidents unless additional safeguards are in place.
    8. The City must publish annual statistics on AI report use, error findings, officer adoption, and measured time savings.
    9. The vendor may not use Bend data to train AI models without explicit public approval.
    10. The City must independently audit the system before and after deployment.

    These rules would not ban AI.

    They would make AI accountable.

    No AI-generated police report without an audit trail

    Police reports are too important to become black boxes.

    If AI helps write an official record, the original AI output should not vanish.

    Bend residents should expect a simple rule:

    No AI-generated police report without an audit trail.

    Further reading

    Series links

  • Why Vendor Lock-In Matters in Police Technology Contracts

    Why Vendor Lock-In Matters in Police Technology Contracts

    Part 3 of the Bend Surveillance Oversight series.

    In the last post, we looked at the range of police technology Bend has already considered, approved, or discussed: body-worn cameras, fleet cameras, digital evidence storage, Fusus real-time information software, Axon Air drone software, third-party video playback, investigation software, VR training, and automated traffic enforcement cameras.

    Looked at one at a time, each purchase can sound narrow.

    But when the same vendor ecosystem provides the cameras, storage, software, subscriptions, hardware refreshes, training tools, review tools, and add-on features, the City may gradually become dependent on one platform.

    That is called vendor lock-in.

    Vendor lock-in does not necessarily mean anyone did anything wrong.

    It means a city’s systems, data, workflows, training, contracts, and budgets become so tied to one vendor that switching later becomes expensive, disruptive, or politically difficult.

    That matters for public oversight.

    How lock-in happens

    A city might begin with a legitimate need: body cameras.

    Then it needs a place to store the video, so it adds cloud evidence storage.

    Then prosecutors need access, so the system becomes part of the criminal justice workflow.

    Then patrol vehicles need cameras, so fleet cameras are added.

    Then drone video needs to be managed, so drone software is added.

    Then the department wants video review tools, third-party video playback, investigation software, AI tools, or real-time information platforms.

    Over time, what began as a camera contract can become a broad public safety software ecosystem.

    The Electronic Frontier Foundation has warned about this pattern in its article “Beware the Bundle”, which describes how police technology companies can use bundled offerings to become a department’s default provider for more and more tools.

    Again, the issue is not whether any single tool is useful.

    The issue is whether the public understands how the tools fit together before the City becomes deeply dependent on the platform.

    Why bundled contracts are harder to oversee

    Bundled contracts can make public oversight harder for several reasons.

    First, bundles can obscure what is actually being purchased.

    Second, bundles can make costs harder to compare.

    Third, bundles can reduce practical competition.

    Fourth, bundles can normalize expansion through amendments.

    That is how surveillance systems can grow without residents ever seeing a single clear moment where the full policy question is debated.

    Vendor assurances are not the same as public policy

    Cities often rely on vendor statements about what a system does or does not do.

    That is not enough.

    • Vendors can change product features.
    • Software capabilities can be added later.
    • Terms can change.
    • Subprocessors can be involved.
    • Data can be stored in complex cloud systems.
    • Departments can expand use over time.
    • Future renewals can make earlier decisions harder to revisit.

    That is why public rules should not depend only on vendor assurances or internal department practices.

    Public policy should be clear enough that residents can understand the limits before the next expansion happens.

    Why this matters in Bend

    Bend has already considered or approved multiple related technology systems over time.

    That does not prove a problem by itself.

    But it does show why residents should ask how all of these systems connect, whether alternatives were seriously evaluated, and what would happen if the City later wanted different pricing, stronger privacy protections, or more independent technical control.

    Vendor lock-in is not only a procurement question.

    It is also a transparency and governance question.

    What better contract oversight would look like

    If Bend wants useful technology without becoming overly dependent on one vendor ecosystem, contracts should protect the public interest.

    That can include:

    • clear exit clauses,
    • data portability requirements,
    • limits on automatic renewals,
    • public review before major expansions,
    • independent audits of enabled features and system settings, and
    • Council approval before materially new capabilities are activated.

    Those are not anti-technology ideas.

    They are basic governance safeguards.

    The real question

    The question is not whether Bend should use one vendor or another.

    The question is whether Bend has enough public oversight before the technology ecosystem becomes too large, too expensive, and too embedded to easily change.

    Vendor lock-in is not just a budget issue.

    It is a democracy issue.

    When public safety technology becomes hard to leave, hard to audit, and hard for residents to understand, public oversight becomes weaker.

    That is why Bend should address vendor lock-in now, before future expansions become automatic.

    Further reading

    Series links

  • What Police Technology Has Bend Already Considered or Purchased?

    What Police Technology Has Bend Already Considered or Purchased?

    Part 2 of the Bend Surveillance Oversight series.

    Before Bend residents can have a useful conversation about police surveillance oversight, we need to understand what technology the City has already approved, discussed, or bundled into larger contracts.

    This is not about assuming bad intent.

    It is about making the public record easier to understand.

    Over the past several years, Bend has moved from body-worn cameras into a broader police technology ecosystem involving vehicle cameras, cloud evidence storage, drone software, real-time information tools, third-party video playback, investigation software, and bundled Axon subscriptions.

    That is why this conversation should not be reduced to a simple question like, “Should police have cameras?”

    The better question is:

    What systems has Bend adopted, and what public rules govern the data those systems create?

    Body-worn cameras and Evidence.com

    In April 2021, Bend City Council considered a five-year agreement with Axon for body-worn cameras, associated hardware, analytical software, training, and digital evidence storage, with a contract amount not to exceed $1,038,996.

    The City’s issue summary said full implementation would mean every officer would be equipped with a body-worn camera during their shift, video recordings would be stored, and the Deschutes County District Attorney’s Office would have the ability to receive the information.

    That matters because body cameras are not only recording devices. They also create records that must be stored, accessed, shared, retained, and governed.

    Fleet cameras in police vehicles

    In July 2022, Bend City Council approved a five-year, $679,500 contract with Axon for fleet cameras in Bend Police vehicles.

    The City described the contract as covering purchase and installation of cameras, software, and video storage.

    This is important because fleet cameras can be more than dashboard video. Depending on the hardware, software, and enabled features, vehicle camera systems can interact with evidence storage, metadata, automated review tools, and potentially other software capabilities.

    That is exactly why public policy should focus on capabilities, retention, access, and auditing — not just the word “camera.”

    Fusus real-time information software

    In March 2023, Bend City Council considered a three-year agreement with Fusus Inc. for software and associated hardware to view public and community video sources for incident situational awareness and investigations, with a contract amount not to exceed $230,000.

    The City’s issue summary described Fusus as a real-time crime center platform designed to consolidate video and other information sources.

    It said Fusus could bring together public and private video systems, community tips, community text notifications, Computer Aided Dispatch, unmanned aircraft video, Live 911 information, body-worn cameras, in-car cameras, a community camera registry, a CJIS-compliant video evidence vault, and video live links for 911 callers.

    That is a much broader system than a single camera.

    It is a platform for gathering, viewing, and coordinating multiple information sources in one place.

    Axon Air and drone software

    In February 2024, Bend considered additional Axon Air software licenses for its drone program.

    The issue summary said Bend Police had been using Axon Air software since 2022 for drone support and remote viewing capabilities, and that the department wanted additional pilot and drone licenses.

    It also stated that Bend Police had been using Axon services since 2021 as a unified platform to better track deployment, usage, and results of police actions.

    That phrase — unified platform — is important.

    It shows the direction of travel: not isolated tools, but integration of multiple police technologies into one vendor ecosystem.

    2024 Axon bundled contract

    In October 2024, Bend City Council considered a five-year Axon Officer Safety Plan 10 Premium subscription.

    The meeting minutes state that Council authorized a five-year contract with Axon for Taser hardware, virtual reality hardware and software, digital video recorder playback support, and investigation support software, for a total amount not to exceed $2,555,786.51.

    The minutes also identify the new bundled products and services as Investigate Pro, Third-Party Video Playback, and Virtual Reality training.

    This is the clearest example of why residents need a public inventory.

    Once products are bundled together, it becomes harder for the public to understand which tools are active, which are planned, which are optional, and which could be expanded later.

    Automated traffic enforcement cameras

    Separate from the Axon materials, Bend has also moved forward with automated traffic enforcement.

    The City says the program uses cameras to detect red-light running and speeding at various intersections.

    This is a different type of camera program, but it belongs in the same public conversation because it raises the same basic governance questions:

    • What data is collected?
    • Who operates the system?
    • How long is the data retained?
    • Who can access it?
    • What rules prevent secondary use?

    Why this matters

    Looked at separately, each item may sound narrow:

    • A body camera contract.
    • A fleet camera contract.
    • A drone software license.
    • A real-time information platform.
    • A video playback tool.
    • An investigation software tool.
    • A traffic enforcement camera program.

    But viewed together, they show a larger pattern: Bend is building a police technology environment made of cameras, cloud storage, software subscriptions, vendor platforms, and integrated data systems.

    That does not mean the City should abandon useful tools.

    It does mean residents deserve a clear, public inventory.

    The first step toward meaningful oversight is simple:

    Tell residents what systems exist.

    Selected source documents

    Series links

  • This Is Not Just About Cameras

    This Is Not Just About Cameras

    Part 1 of the Bend Surveillance Oversight series.

    Most people hear “police cameras” and imagine a simple device: a body camera on an officer, a camera in a patrol car, or a license plate reader mounted near a road.

    Cameras are a tool of modern policing, but modern policing was never just about cameras.

    They are often part of a much larger technology ecosystem involving cloud storage, evidence management software, artificial intelligence tools, automated license plate readers, vehicle cameras, drones, real-time crime center platforms, third-party vendors, and future software features that may be added after the original purchase.

    That distinction matters.

    A camera records what happens in front of it. A connected surveillance system can collect data, store it, search it, analyze it, share it, and combine it with other systems. Once that happens, the public policy question changes.

    The question is no longer only:

    Should police have cameras?

    The better question is:

    What rules govern the data those cameras create?

    For example:

    • Where is the data stored?
    • How long is it kept?
    • Who can search it?
    • Are searches logged?
    • Can outside agencies access it?
    • Can vendors access it?
    • Can new AI or biometric features be activated later?
    • Does the City Council have to approve expansions?
    • Are residents told when capabilities change?

    These are not anti-police questions.

    They are basic public oversight questions.

    Body cameras, patrol vehicle cameras, and evidence systems can serve legitimate public safety and accountability purposes. But when those systems are connected to vendor-controlled cloud platforms, AI tools, automated license plate readers, and broader data-sharing networks, the public deserves clear rules before the technology expands.

    This is especially important because cities often start with one tool and later add more tools from the same vendor.

    A city may begin with body cameras, then add fleet cameras, then cloud evidence storage, then license plate readers, then drones, then AI report-writing tools, then real-time crime center software.

    Each step may be presented as a small upgrade.

    But together, those upgrades can create a powerful surveillance infrastructure.

    That is why the issue is not just the camera.

    It is the ecosystem.

    Bend residents should not have to dig through dense procurement packets, legal agreements, and technical appendices to understand what surveillance tools are being used or considered.

    The City should provide a plain-language public inventory of police technology systems, including hardware, software, cloud storage, AI tools, third-party vendors, data retention rules, data-sharing rules, audit procedures, and any future capabilities that can be activated through software.

    This does not require the City to abandon useful technology.

    It simply requires public oversight to keep pace with the technology being purchased.

    Before Bend expands police surveillance systems, residents should be able to answer a simple question:

    Are these tools governed by clear public rules, or are we relying mostly on vendor assurances and internal department policies?

    That is the conversation Bend should have now, before the system becomes larger, more expensive, and harder to change.

    Further reading

    Series links

  • Police-Tech Vendors Are Becoming Public-Safety Platforms

    Why platform contracts require ongoing oversight

    Body cameras, TASERs, evidence storage, drones, AI tools, analytics, and report-writing software are increasingly being bundled into long-term public-safety platforms. That changes what local oversight has to look like.

    Core issue: Public agencies are no longer just buying individual police tools. They are often entering long-term platform relationships where today’s contract can shape tomorrow’s data access, AI features, evidence workflows, analytics, storage, integrations, and switching costs.

    Axon is no longer just a TASER and body-camera vendor. Its own Q1 2026 financials show a public-safety platform business built around hardware, software, cloud evidence storage, AI tools, analytics, subscriptions, drones, real-time operations, and long-term agency relationships. Axon reported Q1 2026 revenue of $807 million, up 34% year over year.

    That platform model is showing up in public contracts. Baltimore approved a $153 million Axon agreement for body-worn cameras, TASERs, and other public-safety tools, while some city leaders questioned whether the agreement was the best deal for taxpayers. Savannah approved a 10-year, $27 million Axon agreement. Connecticut State Police rolled out upgraded TASERs, body-worn cameras, AI translation capabilities, VR training, drones, and evidence-management tools as part of a broader modernization package.

    Those examples matter because they show how police technology is becoming a bundle: hardware, cloud storage, evidence systems, report workflows, analytics, AI features, training tools, subscriptions, and future upgrades. The public may hear “body cameras” or “TASERs,” but the contract can also shape data access, retention, search tools, audit logs, and the agency’s ability to leave later.

    Investors have noticed the same shift. Business Insider reported that an Axon pitch at the Sohn conference emphasized AI tools such as automated police-report drafting from body-camera footage. That is a market signal: public-safety data, AI workflows, and subscription platforms are becoming part of the growth story.

    Why the platform model changes oversight

    When a city buys a single device, oversight can focus on that device: what it does, who uses it, and how it is maintained. But a platform is different. A platform can expand over time. New features can be added. Workflows can change. Data can be connected across systems. A contract that starts as a body-camera or TASER purchase can become a broader operational environment for evidence management, report writing, analytics, training, records, drones, and real-time response.

    That does not make every feature harmful. Some tools may improve officer safety, evidence handling, language access, disclosure, or administrative efficiency. But the public needs to understand the tradeoff: each added feature can create new questions about data collection, access permissions, audit logs, retention, vendor access, system dependencies, and whether elected officials will be asked to approve meaningful changes before they happen.

    The safeguard question is not simply “Should the agency buy the tool?” It is also: what future capabilities does this platform make possible, who can enable them, and what public process is required before they are used?

    What local officials should ask before approving or renewing a police-tech platform

    • Feature scope: Which tools are included now, which are disabled, and which can be enabled later without a new public vote?
    • AI and analytics: Are report-writing, transcription, translation, facial recognition, object recognition, predictive analytics, or other AI-assisted tools included or available as add-ons?
    • Data storage: What data enters the vendor’s cloud systems, where is it stored, and how long is it retained?
    • Access controls: Who has administrator access, who can search records, and can access be limited by role, case type, unit, or investigation status?
    • Audit logs: Are searches, views, exports, deletions, administrator changes, and vendor-support access logged in a way the agency can export and review?
    • Vendor access: Can vendor employees access agency data for support, product development, testing, demos, analytics, or AI model improvement?
    • Data sharing: Can outside agencies, task forces, prosecutors, federal agencies, or private partners access the platform or receive exports?
    • Exit rights: If the city leaves the platform, can it export complete evidence records, metadata, audit logs, retention schedules, and chain-of-custody information in a usable format?

    Why it matters for Bend

    Axon-style contracts should be reviewed as evolving governance systems, not static equipment purchases. Council and staff should know which features are enabled, who has administrator access, what data moves into vendor cloud systems, and whether new AI or analytics tools can be added without a fresh public discussion.

    That review should not stop at the purchase vote. A police-tech platform can change through software releases, configuration changes, integrations, add-on modules, and new agency workflows. For major public-safety platforms, the better oversight model is continuing review: regular reporting on enabled features, access settings, audit-log exports, retention changes, vendor access, and any new AI or analytics tools.

    Practical safeguard: Require a quarterly platform change log for major police-tech systems. The log should identify major software releases, enabled or deferred features, AI or analytics tools, search changes, evidence-workflow changes, access-control changes, administrator roles, vendor access, audit-log export capability, retention changes, and new sharing relationships.

    Bottom line

    For public officials, procurement is no longer simply “buying a tool.” It can mean entering a long-term platform relationship where today’s contract shapes tomorrow’s data access, integrations, AI features, analytics, storage, and switching costs. That does not mean cities should reject every new public-safety technology. It means the public rules need to be as durable and adaptable as the technology itself.

    Police technology should be judged not only by what it promises on day one, but by what it allows on day 500: who can search, who can share, who can change the settings, who can audit the system, and who can prove whether the public’s limits were actually followed.

    “No man is allowed to be a judge in his own cause, because his interest would certainly bias his judgment, and, not improbably, corrupt his integrity.”— James Madison, Federalist No. 10 (1787)