SignalLock - Emergency Alert Integrity Checker

AI may rewrite the words. SignalLock checks whether it rewrote the action—flagging drift in critical actions, locations, timing, and constraints before human approval.

Comment

🚨 AI may rewrite the words. It may not rewrite the action.

Emergency alerts are one of the worst places for a rewrite to be almost correct.

Consider:

SOURCE: Residents of Zone A must evacuate after 6:00 PM.
REWRITE: Residents of Zone A must evacuate before 6:00 PM.

The rewrite is fluent. Only one relationship changed — AFTER → BEFORE — but the protective instruction is now materially different.

We built SignalLock — Emergency Alert Integrity Checker to detect this kind of critical semantic drift before a rewritten emergency message is approved by a human.

💡 Inspiration

Emergency messages may need to be rewritten, simplified, reformatted, or adapted before reaching the public.

The challenge is that ordinary text similarity is not enough.

Two alerts can use very different words while preserving the same instruction. Two other alerts can look almost identical while changing a critical action, location, time, or condition.

That led us to the principle behind SignalLock:

AI may help rewrite the words. It should not get to silently rewrite the action.

Instead of trusting fluency as evidence of correctness, SignalLock treats the original alert as the authority and checks whether action-critical meaning survives the transformation.

🔍 What it does

SignalLock is a preflight integrity checker for rewritten emergency alerts.

It compares an authoritative source alert with a candidate rewrite and checks operational meaning such as:

  • ACTION — what people are instructed to do
  • PLACE — where the instruction applies
  • TIME — when the action should happen
  • CONSTRAINTS — conditions, restrictions, exceptions, and other operational qualifiers

Where safely represented, SignalLock can also compare semantics such as hazard identity, severity, certainty, audience, and conditional instructions.

The key difference is that SignalLock does not simply ask an AI model:

"Do these two alerts mean the same thing?"

Instead, operational meaning is converted into structured safety contracts and compared using deterministic application logic.

If critical meaning changes, SignalLock can flag the drift. If important meaning cannot be represented confidently, the system fails closed to human review rather than guessing that the messages are equivalent.

SignalLock is a verification layer — not an autonomous emergency-alert publisher.

🌍 SDG impact

SignalLock primarily aligns with UN Sustainable Development Goal 11: Sustainable Cities and Communities, especially Target 11.5, which focuses on reducing deaths, people affected, and losses caused by disasters.

SignalLock's contribution is deliberately specific: reducing one avoidable risk in emergency communication — a critical instruction changing while an alert is being rewritten or adapted.

During an emergency, details such as who must act, where they must go, when they must act, and under what conditions can determine whether a warning remains actionable.

SignalLock adds an integrity check between message transformation and human approval so those operational details are less likely to change silently.

The project also has secondary relevance to SDG 13: Climate Action, particularly where reliable warning communication supports resilience to climate-related hazards.

SignalLock does not claim to solve disaster resilience by itself. It focuses on one narrow but important part of the warning pipeline:

preserving the operational meaning of an emergency alert.

⚙️ How we built it

SignalLock uses a layered architecture built around explicit trust boundaries.

Structured safety contracts

Operational information is extracted into typed data so critical fields can be compared directly instead of relying only on free-form text similarity.

Conservative extraction

We built deterministic extraction for supported alert structures, with an optional structured AI extraction path.

AI-produced structure is not treated as the final safety decision. The verification boundary remains deterministic.

Deterministic verification

The verifier compares represented actions, places, times, conditions, restrictions, and other operational invariants.

This means the final integrity decision does not depend on asking a language model whether its own rewrite is safe.

CAP-aware processing

SignalLock supports the Common Alerting Protocol (CAP) so structured emergency-alert information can participate in the same integrity-checking workflow.

Authority-bound reference

The authoritative source representation can be bound and reused during verification, helping prevent the reference meaning from silently changing while a candidate rewrite is evaluated.

Fail-closed uncertainty

If operational meaning cannot be represented confidently, SignalLock preserves that uncertainty instead of silently discarding it.

That uncertainty is routed toward human review.

🧪 The hardest challenge

Our hardest bugs were not crashes.

They were silent semantic-loss bugs: cases where the software successfully processed a sentence but failed to represent one important part of its operational meaning.

Adversarial testing uncovered failure families involving timing, conditions, hazard identity, severity, certainty, mixed-language text, restrictive modifiers, and semantic scope.

For example, we discovered that recognizing a time expression is not enough if the system fails to attach that time to the action it modifies.

That gave us one of the project's most important engineering rules:

Recognized ≠ represented. Matched ≠ consumed.

If critical text is recognized but its meaning is neither represented nor explicitly preserved as unresolved, a verifier can receive an incomplete picture and incorrectly conclude that two alerts match.

We responded by strengthening extraction, residual-text accounting, trust boundaries, and regression testing.

The result is a system designed not only to compare what it understands, but also to remain cautious about what it does not understand.

📊 Current prototype results

We evaluate SignalLock with both adversarial transformations and meaning-preserving controls.

On our current internal DEV benchmark of 108 cases:

  • 76 / 76 unsafe transformations were blocked
  • 0 / 76 unsafe transformations passed
  • 32 / 32 clean controls passed

The final v0.12.4 prototype passes 611 automated tests covering dangerous transformations, meaning-preserving controls, extraction behavior, trust boundaries, CAP processing, and production-reachable verification paths.

We also conducted a separate final adversarial audit. Across 119 executions classified as clear critical drift, 0 received PASS.

These are finite development and adversarial evaluation results — not a claim of production safety, certification, universal accuracy, or proof that SignalLock cannot fail.

That distinction matters to us.

The purpose of testing is not to prove that SignalLock can never fail. It is to actively search for the conditions under which it can fail, make those failures visible, and strengthen the integrity boundary.

✨ Why this approach is different

SignalLock separates AI-assisted interpretation from deterministic verification.

Rather than asking a model to transform an alert and then trusting an AI judgment about whether the result preserved the instruction, SignalLock creates a separate integrity boundary around action-critical meaning.

The system combines:

  • typed semantic contracts
  • deterministic invariant verification
  • conservative extraction
  • explicit unresolved-text handling
  • CAP-aware processing
  • authority-bound verification
  • adversarial regression testing
  • human-in-the-loop review

The goal is not to make AI more confident.

The goal is to make critical semantic changes harder to pass silently.

📚 What we learned

The biggest lesson was that semantic verification is also a coverage problem.

A verifier cannot compare meaning that an earlier stage silently discarded.

We also learned that:

  • fluent language is not evidence that an instruction was preserved
  • schema-valid output does not guarantee semantic completeness
  • provenance does not guarantee completeness
  • tiny modifiers can carry operationally critical meaning
  • uncertainty needs an explicit state rather than an optimistic guess
  • testing the complete production path matters, not only the core comparison function

These lessons pushed SignalLock toward a more conservative architecture than we initially expected.

They also changed how we think about AI safety in high-stakes workflows: sometimes the most important question is not whether a model produced valid output, but whether anything important disappeared between the input and that output.

🏆 What we're proud of

We're proud that SignalLock became more than a text-comparison demo.

During development, adversarial tests repeatedly challenged our assumptions about what it means to "preserve" an emergency instruction.

Instead of hiding those failures, we used them to improve the architecture.

SignalLock now has explicit mechanisms for structured meaning, unresolved operational text, deterministic comparison, authority preservation, fail-closed uncertainty, and human review.

For us, that is the most important accomplishment of the project:

when the system is uncertain about critical meaning, confidence should not be invented.

🚀 What's next

SignalLock is a hackathon prototype, not a certified public-warning system.

Next, we want to:

  • continue adversarial semantic qualification
  • improve handling of meaning-preserving paraphrases while maintaining fail-closed behavior
  • evaluate additional languages through controlled testing
  • broaden CAP-based historical alert evaluation
  • improve field-level explanations for human reviewers
  • validate our assumptions with emergency-communication and public-safety experts

We intentionally do not want SignalLock to autonomously publish emergency alerts.

The long-term vision is a verification layer that helps a human reviewer answer one critical question before approving a transformed alert:

Did the words change, or did the action change?

Built With

Share this project:

Updates

Submission history