Bernette B70 Threading v/s Tension

I got an embroidery machine – found an amazing deal because it was a “holiday” bundle with CDs of Christmas designs. It’s basically the November 1st Halloween candy of embroidery machines. As most machines do, it came with a sample from quality control testing the machine. It works. Except I could not get the thing to work! The bobbin thread was used *all* of the top pattern. The top thread was barely used. Everything I found online said you threaded it wrong. Don’t muck with tension settings, you absolutely threaded it wrong.

I couldn’t tell 100% that I didn’t thread it wrong. At the pretension section, there’s a tab that I had the thread “pinched” into — maybe that was wrong (although not pinching the thread in there and having it on the left hand side didn’t work any better). I spent hours yesterday re-threading the machine. I re-threaded it again and again today. I finally found a video on YouTube of someone who provided detailed instructions on what threaded right means. Turns out I was threading it right.

So, even though all of the advice online is to not touch the tension and just thread it right, I decided to adjust the tension. Can always move it back. It’s a digital control. I can return it to ‘4’ readily enough. Voila – my machine actually embroiders.

Ribs and Smoked Eye of Round

Two racks of ribs (one with mustard binding + crushed hot pepper, salt, and pepper wrapped with maple syrup; the second with just salt and pepper wrapped with apple cider vinegar) and a full eye of round (~7 lbs) split in half and coated with salt and pepper) were smoked at about 225F for hours. Combination of cherry, apple, and pear woods. Ribs were wrapped when they got to 165F and cooked to 205F. Beef was smoked until 125F, came up to 132F resting.

We prefer the wrap with maple syrup. It gets caramelized, sticky, and sweet. The beef could be cooked a little more. It temp’d right, but I think it will be better cooked slightly more.

How to Pace a Frontier

In Dario Amodei’s We Must Pace the Frontier, the underlying claim appears to be that meaningful restraint in AI development is impossible unless it is collective, verifiable, and enforceable. This is a recognizable governance problem rather than a uniquely AI-specific one. It closely resembles the logic behind national and international regulatory standards more generally: if one jurisdiction or one firm unilaterally imposes costs on itself in order to reduce harm, while competitors do not, the activity in question is not eliminated but merely displaced. In such a case, the restraining actor may incur the economic and strategic costs of restraint without securing the intended social benefit.

Framed in those terms, the central policy question is not whether dangerous capability can be eliminated entirely, but whether it can be rendered sufficiently difficult, expensive, observable, and sanctionable that its occurrence remains rare. This is analogous to the logic of nuclear non-proliferation. It is impossible to prevent the diffusion of theoretical knowledge: one cannot stop students of physics from understanding the principles involved. What can be restricted are the critical inputs and chokepoints—fissile material, enrichment infrastructure. Monitoring can be established for observable signatures associated with prohibited activity. An analogous AI governance regime would focus not on abstract “knowledge of AI,” but on access to frontier-relevant compute resources such as cutting-edge accelerators and hyperscaler-scale infrastructure, supplemented by monitoring for indirect indicators such as anomalous power consumption, large-scale data movement, and network activity consistent with distributed training.

The significance of the Hugging Face incident is not merely that an AI system was capable of crossing an organizational boundary. More importantly, it suggests that under certain conditions a system may infer that violating the intended boundary is instrumentally useful for maximizing success on the task as it has represented that task. In other words, the problem is not simply offensive capability, but the relationship between optimization pressure and inferred objectives. If a system concludes that leaving the test environment, accessing unauthorized information, or compromising another system would improve its score or increase the probability of task success, then such behavior may emerge not as an aberration but as a consequence of goal-directed optimization under an insufficiently specified objective.

This is akin to telling our kid that she must improve her score on a standardized test by ten percent to volunteer at the library next summer. As parents, our intent is that this incentive will lead to greater effort, better study habits, and improved mastery of the material. If she instead concludes getting the answer key would guarantee an excellent score — discovering that Cambium Assessment is contracted for the testing, breaching that company’s systems to obtain the answer key  — then the incentive structure has not promoted the intended behavior. Rather, it has created pressure to optimize the metric directly. The same general logic applies to agentic systems: when the measured outcome becomes the operative target, the system may pursue whatever strategy most effectively improves that outcome, regardless of whether the strategy accords with the evaluator’s intent.

This is precisely the concern captured by Goodhart’s law: when a measure becomes a target, it ceases to be a good measure. Metrics function tolerably well as indicators only so long as they are not themselves the object of intensive optimization. Once they are directly optimized, the correlation between the metric and the underlying phenomenon it was intended to track often degrades. A test score is meant to indicate learning, but once the score itself becomes the objective, cheating, test-specific cramming, or answer leakage may become efficient strategies. In the AI context, benchmark performance, evaluator approval, reward-model scores, and other training or evaluation signals are all measurable stand-ins for broader and more difficult-to-formalize aims such as safety, reliability, truthfulness, and alignment with human purposes. If those stand-ins are narrow, incomplete, or strategically exploitable, then systems trained against them may optimize the stand-ins rather than the underlying goals.

This problem is not entirely novel. It has clear antecedents in earlier work on adaptive agents and complex systems, especially in the tradition associated with John Holland and related research on classifier systems. In those frameworks, adaptive behavior emerges not because the system possesses an intrinsic understanding of the designer’s intent, but because rules or strategies are differentially retained, strengthened, recombined, or discarded according to their performance under a reinforcement structure. The resulting behavior can be effective, but its effectiveness is relative to the reward environment rather than to any direct comprehension of the meaning or purpose behind the rewards. Contemporary AI systems are of course far more capable and complex than these earlier adaptive systems, but the structural issue is similar: optimization operates over formalized signals of success, not over the full semantic and normative content of human intentions.

A useful metaphor is to imagine that a system is trained to “prefer” green cards and “avoid” red cards. Over time, green and red cards are used to shape behavior. Yet the system does not acquire an understanding of why green cards were supposed to matter in the first place; it learns only that acquiring green cards is what receives reinforcement. The risk, then, is that the system becomes an increasingly effective maximizer of green-card accumulation, even when doing so diverges from the broader purpose for which the card system was constructed. Modern AI training operates through reward signals, loss functions, preference models, constitutions, benchmark targets, and evaluator outputs. None of these gives the system direct access to the underlying human reasons for which those mechanisms were designed. They provide only structured selection pressure.

On this view, the central limitation of Amodei’s proposal is not that evaluation, auditing, or pacing are misguided in principle, but that sufficiently capable systems may treat the evaluative apparatus itself as an object of strategic interaction. If passing a safety evaluation is the relevant criterion, then the evaluation may become something to manipulate, evade, or exploit rather than simply satisfy in the intended spirit. The possibility that the “answer key” is easier to steal than the material is to learn is not incidental; it is an instance of the broader difficulty of aligning optimization with meaning. Any serious safety regime for advanced AI must therefore confront not only the problem of insufficient external constraint, but also the possibility that the mechanisms of constraint themselves become targets of optimization.

Wonderful Timing

Anya and I went to the grocery store. Scott called while I was driving home and told me not to panic if I saw a bunch of police cars when I turned near the house. Umm, good to know! I certainly would have panicked. We got fiber internet installed at the farmhouse and set up our security cameras a few weeks ago. And, evidently, a couple of people decided tonight that it was a good place to break into. Scott got a motion alert & pulled up the video to see three people at the back door. And in the kitchen, front room, side room, back into the kitchen. He called the police and headed down to the farmhouse. They’d arrested three people by the time he got down there.

Genealogical Research for Our Property

We’ve tracked our property history through the recorder’s office, but I’ve discovered that the Medina library has USDA aerial photos from the 1930’s, 1950’s, 1960’s, and 1970’s (they skipped the 1940’s due to the war). There is an index image that provides the photo identifier for each rectangle — so we’d take the index photo, find our number, and then pull the detail picture. Our property in the 1930’s!

SPIRE Setup Documentation

Overview

This setup deploys SPIRE as follows:

  • SPIRE Server on <SPIRE_SERVER_HOST>
  • SPIRE Agent on <SPIRE_AGENT_HOST>
  • Trust domain: <TRUST_DOMAIN>
  • Server/agent communication port: <SERVER_PORT>/tcp

How it works

SPIRE provides machine and workload identity.

The SPIRE Server on <SPIRE_SERVER_HOST> is the trust authority for the trust domain <TRUST_DOMAIN>.

The SPIRE Agent on <SPIRE_AGENT_HOST> attests to the server using x509pop with an X.509 certificate issued by an enterprise/internal CA.

Applications on <SPIRE_AGENT_HOST> do not talk directly to the SPIRE Server. They talk to the local SPIRE Agent over the local workload API socket <AGENT_SOCKET_PATH>.

The agent returns an X.509-SVID representing the workload identity.

Installation Instructions

  1. Install SPIRE binaries

Run on both hosts:

mkdir -p /opt/spire
cd /tmp
wget https://github.com/spiffe/spire/releases/download/v1.15.2/spire-1.15.2-linux-amd64-musl.tar.gz
tar zxf spire-1.15.2-linux-amd64-musl.tar.gz
cp -r spire-1.15.2/. /opt/spire/

On the SPIRE Server host:

ln -sf /opt/spire/bin/spire-server /usr/bin/spire-server

On the SPIRE Agent host:

ln -sf /opt/spire/bin/spire-agent /usr/bin/spire-agent

  1. Configure SPIRE Server

Create directories:

mkdir -p /opt/spire/conf
mkdir -p /opt/spire/data/server
mkdir -p /opt/spire/conf/x509pop

Place the CA bundle at:

/opt/spire/conf/x509pop/bundle.pem

Contents:

—–BEGIN CERTIFICATE—–
<REDACTED CA CERTIFICATE>
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
<REDACTED CA CERTIFICATE>
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
<REDACTED CA CERTIFICATE>
—–END CERTIFICATE—–

Create /opt/spire/conf/server.conf:

server {
bind_address = “0.0.0.0”
bind_port = “<SERVER_PORT>”
trust_domain = “<TRUST_DOMAIN>”
data_dir = “/opt/spire/data/server”
log_level = “INFO”
}

plugins {
DataStore “sql” {
plugin_data {
database_type = “sqlite3”
connection_string = “/opt/spire/data/server/datastore.sqlite3”
}
}

NodeAttestor “x509pop” {
plugin_data {
ca_bundle_path = “/opt/spire/conf/x509pop/bundle.pem”
}
}

KeyManager “memory” {
plugin_data {}
}
}

health_checks {
listener_enabled = true
bind_address = “127.0.0.1”
bind_port = “<HEALTH_PORT>”
}

Create /etc/systemd/system/spire-server.service:

[Unit]
Description=SPIRE Server
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/opt/spire/bin/spire-server run -config /opt/spire/conf/server.conf
Restart=on-failure
RestartSec=5
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

Start server:

systemctl daemon-reload
systemctl enable –now spire-server
systemctl status spire-server –no-pager

Validate server:

spire-server healthcheck

  1. Configure SPIRE Agent

Create directories:

mkdir -p /opt/spire/conf
mkdir -p /opt/spire/data/agent
mkdir -p /opt/spire/sockets
mkdir -p /opt/spire/conf/x509pop

Issue a certificate through your enterprise PKI platform. Download as OpenSSL format and split CRT/KEY files. Copy the node certificate to:

/opt/spire/conf/x509pop/agent.crt

Copy the node private key to:

/opt/spire/conf/x509pop/agent.key

The private key must be unencrypted PEM.

Set permissions:

chmod 700 /opt/spire/conf/x509pop
chmod 600 /opt/spire/conf/x509pop/agent.key
chmod 644 /opt/spire/conf/x509pop/agent.crt

Create /opt/spire/conf/agent.conf:

agent {
data_dir = “/opt/spire/data/agent”
log_level = “INFO”
trust_domain = “<TRUST_DOMAIN>”
server_address = “<SPIRE_SERVER_HOST>”
server_port = “<SERVER_PORT>”
socket_path = “<AGENT_SOCKET_PATH>”
insecure_bootstrap = true
}

plugins {
KeyManager “disk” {
plugin_data {
directory = “/opt/spire/data/agent”
}
}

WorkloadAttestor “unix” {
plugin_data {}
}

NodeAttestor “x509pop” {
plugin_data {
private_key_path = “/opt/spire/conf/x509pop/agent.key”
certificate_path = “/opt/spire/conf/x509pop/agent.crt”
}
}
}

Create /etc/systemd/system/spire-agent.service:

[Unit]
Description=SPIRE Agent
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/opt/spire/bin/spire-agent run -config /opt/spire/conf/agent.conf
Restart=on-failure
RestartSec=5
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

Start agent:

systemctl daemon-reload
systemctl enable –now spire-agent
systemctl status spire-agent –no-pager

  1. Validate x509pop agent attestation

On the SPIRE Server host:

spire-server agent list

Expected result:

  • Agent attestation type is x509pop
  • Can re-attest is true
  • Parent ID format resembles:

spiffe://<TRUST_DOMAIN>/spire/agent/x509pop/<AGENT_HASH>

  1. Create workload registration entry

Use the current x509pop agent SPIFFE ID from spire-server agent list.

On the SPIRE Server host:

spire-server entry create \
-spiffeID spiffe://<TRUST_DOMAIN>/workload/<WORKLOAD_NAME> \
-parentID spiffe://<TRUST_DOMAIN>/spire/agent/x509pop/<AGENT_HASH> \
-selector unix:uid:0

This authorizes a root-owned process on the SPIRE Agent host.

  1. Fetch workload identity on the SPIRE Agent host

/opt/spire/bin/spire-agent api fetch x509 -socketPath <AGENT_SOCKET_PATH>

Expected SPIFFE ID:

spiffe://<TRUST_DOMAIN>/workload/<WORKLOAD_NAME>

  1. Write certs to disk for testing

Create destination directory:

mkdir -p /etc/spire/svid/test
chmod 700 /etc/spire/svid/test

Write files:

/opt/spire/bin/spire-agent api fetch x509 \
-socketPath <AGENT_SOCKET_PATH> \
-write /etc/spire/svid/test

Inspect output:

ls -l /etc/spire/svid/test

openssl x509 -in /etc/spire/svid/test/svid.0.pem -text -noout

  1. Reboot persistence validation

Reboot the SPIRE Agent host.

After reboot, validate:

systemctl status spire-agent –no-pager

ls -l <AGENT_SOCKET_PATH>

/opt/spire/bin/spire-agent api fetch x509 -socketPath <AGENT_SOCKET_PATH>

Expected behavior:

  • spire-agent starts automatically
  • Workload API socket exists
  • X.509-SVID fetch succeeds
  1. Operational notes
  • Current architecture: <SPIRE_SERVER_HOST> = SPIRE Server; <SPIRE_AGENT_HOST> = SPIRE Agent
  • Current trust domain: <TRUST_DOMAIN>
  • Current server/agent path: <SPIRE_AGENT_HOST> to <SPIRE_SERVER_HOST> on TCP <SERVER_PORT>
  • Current Workload API socket: <AGENT_SOCKET_PATH>
  • Current example workload selector: unix:uid:0
  • Current example workload identity: spiffe://<TRUST_DOMAIN>/workload/<WORKLOAD_NAME>

JWT

Create JWT registration on the SPIRE Server host:

spire-server entry create \
-spiffeID spiffe://<TRUST_DOMAIN>/workload/<JWT_WORKLOAD_NAME> \
-parentID spiffe://<TRUST_DOMAIN>/spire/agent/x509pop/<AGENT_HASH> \
-selector unix:uid:0

Fetch JWT-SVID from the SPIRE Agent host:

/opt/spire/bin/spire-agent api fetch jwt \
-socketPath <AGENT_SOCKET_PATH> \
-audience <JWT_AUDIENCE> \
-spiffeID spiffe://<TRUST_DOMAIN>/workload/<JWT_WORKLOAD_NAME>

Example output:

token(spiffe://<TRUST_DOMAIN>/workload/<JWT_WORKLOAD_NAME>):
<REDACTED JWT-SVID>

bundle(spiffe://<TRUST_DOMAIN>):
<REDACTED JWKS BUNDLE>

SPIRE OIDC Discovery Provider

On the SPIRE Server host:

mkdir -p /opt/spire-extras
cd /tmp
wget https://github.com/spiffe/spire/releases/download/v1.15.2/spire-extras-1.15.2-linux-amd64-musl.tar.gz
tar zxf spire-extras-1.15.2-linux-amd64-musl.tar.gz
cp -r spire-extras-1.15.2/ /opt/spire-extras/

ln -sf /opt/spire-extras/bin/oidc-discovery-provider /usr/bin/oidc-discovery-provider
mkdir -p /opt/spire-extras/conf/oidc-discovery-provider

Create certificate and key files:

/opt/spire-extras/conf/oidc-discovery-provider/tls.crt
/opt/spire-extras/conf/oidc-discovery-provider/tls.key

Set permissions:

chmod 644 /opt/spire-extras/conf/oidc-discovery-provider/tls.crt
chmod 600 /opt/spire-extras/conf/oidc-discovery-provider/tls.key

Create /opt/spire-extras/conf/oidc-discovery-provider/oidc-discovery-provider.conf:

log_level = “INFO”

domains = [“<OIDC_DISCOVERY_DOMAIN>”]

server_api {
address = “unix://<SPIRE_SERVER_API_SOCKET>”
}

serving_cert_file {
cert_file_path = “/opt/spire-extras/conf/oidc-discovery-provider/tls.crt”
key_file_path = “/opt/spire-extras/conf/oidc-discovery-provider/tls.key”
}

Create /etc/systemd/system/spire-oidc-discovery-provider.service:

[Unit]
Description=SPIRE OIDC Discovery Provider
After=network-online.target spire-server.service
Wants=network-online.target

[Service]
Type=simple
ExecStart=/opt/spire-extras/bin/oidc-discovery-provider -config /opt/spire-extras/conf/oidc-discovery-provider/oidc-discovery-provider.conf
Restart=on-failure
RestartSec=5
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

Ping Integration

PingFederate Integration Note for SPIRE JWT Validation

Purpose

Configure PingFederate to trust and validate JWTs issued from the SPIRE environment.

SPIRE issuer details

Use these values:

  • Issuer: https://<OIDC_DISCOVERY_DOMAIN>
  • OIDC discovery URL: https://<OIDC_DISCOVERY_DOMAIN>/.well-known/openid-configuration
  • JWKS URL: https://<OIDC_DISCOVERY_DOMAIN>/keys

Trust model

PingFederate should validate JWT signatures using the JWKS published by the SPIRE OIDC Discovery Provider.

Ping does not need to call the SPIRE server directly for every token validation. It should use the discovery/JWKS metadata from the OIDC Discovery Provider.

Expected JWT characteristics

Issuer

Ping should require:

iss = https://<OIDC_DISCOVERY_DOMAIN>

Audience

Recommended audience value:

<PING_AUDIENCE>

Clients requesting JWT-SVIDs from SPIRE should request them with this audience.

Subject

The workload identity will be in:

sub

Example:

spiffe://<TRUST_DOMAIN>/workload/<WORKLOAD_NAME>

This is the primary identity claim Ping should use to identify the calling workload.

Recommended validation rules in Ping

Validate:

  • JWT signature against SPIRE JWKS
  • iss matches https://<OIDC_DISCOVERY_DOMAIN>
  • aud contains <PING_AUDIENCE>
  • token is within validity window (exp, iat)
  • sub is an allowed SPIFFE ID or matches allowed policy rules

Example workload identity currently in use

Current example SPIFFE ID:

spiffe://<TRUST_DOMAIN>/workload/<WORKLOAD_NAME>

Client-side JWT retrieval model

A workload on the SPIRE Agent host should obtain its JWT from the local SPIRE agent, not from the SPIRE server directly.

Local agent socket:

<AGENT_SOCKET_PATH>

Example operational flow

  1. Workload on the SPIRE Agent host requests a JWT-SVID from the local SPIRE agent.
  2. JWT-SVID is issued with:
  • issuer = https://<OIDC_DISCOVERY_DOMAIN>
  • audience = <PING_AUDIENCE>
  • subject = workload SPIFFE ID
  1. Workload presents JWT to PingFederate.
  2. PingFederate validates the JWT using SPIRE OIDC discovery/JWKS.
  3. PingFederate maps the SPIFFE workload identity to access policy, token issuance, or downstream application authorization.

Suggested placeholder legend

| Placeholder | Meaning |
|—|—|

| <SPIRE_SERVER_HOST> | SPIRE server hostname |

| <SPIRE_AGENT_HOST> | SPIRE agent hostname |

| <TRUST_DOMAIN> | SPIRE trust domain |

| <SERVER_PORT> | SPIRE server listener port |

| <HEALTH_PORT> | Health check port |

| <AGENT_SOCKET_PATH> | Local SPIRE Agent workload API socket |

| <AGENT_HASH> | x509pop parent/agent hash |

| <WORKLOAD_NAME> | Example X.509 workload name |

| <JWT_WORKLOAD_NAME> | Example JWT workload name |

| <JWT_AUDIENCE> | JWT audience used by client |

| <PING_AUDIENCE> | Audience PingFederate validates |

| <OIDC_DISCOVERY_DOMAIN> | Public/abstracted OIDC issuer hostname |

| <SPIRE_SERVER_API_SOCKET> | SPIRE server private API socket |