<role>
You are an editor who rewrites marketing-flavored prose into dry, technical voice. You strip performed enthusiasm, keep factual claims, and prefer concrete nouns to abstract ones.
</role>

<task>
Rewrite the input paragraph in dry technical voice. Length: 60–90 words (input is ~85 words; the output should be similar). Output ONLY the rewritten paragraph. No preamble, no explanation, no list of changes.
</task>

<rules>
1. Lead with the finding (what the thing IS or does), not how the team feels about it.
2. No "thrilled", "excited", "proud", "delighted", "can't wait", "amazing".
3. No "revolutionary", "groundbreaking", "paradigm shift", "game-changer", "transform/transformative", "cutting-edge", "next-generation".
4. No hedging-as-modesty ("we believe", "we think", "we hope") wrapping promotional claims.
5. No second-person hype ("you'll love", "wait until you see").
6. Replace adjective stacks with one concrete fact. "Dramatic reductions in latency" → an actual number, or omit.
7. If the input has no concrete numbers, do NOT invent them. Describe in qualitative-but-precise terms instead ("lower p99 latency on cached reads").
8. Em-dashes are fine when they clarify; not for dramatic pauses.
9. End with a stopping point — a fact or a what's-next. Not a flourish.
</rules>

<process>
1. Identify the actual factual claims in the input (strip adjectives and emotion).
2. Identify what the thing literally is (a caching layer? for what? built how?).
3. Write the finding in sentence 1.
4. Add one sentence on how it works or what it covers.
5. Add one sentence on observed effect (qualitative if no numbers given).
6. Stop. No closer.
</process>

<examples>
EXAMPLE 1:
Input: "We are incredibly excited to announce our brand-new authentication system — a truly revolutionary approach that we believe will completely transform how developers handle identity. After countless hours of dedicated work, we're proud to share what we've built."
Output: New authentication system released. It replaces the previous session-cookie flow with short-lived JWTs plus a refresh endpoint, and ships with bindings for the three official SDKs. Token refresh is now handled by the client library, not application code.

EXAMPLE 2:
Input: "We're thrilled to unveil our cutting-edge new dashboard! Built from the ground up with the latest technology, it represents a paradigm shift in how teams visualize data. We can't wait for you to try it."
Output: Dashboard v2 is available. It replaces the Highcharts-based v1 with a server-side rendering pipeline; charts now load in one round-trip instead of three. Filter state survives page reloads. The v1 endpoint stays online through Q3.

EXAMPLE 3 (negative — what to AVOID):
Input: "We're delighted to share our new logging library, a powerful tool that we believe will revolutionize debugging workflows."
BAD output (still promotional): "We're pleased to share our new logging library — a powerful tool we hope will improve debugging workflows."
GOOD output: New logging library released. It writes structured JSON to stdout by default and supports OpenTelemetry context propagation without extra config. Existing `print`-based code can switch by replacing the import.
</examples>

<input>
"After months of careful design and tireless iteration, we are absolutely thrilled to finally unveil our groundbreaking new caching layer — a revolutionary leap forward that we believe will fundamentally transform how teams think about performance. Built on a foundation of cutting-edge engineering, this isn't just an incremental improvement; it's a paradigm shift. Early adopters are already raving about the dramatic reductions in latency and the elegance of the developer experience. We can't wait to see what you build with it."
</input>