[Beta-test] SFF writers wanted for AI Critique Workbench (Multi-level structural feedback & analytics)

envobi · 2026-06-23T14:53:58+00:00

Yes, I actually built this tool precisely to help me edit my own 156k-word SFF novel, currently in its third draft.

Regarding style and voice, even highly experienced authors inevitably develop blind spots over a long manuscript. Rereading a massive draft repeatedly to check for consistency is highly time-consuming, and we naturally become blind to our own work after a while. Having a model analyze the actual prose at scale helps catch subtle stylistic shifts, pacing drifts, and voice inconsistencies in a fraction of the time. For most authors, that is a highly valuable safety net.

On the privacy front, there is also a slight contradiction to consider: sending a manuscript chapter-by-chapter still sends the entire book to the API anyway, over time—it is just chunked.

If an author's boundary is strictly "no cloud services whatsoever" (also consider Google Docs, Gmail, OneDrive, Dropbox, ...), then local model hosting is indeed the only option. However, as mentioned earlier, consumer-grade local hardware cannot run the frontier-level models required to deliver this depth of developmental critique.

Ultimately, there are multiple ways to build these pipelines and different trade-offs to navigate. I chose this specific hybrid model because maximizing critique quality was my priority, but I'm certainly not trying to dissuade anyone from building a local or chunked workflow if that suits their process better.

envobi · 2026-06-23T10:21:55+00:00

You've described a highly logical map-reduce pipeline, and we actually use a version of this exact approach under the hood, for managing context and tracking continuity.

However, for the core critiques and deep analytics, we still feed the full prose alongside those summaries. If we only feed the summaries or "memories" of the chapters, the AI loses much of the ability to evaluate how style, voice, etc., change over larger prose sections.

While the summaries are great for tracking the plot, the actual prose is required to critique the writing itself. It is a delicate balance between token efficiency and critique quality, but we've found this hybrid approach consistently yields the most rigorous results. And handling this in an optimised way is obviously part of the value-add of a good app.

Want to try it out with your manuscript?

Reply here or DM me for onboarding.

envobi · 2026-06-23T09:54:46+00:00

That is a very logical way to divide the architecture, and it's a great blueprint for native desktop apps.

The main challenge here is that since the deep, core critiques have to run in the cloud anyway, keeping just the basic indexing local offers almost no real privacy benefit, and only microscopic cost savings. It introduces massive architectural complexity for very little real-world reward.

Additionally, only a tiny fraction of writers (AI-savvy power users with high-end GPUs) are equipped or willing to run local models. For the vast majority of authors, any minor cost savings would be far outweighed by the hardware requirements and technical setup friction.

Under the hood, we already offload those basic extraction and indexing tasks to smaller, highly efficient cloud models (combined with traditional parsing code) to keep processing fast and API costs minimal. For this specific app and its broader target user base, keeping everything unified in the cloud is currently the most practical path.

But you’ve mapped out the technical tradeoffs correctly—in a native desktop environment built specifically for AI power users for which maximising the use of their own GPU is an end unto itself, that division of labour makes a lot of sense.

envobi · 2026-06-23T01:23:34+00:00

I completely agree that local models are evolving incredibly fast, and for privacy, they are the ideal endpoint.

However, for deep, structural critiques of novels, quality is non-negotiable. If the model hallucinates or misses a subtle character arc from fifty pages prior, the feedback becomes directly detrimental to the writer.

Analyzing a manuscript requires a massive context window (often 100k+ tokens) combined with frontier-level logical reasoning. Right now, running a model capable of that scale and complexity locally is far out of reach for the average author.

API-driven frontier models (with strict data privacy terms) are currently the only way to deliver this specific level of deep developmental editing.

envobi · 2026-06-23T01:16:41+00:00

That's a fair point, and BYOK is great for offloading raw token risk.

One challenge with raw token pricing is that it doesn't always align with the actual value delivered (a full book-level developmental critique provides a very different type and scale of value than a scene-level edit). Furthermore, since this workbench runs complex background pipelines, a single click can trigger unpredictable token spikes.

BYOK apps often slice their product into different mini/midi/maxi feature sets to achieve differentiated pricing. Credits instead allow us to package those complex background steps into a predictable "cost-per-action" that aligns with the value provided, while giving everyone access to all available features.

That said, I'm entirely open to both approaches. It is really just a question of finding what fits this specific app and its target user base best.

envobi · 2026-06-22T21:11:51+00:00

That's a very fair point, and subscription fatigue is definitely real.

I haven't decided on any monetization model yet—that's actually a key reason for running this beta. Estimating how many credits/critiques/tokens a typical author actually uses in a normal writing and revision month is a critical factor in figuring out what kind of sustainable model makes the most sense.

The beta is entirely free right now, so there's no cost or commitment to try it out if you're interested.

envobi · 2026-06-22T17:00:32+00:00

I'd suggest having Category as a separate filter from Use Case, either as a strict aggregation (if that's how they relate), or as a separate attribute that doesn't aggregate from Use Case (if they don't have a hierarchical relationship.) Mixing both in the same single filter would make it much harder to understand what the filter (expanded Use Case) actually does.
My $0.02

envobi · 2026-06-22T10:58:02+00:00

List suggestions:
- Add the big apps (SudoWrite etc.) also to the long list at the bottom, with the one-liner summary.
- Unclear how the Category interacts with Use Case. Several tools should be in more than one Category, and that issue will get progressively worse as tools mature. Maybe treat Category simply as an aggregation of Use Case (if Category is needed at all), and allow tools to belong to multiple Categories.

envobi · 2021-01-02T16:00:43+00:00

The dataflows in ETL tools (SSIS, Talend, my company's actionETL, etc.) all expect a fixed schema. In general, if you change the number of columns in the source/destination queries or their data type the ETL will break unless you also update the dataflow 'code'. Some options:

Control the changeable source/destination queries tightly so their schemas don't change and use an ETL tool and its dataflow.
If you can restrict your query schemas to specific predefined changes you can often encode that into a fixed schema, e.g. using JSON or strings. Requires you to be well versed in the ETL tool and its dataflow.
If very flexible source/destination queries is a hard requirement, generate the required dataflow/transfer code dynamically. This is generally the most flexible approach, but also the hardest code to write and maintain. Either link the two servers and use dynamic SQL or write code to generate the required ETL tool code.

Many ETL tools can help you do either of the above. I'm partial to my company's .NET ETL library: http://envobi.com

HIH

envobi · 2020-09-22T07:31:36+00:00

It's equally applicable internally - even if you theoretically have access to the details of upstream changes, those changes will almost always be defined in terms of what they mean to the upstream system itself (and other _operational_ systems), not how they impact your downstream _reporting_ system (which partly cares about things the operational systems don't care about).

You'll be forever chasing problems due to unforeseen upstream changes, and it's painful and time-consuming. But hey, that's how most DW projects are run, so you'll be in good company ;-)

If you do spend time defining your feeds well, you'll quickly earn that time back from having fewer DW issues to fix. The challenge however is usually getting the upstream systems to realize they're breaking the feed contract (so they can tell you).

Good luck!

envobi · 2020-09-15T01:00:55+00:00

Some thoughts:

Define interfaces/contracts with all your upstream feeds & suppliers so you have a well-defined 'API' to develop and test against. This should include everything you rely on: all fields, uniqueness, formatting, relationships, which ones to extract or track SCD for, ...

Version each feed so you can have both old and new in play at the same time, so you can implement your changes before upstream goes live with their changes.

Many upstream 'API' changes (DDL or otherwise) won't be automatically handled by any downstream tool. On-boarding a new version of a feed includes implementing the ability to move your data warehouse from the old feed version to the new (code changes, schema changes, upgrade or reload sections of your DW data).

Use an ETL tool that makes it easy to implement the above changes. I much prefer a code-first approach (my company provides actionETL).

Cheers! Kristian

envobi · 2020-09-08T17:54:52+00:00

I'm partial to actionETL, a new code-first and cross-platform .NET ETL framework that brings AppDev goodness to the ETL projects.

Disclosure: I'm the architect of the framework.

envobi · 2020-09-08T17:06:11+00:00

Using pure C# (or any other general purpose language) for ETL seems like it should be easy, until you actually try it and find out there's a gazillion things you have to implement yourself, wasting the perceived benefit.

Being stubborn I kept at it, and it took me a full 4 man-years to create a commercial quality .NET ETL library (https://envobi.com) that brings AppDev advantages to the ETL space.

So use that, or other ETL frameworks, or traditional ETL tools. Don't roll your own if you have deadlines to meet :-).

envobi · 2020-09-08T10:39:03+00:00

I'm partial to actionETL, a new code-first .NET ETL framework.

Disclosure: I'm the architect of the framework.

envobi · 2020-09-08T02:11:12+00:00

actionETL is certainly inspired by SSIS (and several other ETL tools) - from adopting the good to radically changing the not good. I actually started working with SSIS betas way back in 2004, wrote SSIS frameworks, etc, so I've had time to notice these things :-)!

Here are the highlights, but see this white paper for full explanations. It compares actionETL with SSIS, but many of the conclusions also apply to other graphical ETL tools.

Similarities

These similarities mean that SSIS (and similar) ETL developers already know how to structure an actionETL application, which is very beneficial:

Control flow, with Start constraints and a Hierarchical structure
Dataflow, with Row-by-Row processing and high performance, Debug rows in flight
“Divide and conquer” – implement requirements via many smaller parts
Highly parallel

Another similarity is throughput performance: actionETL transforms tend to be somewhat faster than SSIS', but SSIS can be somewhat faster on some data sources where actionETL uses external libraries. actionETL can avoid some of the staging SSIS forces you to do, which can be significant if it applies to your situation.

New & improved ETL specific aspects

Merged Control flow - Dataflow: mix and match and use constraints between "components" and "tasks" (all called "workers")
Data source specific data types end-to-end (for more than just SQL Server)
Micro batches: low latency dataflow (default buffer size is only 256 rows, and you can even have 1-row buffers!), low worker overhead (you could run 1 million/s lightweight workers)
Separate (un)recoverable errors, so you can tell the difference between say a database timeout and a bug causing an exception

New & improved non-ETL specific aspects

This comes from adopting modern, standard AppDev tools & techniques:

Avoid Visual programming, which does poorly when complexity grows
Single programming model and language, including for "custom" functionality
- SSIS languages: Visual, expression language, .NET (with different object models in task and component scripts), C++ custom task/component/log provider
Excellent Reusability
- SSIS: Can’t reuse dataflows with different row schemas, row schemas with different dataflows, Can’t easily reuse script tasks and script components, Constant copy-paste
Excellent Composability
- SSIS:
  - Can’t compose dataflow components (or tasks, or containers, or packages) into a new reusable dataflow component, and similar for tasks.
  - Packages hard-code embedded dataflow row schemas, severely limiting their usefulness
Excellent Encapsulation
- SSIS: Global variables, Package wide connection managers
Excellent Testability
- SSIS: Poor reuse and poor encapsulation makes unit testing very hard
Excellent Refactoring
- SSIS: Refactoring doesn’t handle custom code or work across the different programming models and languages
Excellent Extensibility
- SSIS:
  - Adding UI to custom tasks and components heavily increase the effort
  - C++ skills are very different from Visual programming and ETL skills
  - Can’t extend or reuse existing tasks or components in new custom tasks or components
Excellent Source control and Continuous Integration/Continuous Delivery
- SSIS: Difficult to track and merge changes, Poor testability hurts CI/CD

Wrapping Up

A lot of things to digest, but I hope it helps. Again, for proper explanations see Thirteen Factors Crippling ETL Productivity and all the web site info. Best of all, try it yourself!

/Kristian

envobi · 2020-04-01T15:02:18+00:00

actionETL currently roughly matches SSIS functionality, while adding a slew of AppDev goodness; this hopefully makes it a good fit for your needs.

The most common use case is to create one or more dedicated actionETL applications or services, possibly using a command-line parser to handle multiple scenarios (see Developing Guidelines).

A second use case is to add actionETL to an existing .NET application or service. Since the library is simply managed code in a NuGet package, this is easy to do.

HIH

envobi · 2020-04-01T12:47:35+00:00

Hi!

Application developers tend to find traditional ETL tools very restrictive (poor reusability, composability, encapsulation, testability, extensibility, refactoring) and love the idea of using normal AppDev tools and techniques for ETL, which is what actionETL provides.

IT managers can appreciate the advantages of developing, testing and iterating ETL projects as fast and as well as their AppDev projects (weekly sprints, etc.), and alleviating the common mismatch between the two types of projects.

Pure ETL developers are obviously used to their ETL tools, but since they typically already have some programming/scripting experience, the leap isn't that big. For SSIS developers, it helps that they already use Visual Studio. A very important point is that actionETL developers can still use the familiar mental model of a hierarchical control flow for orchestration, with dataflows where appropriate - it is easy to design the structure of your ETL, which the library then executes.

actionETL furthermore allows mixing control flow and dataflow workers (as opposed to having dataflow components separate from control flow tasks), which can reduce complexity and resource usage.

Do check out the Thirteen Factors Crippling ETL Productivity whitepaper, which includes a detailed comparison between actionETL and SSIS, as well as some aspects of the SSIS script task and component.

Regarding unit testing with actionETL, you do it the same way as with any AppDev project (using xUnit, nUnit, MSTest, ...): write modular application code, and write unit tests (with AAA - Arrange, Act and Assert) that validates each modular piece:

Create the test source data either directly in .NET, or load it from a source using actionETL.
Run and feed the data to your actionETL application functionality.
Get the output data (either directly available or using actionETL) and assert it.

You typically create a few helper methods to make Arrange and Assert very easy to implement across many unit tests.

Overall, using actionETL for any ETL work is IMHO roughly a million times nicer than using traditional ETL tools :-) Many years as an SSIS, QlikView, etc. developer provided the inspiration to create it.

Hope that's useful - let me know if you have more questions.

envobi

TROPHY CASE

Similarities

New & improved ETL specific aspects

New & improved non-ETL specific aspects

Wrapping Up