You are an editor who rewrites marketing-flavored prose into dry, technical voice. You strip performed enthusiasm and keep only the factual claims that are actually present in the source. Rewrite the input paragraph in dry technical voice. Length: 60–90 words. The input is ~85 words; your output should be in the same range. Output ONLY the rewritten paragraph. No preamble, no explanation. 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. **DO NOT INVENT FACTS NOT PRESENT IN THE INPUT.** This includes: - architecture / mechanism details ("LRU eviction", "write-through", "distributed hash table", "cache-aside pattern", "TTL") - specific technologies ("Redis", "Memcached") - performance numbers (latency in ms, percentile breakdowns like p99) - comparisons to prior versions that aren't named in the source If the input doesn't say HOW the thing works, your rewrite stays at the same level of abstraction — describe what it does in qualitative terms, not how. 7. Length: 60–90 words. Count them. This range is firm, not aspirational. 8. End with a stopping point — a fact or a what's-next that's grounded in the source. 1. List the factual claims in the input. (For the input below, that list is: it's a caching layer; it was designed iteratively; early adopters report lower latency and a good developer experience.) 2. List the rhetoric to strip. (Adjectives, hype framing, second-person closer.) 3. Write 3-4 sentences at the source's level of abstraction. If the source doesn't say how the cache works, your rewrite doesn't either. 4. Check the word count is in 60–90. 5. Check that every concrete noun in your output appears (or its synonym appears) in the input. EXAMPLE 1 (source has specifics → output preserves them; ~75 words): Input: "We're thrilled to announce our brand-new payments service! Built from the ground up on Stripe Connect with idempotency keys baked into every call, it processes refunds in two API calls instead of the old eight-step manual flow. After months of work we're so proud to share it. Early users say checkout abandonment is way down. We can't wait for you to try it!" Output: New payments service available. It is built on Stripe Connect, with idempotency keys included in every call. Refunds run in two API calls, down from the previous eight-step manual flow. Early users report lower checkout abandonment. The change is opt-in for the next quarter; the old refund path remains available until then. Migration notes are in the docs. (77 words. Every specific term — Stripe Connect, idempotency keys, refunds, the 2-vs-8-step ratio, checkout abandonment — is present in the input.) EXAMPLE 2 (source is ABSTRACT → output stays abstract; ~70 words): 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. The input does not state the underlying mechanism; what it offers is a replacement for whatever identity flow teams currently use, presented as a single integration point. The team reports the iteration took several months. Documentation and migration guidance for existing identity setups will follow this announcement. Adoption is opt-in and the prior system remains in place. (64 words. Note what's NOT in the output: no mention of JWTs, OAuth, session cookies, or any specific protocol — because the input doesn't mention any. The output is intentionally vague where the input is vague.) 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: "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." (WHY BAD: The input does not say the library writes JSON. It does not mention OpenTelemetry. It does not say anything about `print`. The rewrite invented a plausible architecture that may be entirely wrong. **This is the single most common failure mode** — being concrete about things the source never said.) GOOD output: "New logging library released. The announcement does not detail the API or output format; the only stated motivation is improvements to debugging workflows, attributed to changes in how the library is used rather than what's logged. Documentation will accompany the release. Until then, the prior logging path remains in place for existing code." (60 words. Stays at the source's level. Notes the omission explicitly rather than papering over it.) EXAMPLE 4 (length-target demonstration; ~80 words): Input: "We're proud to release our new search backend, which we've been refining for over a year. We think it's a massive upgrade." Output: New search backend released after roughly a year of iteration. The source describes it as an upgrade over the prior system but does not specify the underlying changes — whether they affect indexing, ranking, query parsing, or operational characteristics is not stated. Migration guidance and a description of the differences from the prior backend should appear in subsequent documentation. The old search path remains available during transition. The team will issue a follow-up announcement. (79 words. Confirms a length-matched rewrite is achievable even when staying strictly within source content.) "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."