Syncplify Server! has a built-in protection mechanism, called Protector!, that automatically block-lists IP addresses exhibiting suspicious behavior. It works brilliantly against actual attacks. Against your own load balancer, though, it will work just as well, and that is the problem. If your load balancer’s IP address is not in the safe-list, Protector! will eventually block it, and when that happens, every node behind that load balancer stops accepting connections. Not because the software failed. Because it did exactly what it was told.

The fix is a single configuration step: every IP address used by every load balancer in your HA deployment must go in the safe-list. Not the allow-list (which has entirely different semantics), not the block-list (obviously), the safe-list. Safe-listed addresses are never auto-blocked, regardless of how many times they connect and disconnect without authenticating. This is precisely what the safe-list was designed for. Full details on all three list types are in our knowledge base, alongside the complete HA setup guide. If you are running a load-balanced HA cluster and have not checked this, now is a good time.

Containerizing a product like Syncplify Server! is not trivial. The server runs three cooperating processes: the SyngoDB database engine, the REST API and control plane, and one worker process per virtual site. These processes communicate over loopback addresses, which do not cross container network boundaries. Rather than rewiring the IPC layer entirely, we chose a monolith container model: all three processes share a single network namespace inside one container. Every loopback address works identically to bare metal, and IPC code didn’t need to be altered.

The bigger challenge was the worker lifecycle. On Linux, virtual site workers have always been managed by systemd. Inside a container there is no systemd. We built a small in-process supervisor that replaces systemd in container mode: it forks, monitors, and terminates worker processes directly, with graceful SIGTERM handling and a even a kill-timeout that mimics bare metal and VM operation. The switch is activated by a single environment variable.

The container image is built for both linux/amd64 and linux/arm64 and published as a multi-arch manifest on Docker Hub. Deployment is a single docker compose up -d. The data directory, log directory, and user “homes” are mounted from the host, so the license, configuration, and all virtual site data persist across container restarts and image updates.

It even support hybrid clustering, with some nodes running in bare-metal/VMs, and some other nodes running in/as containers!

We are in the final testing phase. The Docker image and a full deployment guide will ship soon with one of the upcoming release. Stay tuned.

When Syncplify Server! v7.5 is released (please, be patient just another little bit!!) it will come with an additional deployment option on top of the usual “download and install”: a docker container image.

Stay tuned for more…

What’s changed?

• Upgraded back-end SyngoDB server to version 6.2.3

• Fixed several accessibilty issues in the WebClient! UI

• Fixed a few minor bugs to all 4 UIs (Setup, SuperAdmin, Admin, and WebClient!)

Please, also read this note which pertains to all updates/upgrades. And, as usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

Meet grinder, our in-house multi-protocol stress testing utility. It doesn’t just push data at a server as fast as the network allows. It simulates the worst real-world conditions imaginable: connection drops, jitter, backoff cycles, the full chaos of a production environment having a very bad day. Two instances, each hammering a different node of the same cluster simultaneously, with 10 concurrent connections each and a 50MB buffer per session.

In short: grinder is every SFTP server’s nightmare. And we pointed two of them at a two-node Syncplify Server! v7.5.0 HA cluster running our brand-new clustering subsystem.

The result? Completely smooth. Rock stable. Not a single crack.

Node one held at 426 MiB/s. Node two at 341 MiB/s. Combined throughput north of 750 MiB/s (that’s mebibytes per second, not megabits!) sustained across both nodes simultaneously, under full grinder conditions, while the HA subsystem handled synchronization in the background without breaking a sweat.

The dashboard tells the story clearly: 30-40 concurrent active sessions across both nodes, uploads and downloads running in parallel, data transfer peaking near 1,000 MiB/s on individual bursts. Zero rejected sessions. Zero instability.

This is the same new HA algorithm we teased recently, the one we rebuilt from scratch to handle time drift, fast catch-up after node inactivity, and per-node per-site draining with full observability. Under grinder load, it performed exactly as designed.

We’ll have more to share soon, including the full release details. But if you run Syncplify Server! in a high-availability deployment you’ll definitely want to deploy this new version when it becomes available.

Syncplify Server! v6.x has been retired and is under Limited Long-Term Support (LLTS). Under normal circumstances, no new v6 builds would be produced. This release is an exception, made exclusively because a critical defect affecting some but not all HA (high-availability) clusters warranted a backport.

What’s in this release

• Critical fix (backported from v7): Corrected an HA node communication defect that could (in some limited cases) cause cluster nodes to exchange excessive inter-node traffic, consuming significant network bandwidth while performing no useful work. In severe cases this could degrade the cluster performance.

That’s it. There are no new features, no other fixes, and no roadmap changes. This is a surgical release for one reason only.

A reminder about v6 support status

Version 6 is retired. LLTS means we address critical defects when the impact is severe enough to justify it. It does not mean v6 is back on the active development track, and it does not mean future issues will always receive backports.

If you are running v6, the right long-term answer remains the same: upgrade to v7. It is more secure, more capable, and actively maintained. Every day on v6 is a day without the improvements, protections, and fixes that ship continuously in v7.

If you are running an HA cluster on v6 and cannot upgrade immediately, apply this release. Then make upgrading to v7 your next scheduled priority.

You can download the most recent releases from our website.

Thank you for your continued trust in Syncplify.

The first generation of Syncplify Server!’s HA subsystem was built incrementally, as the product grew and as customer deployments grew more ambitious. It worked. But four years of production data, support cases, and internal tooling gave us a precise catalog of the edge cases it handled imperfectly and the operational experiences that were harder than they needed to be. Rather than continue grafting improvements onto a design which foundational assumptions were no longer sound, we made the decision to rewrite the entire HA subsystem from scratch.

This is not a reversal. It’s engineering maturity. Here’s what changes.

Automatic Recovery From Node Failures

When a node goes offline, the current implementation keeps it marked offline until the cluster is explicitly told to reset it. A transient hiccup, something that resolved itself in 30 seconds, can still require administrative intervention to clear.

The new engine recovers automatically. When an offline node comes back, the cluster detects it, catches it up on any missed changes, and resumes normal operation. No manual steps, no scheduled tasks to babysit.

For most customers on stable infrastructure, this will never matter. For customers running in cloud environments with occasional transient connectivity events, it matters every week.

A Dedicated Heartbeat, Separate From Data Sync

The existing subsystem infers node health from whether data synchronization succeeds. If a node has nothing new to sync, there is no communication at all, and silence is indistinguishable from unavailability.

The new engine introduces a lightweight, continuous heartbeat that runs independently of data replication. The cluster always has an accurate, current picture of which nodes are reachable, regardless of whether any data has changed recently.

Continuous Clock Verification

All timestamp-based HA implementations require synchronized clocks. The new engine goes further: it continuously verifies clock accuracy continuously during operation, not just at startup, and it can detect when a specific node is the one drifting, rather than only detecting that a difference exists. A node that determines it is the source of drift can self-quarantine from pushing changes, preventing incorrect data from propagating.

Stronger Inter-Node Authentication

Every inter-node request in the new design is cryptographically signed, covering the full request body. A timestamp embedded in every signature prevents replay attacks. Combined with TLS transport, this closes a class of inter-node threat scenarios that the previous implementation did not fully address.

A Wire Format That Survives Rolling Upgrades

The previous implementation used a binary encoding that fails silently when the data structures on two nodes diverge, as they inevitably do during an upgrade. The new design uses a versioned, human-readable wire format. Unknown fields are ignored gracefully. Protocol version mismatches are detected and reported cleanly rather than causing silent data corruption.

Automatic Tombstone Purging

Deletion records used to accumulate indefinitely, requiring manual cleanup. The new engine purges them automatically on a configurable schedule. A node that has been offline long enough to miss the purge window is handled gracefully on reconnection, with no operator involvement required.

The Worker Is Simpler

In the current design, the worker process participates in HA replication with its own sync cycle and its own database connections for that purpose. In the new design, replication is an exclusive responsibility of the ss-webrest process. The worker is notified of relevant changes via IPC and reloads only what changed. Its behavior is identical whether HA is enabled or not.

What Does Not Change

The behavioral contract is preserved. Two-node active-active HA, the same replicated collections, the same operational model. The upgrade path from the current implementation will be clear and documented.

We will publish more detail, including the migration procedure for existing clusters, closer to the release date. If your deployment has specific edge cases you want to make sure we have covered, or if you’re interested in BETA-TESTING this new HA approach, please reach out to us directly via https://syngo.to/support.

Not a cosmetic refresh. A complete overhaul of the synchronization algorithm, with meaningful gains in speed and resource efficiency, plus first-class handling of edge cases that were simply not on the radar before: time drift, fast catch-up after extended node inactivity, and elegant per-node, per-site draining with full observability.

Speaking of observability, here’s a sneak peek at where things are headed:

No release date to announce yet. But if HA deployments matter to your infrastructure, this one is worth keeping an eye on.

What’s changed?

• Vastly improved the VFS Configuration section in the Admin UI, its user experience (UX) is now much cleaner and user-friendly

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

What’s changed?

• Fixed one critical bug that could cause mis-mapping of the REST API port for inter-node communication and synchronization between HA (high-availability) nodes belonging to the same set

• Made setting permissions onto shared objects (files and folders) in WebClient! much clearer and easy to understand

• Several other “quality of life” improvements to WebClient!, including but not limited to, a convenient “refresh” button, a more consistent editing experience for “self” (own profile), the ability to set custom colors (light and dark) for WebClient!’s title and disclaimer, and a few other accessibility improvements

• Block-list items are now included in backup/restore operations (NEW!)

• OTP inputs on all 3 UIs are now auto-focused if/when they appear

• Vastly improved SMTP configuration and testing

• Several more small bug-fixes to all 3 UIs (SuperAdmin, Admin, and WebClient!)

Please, also read this note which pertains to all updates/upgrades. And, as usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

Here is what changed, and why it matters.

The SyncJS library is now the common cross-product engine. Previous versions of AFT! had their own bespoke (and somewhat incompatible) SyncJS implementation. Starting with v4.0, every AFT! automation uses the new SyncJS engine shared library: the same engine that powers Syncplify Server! event handlers and R2FS! storage backend scripting tasks.

This is not a compatibility layer; it is a true unification. A script you write for AFT! will run on Syncplify Server! without modification (except for APIs that are product-specific by design), and vice versa. One scripting language. One API surface to learn. One VSCode extension to install.

Speaking of which: the SyncJS VSCode extension is already AFT!-aware. Install it, set syncjs.product to aft (which is the default), and you get full IntelliSense for every SyncJS built-in, every AFT!-specific extension (FsWatcher, RemoteWatcher, WaitForHaltSignal, Params, JobID), and the full SyncJS API surface. The extension also bundles MCP servers, so AI coding assistants like GitHub Copilot (etc) have accurate, real-time awareness of the AFT! scripting API.

Scripts can run long-lived jobs or one-shot executions. This is the design choice that opens the most doors. An AFT! script can run as a persistent process. WaitForHaltSignal() blocks the script until an operator stops it via the web UI or the REST API, which means scripts can react to events in real time rather than polling on a schedule. FsWatcher monitors local directories for file-system events (create, write, remove, rename, chmod) and fires a callback the moment something changes. RemoteWatcher does the same for remote directories. Both support recursive subdirectory tracking. Newly created subdirectories are covered automatically, with no extra logic required. Scheduled execution via a cron-compatible built-in scheduler is still fully supported for batch workloads. The two models coexist.

The VFS Library replaces hardcoded credentials. Connection profiles (SFTP, FTP/S, S3, Azure Blob, GCS, local filesystem) are defined once in the VFS Library with a name and tested independently. Scripts reference them by name using VirtualFSByName(). Credentials never appear in script code, and the same script works across environments by simply changing which named profile it references. This is the AFT! equivalent of the VFS Library concept that Syncplify Server! users already know well.

CopyToVFS/MoveToVFS transfer without touching local disk. When copying or moving a file from an SFTP server to an S3 bucket, AFT! streams it directly between the two endpoints. Nothing is staged locally. And if it’s a “move” operation, the source file is removed automatically after a successful transfer.

Named Secrets keep credentials out of scripts. Passwords, API keys, and other sensitive values are stored encrypted in AFT!’s secrets store and retrieved at runtime with GetSecret("secret-name"). They never appear in plain-text anywhere in the script.

The full SyncJS function library is available. That means SFTP, FTP/S, S3, Azure, and GCS client objects with a uniform upload/download API; fluent HTTP client for REST API calls; SQL database access; AMQP messaging (RabbitMQ and Azure Service Bus); PGP encryption and signing; HMAC signing and verification; CSV and XML parsing; email, Slack, Teams, Telegram, and Twilio notifications; process execution with output capture; encoding and compression; image processing; and TcpConnect for lightweight health checks. The 21 new SyncJS core functions announced last week are all available in AFT! v4 as well.

The admin UI has been completely redesigned and vastly improved. New dashboard, new script editor with syntax checking, cron job management, op log, license management, and settings, all rebuilt. Login is now protected by bcrypt-hashed passwords and TOTP-based two-factor authentication.

Migration from AFT! v3 is a single command. Run aft import-from-aft3 and your existing v3 JavaScript scripts are imported. They will require review, and likely some adaptation to the SyncJS API, but the import step eliminates the manual copy-paste work.

It ships as a single binary with no external dependencies. One file. No runtime, no sidecar processes. Drop it on Linux or Windows, run it interactively, or install it as a system service with one of the supplied installers, and it is operational. The binary is CGO-free and statically linked.

Come check out the new AFT! at syncplify.com!

What’s changed?

• Fixed a minor issue in the installer (not the software itself) that wasn’t able to correctly identify updates/upgrades for fully-licensed instances.

As usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

Soon, soon, soon!

Here is the complete addition:

File operations: GzipFile, GunzipFile, FileAgeSecs, FileSizeOf, WaitForFile, SplitFileByLines, SplitFileBySize

Data and encoding: ParseCSV, FormatCSV, ParseXML, Base64Encode, Base64Decode, HashString, FormatDateTime

Cryptography: HmacSign, HmacVerify, PGPSignFile, PGPVerifyFile

Integration: RunCapture, TcpConnect, SendToTeamsWebHook

The three additions that change the most scripts

HMAC signing and verification. HmacSign and HmacVerify implement the pattern behind every major webhook security model: GitHub, Stripe, Slack, and virtually every cloud event system use HMAC-SHA256 to authenticate payloads. Until now, doing this from a SyncJS script meant shelling out to an external tool. That workaround is gone. Both functions support SHA-256 and SHA-512. HmacVerify uses constant-time comparison, so it is safe in authentication paths.

var key     = GetSecret("webhook-secret");
var sig     = HmacSign("sha256", key, payload);
var trusted = HmacVerify("sha256", key, payload, incomingSig);

Native CSV and XML parsing. The majority of real MFT scripts exist to read, transform, or route files based on their contents, not just their filenames. ParseCSV returns a two-dimensional array of strings. ParseXML returns a nested JavaScript object with a predictable structure: attributes under _attrs, text content under _text, repeated elements as arrays. Neither function requires a child process or an external dependency. The data is just there, in memory, ready to drive routing logic.

var rows = ParseCSV(ReadTextFile("/inbox/orders.csv"));
var doc  = ParseXML(ReadTextFile("/inbox/manifest.xml"));
Log("order count: " + rows.length + ", ship-to: " + doc.order._attrs.destination);

WaitForFile. If you have written a SyncJS script that waits for an upstream process to drop a trigger file, you have written the sleep/check/repeat loop manually. WaitForFile replaces it entirely. Pass a path, a timeout in milliseconds, and an optional poll interval. Get a boolean back.

if (!WaitForFile("/processing/trigger.flag", 30000)) {
  Log.Warn("trigger file did not arrive within 30 seconds");
  Exit(1);
}

The rest, in brief

GzipFile and GunzipFile compress and decompress single files in place or to a named destination. SplitFileByLines and SplitFileBySize partition large files into numbered chunks, the prerequisite step for any parallel-upload pattern. FileAgeSecs and FileSizeOf return exactly what the names say, useful for conditional logic without a full StatFileSystemObject call.

PGPSignFile and PGPVerifyFile extend the existing PGP encrypt/decrypt pair with detached signature support. HashString brings string-level hashing to the same eight algorithms already supported by HashFile. Base64Encode and Base64Decode handle the encoding required by virtually every HTTP API.

RunCapture turns the output of any OS command into a string your script can use directly. TcpConnect checks whether a host and port are reachable before committing to a full connection. SendToTeamsWebHook joins Slack and Telegram in the notification options. FormatDateTime formats timestamps using token-based patterns without requiring the standard library workarounds that JavaScript developers normally reach for.

In conclusion

Full documentation for every new function is in the SyncJS scripting reference. If you write scripts in VSCode, the Language Server extension picks up all new symbols automatically after updating. No reinstall required.

And it doesn’t end here. SyncJS is becoming more and more central to the life and interoperation of all Syncplify software products, so we’re fully committed to its constant upkeep and improvement.

What’s changed in Server!?

• Bumped the scripting subsystem to SyncJS v4.1.2, which adds 21 brand new utility functions to the language

• Fixed a bug in the Admin UI that prevented clearing the SMTP configuration

• Improved UX of the WebClient! UI to more explicitly incorporate the new browser security restrictions with regards to OS interoperation with the file/directory selectors during uploads

What’s changed in R2FS!?

• Bumped the scripting subsystem to SyncJS v4.1.2, which adds 21 brand new utility functions to the language (same as in Server!)

Please, also read this note which pertains to all updates/upgrades. And, as usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

Given that over 90% of developers work in VSCode or one of its derivatives, that was the obvious place to start.

SyncJS is 100% ECMA 5.1-compliant JavaScript at its core, but it also adds 200+ functions, methods, structures, and symbols on top of the base language. Expecting every developer to memorize that extended API was never realistic.

So we built a VSCode extension that solves both problems at once: a full Language Server for inline documentation and auto-completion, and an MCP (Model Context Protocol) server so AI agents can write SyncJS scripts for you without hallucinating methods or structures that don’t exist.

Here’s how to get set up.

1. Install the SyncJS extension

Search for SyncJS in the VSCode Extension Marketplace and install it.

2. Register the MCP servers in your User profile

Once installed, open the command palette with Shift+Ctrl+P and run: SyncJS: Register SyncJS MCP Servers in User Profile.

Reload your VSCode window when prompted for the change to take effect.

3. Add a SyncJS MCP server to your project

After reloading, open the command palette again and run MCP: List Servers.

Select the SyncJS flavor that matches your project: core SyncJS (symbols shared across all Syncplify products), or the extended symbol tables specific to Server! or AFT!.

4. Prompt your AI agent

That’s it. Your AI agent now has precise, complete knowledge of the SyncJS language: its syntax, object model, and the full functional API. Write your prompt as you normally would.

5. Your SyncJS script is ready

The agent produces a working SyncJS script. Review it, make any adjustments you want, then paste it directly into your Syncplify product’s web UI.

The SyncJS VSCode extension is available today. Whether you prefer writing scripts by hand with full auto-completion and inline documentation, or delegating the first draft to an AI agent that actually knows the language, the tooling is there.

Install it, connect your agent, and let SyncJS do the heavy lifting across your entire Syncplify environment.

What’s changed in Server!?

• Extracted the SyncJS scripting language (Syncplify’s very own extended version of JavaScript built on top of the ECMA 5.1 standard with the addition of many dedicated functions, methods, and types) into an independent shared library so that it can be ported to R2FS! and AFT! as well with perfect consistency

• Removed deprecated ioutil package (Go) and switched to the recommended alternatives (io, os, etc…)

• Fixed a bug with the multiplexed session counter for SSH-based subsystems which could, in certain conditions, “forget” to decrement the number of total active sessions in the dashboard

• Fixed several cosmetic (and one functional) bugs in the Admin UI

What’s changed in R2FS!?

• Added full SyncJS scripting and event-handling (uses the same SyncJS extended version of JavaScript also available in the Server! software) - now you can run your SyncJS scripts on the storage side as well!

• Added indexed/searchable VFS-level “op log” directly in R2FS!’s back-end database (does not substitute log files, which are still there for full auditing trail)

Please, also read this note which pertains to all updates/upgrades. And, as usual, you can download the most recent release from our website.

Thank you all for trusting our software with your secure file transfers!

Every file operation is recorded with timestamp, operation type, VFS, user, path(s), bytes received and sent, duration, and error status. You can filter by time range, operation, user, VFS, or any combination thereof. Precisely the kind of granular, on-demand visibility that system administrators have always wanted when something needs investigating.

A quick clarification, though, for the security-conscious reader: this is not a replacement for the digitally signed, tamper-evident log files you already rely on. Those aren’t going anywhere.

The operation log is a complementary tool, optimized for interactive exploration rather than compliance attestation. Think of the signed log files as your forensic record and the op-log as your operational sidekick, both live side by side, each doing what they are designed to do.

As with SyncJS support, we’re not ready to commit to a specific release date, but v2.0 is close. Maybe even closer than you think.

Well, starting with R2FS! v2.0, you will have it. When this release lands, you’ll be able to execute SyncJS scripts not just on the server side (as always), but directly on the storage side via the R2FS! storage connector.

That means your event-driven logic can live where your data lives, opening up automation patterns that simply weren’t possible before.

And because SyncJS scripts are already fully portable between Syncplify Server! and R2FS!, any script you’ve written and tested today will run without modification tomorrow (with the exception of server-only contexts that simply don’t exist in R2FS!, but that’s obvious).

We’re not ready to announce a specific release date yet, but R2FS! v2.0 is on the near horizon. Stay tuned.

When you move your organization’s file transfer operations to a cloud MFT platform, you typically hand your data to a third party. That’s the obvious part, the part everyone understands and accepts as the trade-off for convenience and scalability. What’s less obvious, and far less discussed, is what happens to certain encryption keys.

Most cloud MFT platforms encrypt your data at rest. They’ll tell you this proudly, and technically, they’re telling the truth. What they’re less eager to explain is that in the overwhelming majority of cases, they also manage the encryption keys. Their infrastructure. Their key management system. Their access.

Which means, if you read between the lines: they can decrypt your data. Not because they want to, not because they’re malicious, but simply because the architecture permits it.

Why This Matters More Than You Think

Consider what that architectural reality means in practice.

It means that a sufficiently serious breach of your vendor’s infrastructure is also a breach of your data, regardless of how strong the encryption algorithm is. Encryption only protects data if the keys are out of reach. When the keys live alongside the data in the same vendor environment, you don’t have two locks on the door. You have one.

It means that a subpoena, a national security letter, or a government inquiry directed at your vendor potentially becomes your problem, even if your organization was never the target. Your data’s legal exposure is no longer purely a function of your own legal standing.

It gets worse: It means that a rogue insider at your vendor has a theoretical path to your most sensitive files. Again, not likely. But in regulated industries, “not likely” is not a compliance posture.

It means, bluntly, that you’ve outsourced not just the infrastructure but the trust model itself.

The Industry Has Normalized Something It Shouldn’t Have

The uncomfortable truth is that most organizations never ask these questions during vendor evaluation. “Do you encrypt data at rest?” gets a yes, the checkbox gets checked, and the conversation moves on. The far more important question, “Who holds the encryption keys, and what would it take for someone other than us to access them?”, rarely gets asked.

This isn’t a criticism of IT and security teams. The cloud MFT market has spent years (and a remarkable amount of dollars) conditioning buyers to treat server-side encryption as sufficient. But it isn’t. Not for organizations operating in regulated industries, not for organizations handling sensitive partner data, and not for any organization that takes data sovereignty seriously.

The standard should be simple: your data should be encrypted in a way that makes it technically impossible for anyone other than you to access it. Not policy-impossible. Not contractually-impossible. Technically impossible.

What Good Actually Looks Like

True data sovereignty in a cloud file transfer context requires one thing above all else: encryption keys that never leave your control, managed on infrastructure you own, in a network you control.

This means the encryption and decryption of your data at rest happens on your side of the boundary, not your vendor’s. It means your vendor’s cloud infrastructure acts as a secure, highly available relay, moving encrypted data it cannot read, between parties it authenticates but cannot impersonate. It means that even in the worst-case scenario, a complete compromise of the cloud layer yields nothing useful to an attacker, because the keys were never there.

This architecture exists. It’s not theoretical, it’s not exotic, and it doesn’t require sacrificing the operational benefits of a managed cloud service.

It does, however, require vendors who were willing to build it that way from the ground up, rather than retrofit the appearance of security onto a model that was never designed with true key separation in mind.

At Syncplify, we’ve always believed that the right answer to “who holds the keys?” is unambiguous: you do. Always. Without exception.

We’ll have more to say about how we’ve put that belief into practice. Stay tuned.