I just saw this property on OpenStreetMap.

Using the satellite imagery, I can see that it’s now got stuff happening in and around it including a not-mapped soccer field in the top right.

This looks familiar. I look at the history for this node.

I remember this. You can see immediately that it was added by EvanCarroll — me. This is an old psychiatry hospital named HopeBridge that had a ton of scandals. I digitized it after it closed as a disused hospital. Now it’s back, but with a soccer field, presumably with different owners. Nothing new there.

I want to update the listing so I go searching for information on the address “5556 Gasmer, Houston TX 77035.” I can’t find anything. I turn to HCAD. I search there. HCAD lists the owner of the property at 5556 GASMER MANAGEMENT LLC.” They’re intentionally trying to keep this anonymous. Fishy. Not the end of the world but this is sketch.

I search on Google Maps which knows them as “Children first residential care Gasmer.” Interesting. No website in their Google Maps listing. Nothing. What kind of hospital relies on word-of-mouth?

There is a website for Children First Inc. But, it’s not clear it’s the right group. The Google Maps listing is for Children First Residential Care. That website is Children First Clinical Care.

Searching for permutations on that name I was able to find this this PDF, which tells me its Project Name “Children First Residential Care - CFRC - Gasmer”. This confirms the address is still “5556 Gasmer Dr., Houston, TX 77035”.

Doing more research on this I find this case filing, and it says this,

GHIRP has been providing legal services to unaccompanied immigrant children in Galveston and Houston since 2020, when the organization was founded. Since the organization opened, our legal services dedicated to unaccompanied immigrant children have expanded each year. In 2020, we provided direct representation to approximately 35 unaccompanied immigrant children. In 2021, GHIRP initiated services in a newly opened ORR facility in Houston (Children's First Residential Care TX Gasmer), providing KYR presentations, intakes, direct representation, social services, and referrals for children who were released to other jurisdictions. In 2023, GHIRP began providing the same legal services to unaccompanied children in a second ORR shelter named LSSS Upbring Krause Children's Center. GHIRP’s direct representation services dedicated to children who are not in custody have also expanded, from 35 cases in our first year of existence (2020) to now serving approximately 300 clients per year (2025). Currently, GHIRP serves a combined annual number of nearly 1,500 children per year, including approximately 1,500 children detained in ORR custody, approximately 300 children receiving direct representation services per year, 120-150 children receiving social services per year, and approximately 35-50 children receiving pro se assistance per year.

• GHIRP = Galveston-Houston Immigration Representation Project

• ORR = Office of Refugee Resettlement

• KYR = Know Your Rights

It turns out this is one of the detention prisons for unaccompanied kids managed by a contractor for the Office of Refugee Resettlement.

I found a secret kid prison in my neighborhood using OpenStreetMap.

I believe a similar story in 2018 was published about these with Amy Goodman’s reporting.

Unsatisfied with one vague map, the New York Times, put out a second aerial map with even less data and with deceptfully labeled “Cabin on the Flats,” which actually includes all the cabins they’re not showing behind the tree line.

I found their maps to vague; I wanted to do better. I used OpenStreetMap and some quick cross referencing of the Camp Mystic brochures and other news data and I came up with this,

Viola. Now you can see every building. The yellow outline is the flats which is where the campers were. You can see my digitized contributions on Open Street Maps. But here is an image generate from it without any satellite imagery.

Log in if you want to see the total campsite digitized (or most of it anyway).

Now when the news mentions Bubble Inn you can quickly find it. This is the cabin which had all of 13 of the girls which inhabited it swept away in flood waters. You can read more about that in the coverage by the New York Post.

If you want to see both camps together the Camp Mystic Guadalupe River, and Camp Mystic Cypress Lake, then here is a map for you! (Requested in pvmsg)

The highlighted area is the “Cabin on the Flats” of Camp Mystic Guadalupe River. Compare that to the label the NYT placed above.

Here is a copy of the USGS 3D Elevation map of the region. You can see the cabins for the kids are square in the river’s trough.

I overlaid it with the digitized buildings.

Also worth pointing out that there is an extinct creek that some sources show running right through the camp site called Edmunson Creek. This is an overlay on the USGS The National Map Topographic.

For comedy, this is the level of detail you get with Google. If you’re interested to learn more about mapping and how you can contribute, comment below and I’ll write more about OpenStreetMap.

I have follow up to this article where I write about the poor reception I got on r/Texas and my general experiences on Reddit. I have another article about Camp Mystic entitled “Camp Mystic, cabins, and the 100 year flood plane”

Scientific Journal of Objective Truths and Proof 2025:7-7.0.0

• Remote and arbitrary code execution

• Arbitrary file exfiltration

That’s what it does by design. Claude has the ability to read any files on your disk and execute any code that a remote LLM decides is a good idea. They call this “claude-cli”. And while it probably takes the title for my favorite use case of remote code execution, I think we should take the security implications of it seriously.

Solution

Introducing claude-podman finally you don’t have to trust Bezos and Google! Claude podman runs claude code in a rootless podman container which

• Limits the file access of claude-code to

  • The current working directory

  • The claude configuration files

• Limits code execution to node:current-alpine

As a rootless container running as non-root user, claude-podman is a maximally secure way of running claude-code within a container: claude-code can’t even self-update! Even if it gets root, it’s still in a container. And even if it breaks out of the container it only has access to running as a regular process which makes it no more risky than it’s normal deployment mode which everyone except the elite few is likely using.

Find the repo here: https://github.com/EvanCarroll/claude-podman

Scientific Journal of Objective Truths and Proof 2025:5-2.0.0

One such product is the beautiful oauth2-proxy. I found it and loved the interface. I even contributed to solve a bug in the Helm manifest. It supports multiple authentication providers.

After getting everything working with Google SSO, I added an additional provider: the LinkedIn provider I configured a LinkedIn provider with the new configuration format called “Alpha Config.” The configuration took and validated, but I couldn’t see any difference in the login page. The end points also didn’t respond as I would have thought when trying to target a different provider. Turns out, oauth-proxy does NOT support multiple providers at the same time.

The reason for this confusion is because they updated only the configuration file format (Alpha Config) to support multiple providers. They built some future-proofing by making the provider in the new format an array and calling it providers, but they do nothing with the non-primary provider. Ouch. All that work chasing this solution and it’s a dead end.

Nothing in the docs clearly owned this shortcoming. But in this case, it’s very important to document what you can’t do. Especially when your users will expect it. The feature request for Multiple Providers was opened in 2020. It has 63 upvotes. The last PR on that feature landed in 2021. This is probably not getting fixed any time soon. Time to go back to the drawing board.

I submitted a PR to document this, which was since accepted. Hopefully it saves someone a headache.

Scientific Journal of Objective Truths and Proof 2025:4-27.0.0

• Audit the entire server to figure out what’s the hold up

• Guess about what could be a dependency

• Try to delete the thing

  • If that fails, remove associated “finalizers” and try again or restart the process

  • if it succeeds you’re done.

Removing a chart dependency on cert-manager

I had a declared cert-manager as an optional dependency in a helm chart. This worked well when I was just running everything as one app on Kubernetes within that chart, but it apparently violated some conventions with Kubernetes. I went to migrate cert-manager out of the chart and I couldn’t.

My first step was to simply uninstall the chart, and delete the namespace. Ideally, this would be facilitated by helm with a `—purge` command. But everything in Kubernetes is more difficult. Uninstalling the chart and deleting the namespace didn’t work though because the dependency installed crds: a crd is a custom resource. They’re not installed in the namespace, but they’re “maintained by Helm.” Those crds weren’t cleaned up. Cleaning them up is documented, but it’s cute watching agentic AI figure this out the hard way.

● Bash(kubectl get crd certificaterequests.cert-manager.io -o yaml | grep -A5 'metadata:' | grep -E …
      'labels:|annotations:|name:' | head -10)
  ⎿    annotations:
         meta.helm.sh/release-name: ACME
             f:annotations:
               f:meta.helm.sh/release-name: {}

● The issue is clear now. The CRDs are owned by the "ACME" Helm release, which is causing the conflict when you try to install cert-manager in its own namespace.

In fact, one of the ways Claude does this is simple.

kubectl get crd | grep cert-manager

kubectl delete crd certificaterequests.cert-manager.io certificates.cert-manager.io  challenges.acme.cert-manager.io clusterissuers.cert-manager.io issuers.cert-manager.io orders.acme.cert-manager.io --ignore-not-found

That command just hangs… this is where I would be in over my head. Claude tries this next

kubectl get challenges.acme.cert-manager.io --all-namespaces

At this point, I’ll be honest. I don’t even know what this command does. News to me, you can get a challenge to a cert and it’s represented as a crd. From here, it knows it needs to delete the challenge,

kubectl delete challenges.acme.cert-manager.io -n coworkunion coworkunion-prometheus-tls-cert-1-1841491659-3150586538

Will that work? Of course not, because it’s Kubernetes, and it’s too stupid to include a —force flag. Next up, Claude knows it needs to remove the finalizers. Finalizers are hooks that have to return success before a resource can be cleaned up. How does it do that? Maybe there is a convenient flag like kubectl delete —ignore-finalizers that would function like —force but it would be more fine grained? Of course not, it’s Kubernetes. Removing the finalizers on the command line looks like this,

kubectl get crd challenges.acme.cert-manager.io -o json | jq '.metadata.finalizers = null' | kubectl  replace --raw /apis/apiextensions.k8s.io/v1/customresourcedefinitions/challenges.acme.cert-manager.io  -f -

Of course, if any human wrote code like that on the command line they’d be insane so let’s look at it

• kubectl get crd challenges.acme.cert-manager.io -o json

  Get everything about the crd as json. This for reference shows a finalizer for “customresourcecleanup.apiextensions.k8s.io” which is probably what the documentation is referring to when it says,

  If the namespace has been marked for deletion without deleting the cert-manager installation first, the namespace may become stuck in a terminating state. This is typically due to the fact that the APIService resource still exists however the webhook is no longer running so is no longer reachable. To resolve this, ensure you have run the above commands correctly, and if you're still experiencing issues then run:

• jq '.metadata.finalizers = null'

  Remove just the finalizers value from the metadata, effectively deleting the hook. Return the whole documented as JSON.

• kubectl replace --raw /apis/apiextensions.k8s.io/v1/customresourcedefinitions/challenges.acme.cert-manager.io -f -

  This is command like patch, but that focuses on the difference.

Why did it write that in such a way? No idea. It’s probably the same as this,

kubectl patch crd challenges.acme.cert-manager.io -p '{"metadata":{"finalizers":null}}' --type=merge

Which is what I did after I got sick of watching it show off. That removed the finalizer which made possible to delete the last crd.

But you can’t deny that it’s amusing and entertaining see how it solves these problems without reading the docs.

Addendum for the tribal

Just want to reiterate,

1. I knew about the docs before I ran the LLM. This was only to see how it would go about figuring this out as a learning exercise. That note was always in there.

2. This is not abnormal. Most every piece of software that I’ve used is “caveat emptor”. You can remove an rpm ignoring it’s normally blocking hooks with rpm -e —noscripts you can remove a package in Debian that is in an inconsistent state with dpkg --force-remove-reinstreq where normally dpkg would want to reinstall the package thinking that a reinstallation will allow an uninstallation. But sometimes the package needs to be removed in order for an installation to work, and so it’s there!

3. This bug isn’t rare. It’s common. It’s in the *Frequently* Asked Questions for cert-manager.

4. This is not about security. It’s about convenience. I can remove something by manually removing finalizers and dependent resources. If I can do it, there should be a command to do what I’m doing automatically. It’s not complex. The argument here is whether or not it should be convenient.

Take care. Hope you enjoyed the adventure.

Scientific Journal of Objective Truths and Proof 2025:4-26.0.0

A monorepo is a single code repository that contains multiple “projects” which may each be versioned differently1. This is an older way to develop and it remains popular (mostly for cultural reasons) with those that come from pre-git source control management systems, like svn and cvs.

In order to emulate a mono repo we’ll create a sandbox. This sets up a code repository in the directory “repo” which has three projects “foo”, “bar”, and “baz”. Each of these projects have a fresh change log and are versioned to 1.0.0. But because we’re using a monorepo, the version tags are project specific. For example, there are two separate tags for foo-1.0.0 and bar-1.0.0. When viewing the repository at “foo-1.0.0” the code in all other non-foo projects should be ignored.

git init repo
cd repo
git-cliff --init
echo "INITIAL COMMIT" >README.md
git add README.md
git commit -a -m 'initial commit'

for PROJ in foo bar baz; do
(
  mkdir $PROJ
  cd $PROJ
  echo "New readme for $PROJ" >README.md
  git add README.md
  git commit -a -m"Added new project $PROJ"
  git tag "$PROJ-1.0.0"

  git-cliff --unreleased --bump >CHANGELOG.md
  git add CHANGELOG.md
  git commit -a -m"chore($PROJ): git-cliff"
  git tag $(git cliff --unreleased --tag-pattern="$PROJ-.*" --bumped-version)
)
done

As before, this part is key and will remain unmodified generating the chore commit.

git-cliff --unreleased --bump --prepend CHANGELOG.md
git add CHANGELOG.md
git commit -a -m'chore: git-cliff'
git tag $(git cliff --tag-pattern="$PROJ-*" --bumped-version)

Demonstrating a single fix

To demonstrate a single fix, we can use this code

# Single commit test on foo
PROJ=foo
cd $PROJ
echo Short fix >>README.md
git commit -a -m"fix: single commit $PROJ"

git-cliff --unreleased --bump --prepend CHANGELOG.md
git add CHANGELOG.md
git commit -a -m'chore: git-cliff'
git tag $(git cliff --tag-pattern="$PROJ-*" --bumped-version)

Two commits on the same project?

Here we demonstrate two commits on the same project. This kind of thing will happen often in a PR for example, especially when the source is an integration branch.

PROJ=foo
cd $PROJ
echo One more fix >>README.md
git commit -a -m"feat: [1/2] dual commit/single proj $PROJ"
echo Always another one >>README.md
git commit -a -m"feat: [2/2] dual commit/single proj $PROJ"

git cliff --unreleased --bump --tag-pattern "$PROJ-.*" --prepend CHANGELOG.md
git commit -a -m'chore: git-cliff'
git tag $(git cliff --unreleased --tag-pattern="$PROJ-.*" --bumped-version)

Crossing project boundaries in one chore commit

But what if your integration branch crosses boundaries, not a problem. Here is the code that would handle that.

# Create commit
for PROJ in foo baz; do
(
  cd $PROJ
  echo "Dual project fix" >>README.md
)
done
git commit -a -m'fix: dual plugin commit'

# Iterate through project updating changelogs
for PROJ in foo baz; do
(
  cd $PROJ
  git cliff --unreleased --bump --tag-pattern="$PROJ-.*" --prepend CHANGELOG.md
)
done

# Create a chore commit
git commit -a -m'chore: git-cliff'

# Set version tags to that commit
for PROJ in foo baz; do
(
  cd $PROJ
  git tag $(git cliff --unreleased --tag-pattern="$PROJ-.*" --bumped-version)
)
done

You’ll notice here that this is the complex use case for version management in a monorepo. We have to break our pattern substantially, this is because in one chore commit we want

• All the changelogs generated

• All bumped versions tagged

This is only meant to demonstrate an overview of the monorepo functionality of git cliff. Git cliff is actively developed. As always, customizations will likely be required and be sure to read the documentation!

Scientific Journal of Objective Truths and Proof 2025:3-10.1.0

Git Cliff is a tool by Orhun Parmaksız that allows you to automate changelogs and versions. In it’s simplest form it assumes there is one version-number bearing project in a repository. The set up looks something like this,

# Create new repo dir
git init foo
cd foo
echo readme >README.md
git add README.md
git commit -a -m 'initial commit'
git tag 1.0.0

# Git cliff setup
git-cliff --init
git add cliff.toml
git commit -a -m'ci: added git cliff'

git-cliff --unreleased --bump >CHANGELOG.md
git add CHANGELOG.md
git commit -a -m'chore: git-cliff'
git tag $(git cliff --bumped-version)

Now you have a project configured with git cliff, and it’s bumped its first version. After you run those commands, you’ll see two versions tagged and one of them was calculated by git cliff.

$ git tag
1.0.0
1.0.1

And the git log will show your chore commit,

commit a840842e48984fc454b2d673e5bc8d6e94547f3a (HEAD -> main, tag: 1.0.1)
Author: Evan Carroll <me@evancarroll.com>
Date:   Mon Mar 10 18:37:50 2025 -0500

    chore: git-cliff

While there are lots of ways to use git cliff, I believe the best practice is to have

• A separate commit for the files touched by git cliff

• Where that separate commit is the tag point for the new version

In order to achieve this, whenever you want to publish a new commit simply run

git-cliff --unreleased --bump --prepend CHANGELOG.md
git add CHANGELOG.md
git commit -a -m'chore: git-cliff'
git tag $(git cliff --bumped-version)

Note: the only thing that changes in these four lines from the above, is the “--prepend” argument. You can repeat this process for each new commit-cycle

echo "New Code" >> main.rs
git add main.rs
git commit -a -m'feat: added a new pseudo rust feature'

git-cliff --unreleased --bump --prepend CHANGELOG.md
git add CHANGELOG.md
git commit -a -m'chore: git-cliff'
git tag $(git cliff --bumped-version)

And now you’ll see the commit with the new tag 1.1.0

commit 2aeb571078c4ef24022cb5dfba1fbc7eabd6fdfc (HEAD -> main, tag: 1.1.0)
Author: Evan Carroll <me@evancarroll.com>
Date:   Mon Mar 10 18:40:43 2025 -0500

    chore: git-cliff

Monorepos

I have whole entry on just git cliff and monorepos. I highly suggest it but I’m partial. It felt out of place diving into all that detail here.

Other functionality

In all this code we rely on just the defaults of git cliff, which is rather amazing. It has a slew of other cool features. If you’re entertaining adoption I suggest reading about,

• Templating: there is a ton of functionality here. The prebuilt templates are documented in —init. However you can create your own — no Rust required!

• Host integrations (for GitLab, GitHub, and BitBucket)

Scientific Journal of Objective Truths and Proof 2025:3-10.0.0

Aside from a version number, most software is distributed with a changelog. A changelog will tell you — log — what has changed with a new release of software. These changes are tied back to version numbers. Historically programmers describe changes in two places,

• user-facing changelogs.

• commit messages which are only viewable by developers

Despite being conceptually different, for efficiency most simply concentrate change documentation into commit messages killing two birds with one stone. But, we can do better than that. In this article we will kill three birds with one stone.

Recap on Semantic Version

Recall that Semantic Versioning is a standard for version numbers that allows you to compare any two versions and state affirmatively the type of change between them as one of either

• “major” (also known as a “breaking change”): incompatibility with potentially more features and bug fixes

• “minor”: more features and potentially bug fixes

• “patch”: just bug fixes

Automating version management

Let’s assume we have source-control management (SCM) like git. Going back to our,

semvarAfter = bump(semvarBefore, change)

Where change is of type ENUM[MAJOR,MINOR,PATCH].

In order to provide full automation of releases, we have to be able to derive both arguments to bump:

• semvarBefore

  This is easy to determine: version numbers are typically stored in git tags. You can determine the last version by applying the coalition in the Semantic Versioning spec (the standardized sorting order).

• change

  This is the problem: we need a deterministic method to get a value for change by deciding which variant of the ENUM[MAJOR,MINOR,PATCH] represents the changes in code want to publish.

One solution that enables automation is to simply tag each commit with a token that represents the change type.

Enter Conventional Commits

Conventional Commit is one of many standards for tokens, and token placement. The tokens used by Conventional Commits, are

• “BREAKING CHANGE:” For a major change.

• “feat:” For a minor change, abbreviation of “feature”

• “fix:” For a patch level change

Where “type” is our token above.

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

These map directly onto our ENUM[MAJOR,MINOR,PATCH]. With each commit message standardized to use the tokens above, we need only

• Scan all commits from the last published version, to the code we want to publish (typically HEAD). And,

• Track the most significant token identified in the scan

Pseudo-code

change = scanCommits(gitTag, HEAD)

We can return to our original method of calculating the bumped version,

semvarAfter = bump( semvarBefore, change )

And substitute change,

semvarAfter = bump( semvarBefore, scanCommits(gitTag, HEAD) )

This is how Semantic Release paired with Conventional Commits enables automated release management. If you’re already using Semantic Versioning, adopting Conventional Commits is the one stone that kills,

• Versioning

• User-facing changelogs

• Git Commit message standardization

Conventional Commit Scoping

Conventional commits support something called scoping. Which looks like the following (the scope below is lang):

feat(lang): add Polish language

Scoping allows you to develop tooling that reacts differently to changes of different feature sets and projects in your repository. It’s left for the implementer to decide how to use it.

Revisiting changelogs and commit messages

It’s worth revisiting the distinction between user facing changelogs and commit messages. Conventional Commit does not address this distinction. But in practice, most of the changelog-generating tools only make available to the user-changelogs the first line of the commit message. Simply keep that title line (first line of the commit message) succinct and user-focused and place the details restricted to developers in the body below.

Scientific Journal of Objective Truths and Proof 2025:3-7.0.0

• When the major number (x in x.y.z) changes it “represents a breaking change and potentially more features and bug fixes”

  Ergo, an upgrade of this sort can NOT be assumed to be compatible with your code base at all.

• Or, when the major number remains static and the minor number (y in x.y.z) changes it “represents more features and potentially bug fixes”

  Ergo, a higher minor number can be assumed to be compatible but can NOT be assumed to be free of security vulnerabilities nor to be free of additional bugs which may be introduced by the development of new features.

• Or, when the major number and minor number remains static and the patch number (z in x.y.z) changes it “represents solely bug fixes”

  Ergo, a higher patch number can GENERALLY be assumed to neither introduce an incompatibility nor additional bugs nor additional vulnerabilities.

Semantic Versioning has proven to be tremendously useful and it has been the status quo for a very long period of time.

Adopt semantic versioning by making the first public release of your software 1.0.0. Or increment the major number and from that point on, simply follow the convention above.

In practice; developing with Semantic Versioning

To think about Semantic Versioning more formally if any two different semantic versions are compared the result of the comparison is the change between the two versions and can be represented as an enumeration of these three outcomes

• MAJOR: “represents a breaking change and potentially more features and bug fixes”

• MINOR: “represents more features and potentially bug fixes”

• PATCH: “represents solely bug fixes”

change = compare( semvarBefore, semvarAfter )

Where change of type ENUM[MAJOR,MINOR,PATCH].

Further, knowing the semvarBefore and the change whether MAJOR, MINOR, PATCH you can calculate the next valid semvarAfter. This is done normally with a “bump” tool.

semvarAfter = bump( semvarBefore, change )

The bumper tool can be implemented simply:

• When major changes: increment major, clear (set to zero) minor and patch

• Or, when minor changes: retain major, increment minor, clear (set to zero) patch

• Or, when patch changes: retain major and minor, increment patch

When using semantic versioning, a developer will

• take the current version number

• review the changes from that version until the point you wish to publish as a new version to decide which one of the statements above summarizes the magnitude of the changes, and

• hand both the current version and the type of change or bump needed to the bumper

This would provide them their new version number.

Pre-release and build-metadata

There are two advanced pieces of functionality that are very useful and often less well known about Semantic Versioning. Let’s just assume the next version of Ubuntu is 15.0.0

• Want to include something external in your version number like a stupid animal name for your adolescent user base? Semantic Versioning makes this possible with build metadata! Simply suffix the version number with a “+” (plus sign) and one or more dot-separated identifiers. For example, the next version of Ubuntu could simply be.

  15.0.0+puffin.25.04

  • Where “puffin” is the dumb animal name they’re using to market it

  • Where 25.04 is the release date (April of 2025) the version was first provided

  Now they don’t have to drive everyone nuts with “puffin” and “25.04” in random locations. There is no spec on your build metadata. It’s left for you to define and it’s excluded in comparisons and sorting.

• Want to provide a pre-release of your software? Semantic Versioning allows this as well: simply suffix the version number with a “-” (hyphen) and one or more dot-separated identifiers

  • 15.0.0-alpha+puffin.25.04

  • 15.0.0-beta+puffin.25.04

  • 15.0.0-rc1+puffin.25.04

It’s very typical for the build-metadata to include the git-SHA in a repeatable build situation.

Read The Spec!

Semantic Versioning is something you’ll use all the time. The spec is not long — only a couple of pages. It’s useful to read it once. It’s beautiful in its simplicity.

Scientific Journal of Objective Truths and Proof 2025:3-1.0.0

Here is how the world has evolved and how it impacts you.

• Slack now has an official offering called AI Agents. And, they’ve long since allowed Enterprise Administrators to read public messages without you knowing.

  • lurel.io offer products which include “Sentiment Analysis”

  • posipanda offers a service which provides a toxicity and kindness score.

    Identifying Toxic Behavior in Slack: Posipanda aims to foster a positive work culture by identifying and addressing communication challenges.

  • nightfall.ai offers a service to monitor for bullying using AI

• SalesForce already makes use of Toxicity Scoring with LLM and AI, using it’s Einstein Generative AI. It also integrates with Slack.

• Microsoft Teams makes “Sentiment Analysis” so easy, it’s actually in the coding example for a bot.

• Zoom is also playing around with “Sentiment Analysis.”

Remember, at work — especially in a Right to Work state (right to get fired) — you have almost no rights nor expectation of privacy, according to Workplace Fairness

Employers can legally monitor almost anything an employee does at work as long as the reason for monitoring is important enough to the business. Employers may install video cameras, read postal mail and e-mail, monitor phone and computer usage, use GPS tracking, and more.

Operational security is not having conversations in unsafe venues about,

• Your political opinions

• Your pay

• Your opinions of leadership and management

Those conversations shouldn’t be on the company provided communication medium. By all means, reach out and talk to your coworkers. Organize side channels. But don’t make it so easy that you get marked for spreading negativity on things they administer and maintain. Moreover, think twice before endangering a coworker with that. Most can talk about Trump and Biden and be level headed, but what about the one guy that gets emotional? Is it worth being a party to a conversation which can end up hurting those that get too emotional — even if their heart is in the right place?

Let’s say a hothead reaches out and they want to know what you thought of the HR meeting, or their own struggles at the workplace. Sympathizing with them publicly or reinforcing their perspectives gives them a permit to continue to vent on the medium. Why put them in a position to dig themselves into a hole by welcoming that conversation there? It can only ever hurt their career.

When it comes to how you behave at work, assume your employer will act to protect their workplace culture. That’s a valid and fair assumption. Yes, you’re losing out, but for your own sake consider how AI is giving them an edge. A dystopian corporate edge.

Scientific Journal of Objective Truths and Proof 2025:1-28.0.0