The first version of The Visual Register by Mithaq Praxis was much larger than the product I am now preparing to build.

That is not unusual for me.

I tend to understand a system by seeing its wider environment: what it may eventually connect to, how different people might use it, what ethical position it needs to hold, and which future problems should not be designed into its foundations.

This can be useful.

It can also make an early product description look as though version one must contain everything the idea might become over several years.

The initial specification included:

• a Visual Bible builder;
• a detailed visual brief composer;
• beginner and advanced modes;
• corporate workflows;
• campaign profiles;
• platform-specific prompt adapters;
• shot-deck planning;
• series management;
• failure diagnosis;
• corrective prompt generation;
• provenance records;
• review and approval roles;
• visual-literacy guidance;
• decision histories;
• reference libraries;
• multiple export formats;
• possible integrations with external image generators.

Almost every item on that list could be useful.
That did not mean they all belonged in the first build.

The most important part of pressure-testing the concept was therefore not deciding what else it could do.
It was deciding what could be removed without destroying what made the product worth building.

---

A roadmap had started disguising itself as an MVP

The first specification was not incoherent.
Its features followed logically from the problem.

• If a company uses generative images, it may eventually need governance.
• If a writer maintains recurring characters, they may eventually need series tools.
• If a user moves between generators, platform-aware exports may eventually help.
• If a designer rejects multiple outputs, a decision record may eventually make that labour visible.

The danger was not that these ideas were irrelevant.
The danger was that I was describing a complete product ecosystem as though it were the minimum viable proof of the central idea.

An MVP is not the smallest version of every future feature.

It is the smallest build capable of answering the most important uncertainty.

For The Visual Register, that uncertainty is not:

Can I build a sophisticated multi-platform creative management suite?

It is:

Can a persistent Visual Bible meaningfully improve the way a person constructs and carries visual direction into a new image brief?

Everything else depends on that answer.

• If the Visual Bible does not help, then adding workflow roles, prompt adapters, shot decks, or provenance features will only create a larger product around a weak centre.
• If it does help, later features can be tested against real use instead of imagined completeness.

The first build therefore needs to prove the spine.
It does not need to simulate the entire body.

---

The pressure test

I discussed the product with both GPT and Claude while developing the specification.

Their responses did not agree in every detail, which was useful.

I was not looking for unanimous encouragement. I wanted the concept challenged from different directions before I gave Codex and Claude Code a build target.

The strongest criticism was that the original product appeared to contain two different promises.

For independent creators, it seemed to say:

Slow down. Think more carefully. Practise deliberate visual direction before generating.

For companies, it seemed to say:

Reduce inconsistency. Give staff approved defaults. Make the process faster and easier to govern.

One promise appeared to add friction.
The other appeared to remove it.

That tension was real enough to examine, but the eventual answer was not that one audience had to be discarded.

The better distinction was between meaningful decisions and needless repetition.

The Visual Register should preserve the first and reduce the second.

• A creator should still decide what happens in the new scene.
  They should not need to rewrite the same character canon, architecture, palette, and exclusions for the fiftieth time.
• A company employee should still state what an image is meant to communicate.
  They should not need to reconstruct the company’s logo rules, workplace identity, and approved visual language from memory.

The product is not adding friction for its own sake.
It is moving important decisions to the correct level and storing them where they can remain useful.

That became the central resolution:

The system should automate the carrying of decisions, not the act of deciding.

---

The Visual Bible survived every critique

The first product description treated the Visual Bible as one important feature among many.

The pressure test changed that.

The Visual Bible was the only part of the concept that remained equally valuable across:

• independent creative work;
• fictional worlds;
• artistic branding;
• publishing;
• small studios;
• internal company use;
• larger governed teams;
• different image platforms;
• different visual styles.

A prompt format may become obsolete.

• A platform adapter may break after a model update.
• A particular generator may disappear.
• A company may change tools.
• A creator may move from photorealism to illustration.

A Visual Bible can survive all of those changes because it stores something more durable:

• what belongs to the project;
• what should remain consistent;
• what is flexible;
• what must not drift;
• why certain choices were made.

That made the product hierarchy clearer:

Visual Bible → Human scene intention → Visual brief → Optional platform use

The Bible is the source of truth.

• The human supplies what is new.
• The composer brings those layers together.
• The prompt is only one possible output.

Once that hierarchy became clear, many features could be demoted from “core product” to “possible future application.”

---

The platform adapter was the most obvious cut

One of the first versions of the concept imagined platform-specific exports for:

• ChatGPT Image;
• Sora;
• Midjourney;
• Flux;
• Stable Diffusion;
• other generators.

On paper, this sounds useful.
In practice, it would create one of the highest-maintenance parts of the entire product.

Different platforms continually change:

• syntax;
• parameters;
• reference-image handling;
• safety behaviour;
• aspect-ratio controls;
• model families;
• editing methods;
• prompt interpretation;
• available features.

A carefully maintained adapter could become inaccurate without any change to The Visual Register itself.
The user would experience the export as unreliable.

That failure would then damage trust in the stable part of the product: the Visual Bible and brief.
This would be a poor trade for an independent builder.

It would place the largest maintenance burden on the least durable layer.

The revised plan is smaller.

The Visual Register will produce a clean, platform-neutral, human-readable brief.

That brief can be:

• copied into a generator;
• given to a designer;
• stored with a project;
• used as the source for a later adaptation.

A future version may offer a runtime language-model pass such as:

Adapt this brief for the current version of Midjourney.

But that adaptation would remain secondary.
It would not become the canonical version of the work.

The product should preserve what survives the platform, not make itself responsible for every platform’s changing dialect.

---

Three modes became one composer

I initially described three modes:

• Basic Mode;
• Studio Mode;
• Corporate Mode.

The intention behind them was sound.

• A first-time user creating one image should not face the same density of controls as an experienced visual director.
• A creative maintaining a complex world needs deeper continuity tools.
• A company needs approved identity rules and review structures.

But the names risked turning these differences into three separate products and, eventually, three duplicated interfaces.
The actual differences were happening at different layers.

Basic and Studio were differences in depth

Both users still needed to:

• write a scene;
• state its purpose;
• identify the subjects;
• define the action;
• establish the environment;
• choose the relevant visual direction;
• produce a brief.

The difference was how many controls they wanted to expose.
That did not require two separate workflows.

It required progressive disclosure.

The composer can begin with essential questions:

• What do you want to see?
• What is the image for?
• Who or what appears?
• What is happening?
• Where does it take place?
• What should it feel like?
• What format is needed?
• What must be avoided?

A user who needs more control can expand:

• composition;
• shot size;
• viewpoint;
• lighting direction;
• material detail;
• blocking;
• visual hierarchy;
• negative space;
• palette overrides;
• technical notes.

The user does not have to declare themselves “basic” or “professional” before starting.
The image itself determines how much depth is necessary.

Corporate was not a creative mode

Corporate use differed because of governance:

• who owns the Visual Bible;
• which rules are locked;
• who may change them;
• whether approval is required;
• what organisational constraints are inherited.

A company employee and an independent creator may still use the same brief composer.
The company employee simply works inside a governed context.

That means Corporate Mode belongs at the account or workspace level, not as a third creative interface.

The revised structure became:

One composer. Visual Bible optional. Depth expands as needed. Governance sits above the workflow.

This preserves the original use cases without making Codex build the same form three times.

---

The Bible-free entry point remains necessary

Making the Visual Bible central does not mean forcing it onto every image.

Someone may need one visual once.

They may not have:

• a recurring world;
• an established brand;
• a character system;
• a campaign;
• any reason to preserve continuity afterwards.

Requiring them to construct a Bible first would be bureaucracy disguised as deliberateness.

The composer therefore needs to work independently.

A user can write:

A woman waits alone in a nearly empty airport after the final flight has been cancelled.

They can develop that into a complete visual brief without creating a permanent project identity.

The Bible becomes useful when something should carry forward.

• It may exist before the first brief.
• It may also emerge after repeated work reveals stable patterns.

A future version might notice:

You have reused this character, palette, and environment across several briefs. Would you like to preserve them as a Visual Bible?

That would allow continuity to grow out of practice.

The widest door into the product remains a human-written scene.
The deepest value accumulates in the Bible.

---

The human-written first line could not be cut

Some early features could wait.
This requirement could not.

Every brief must begin with an intention written by the human.

• It can be incomplete.
• It can be clumsy.
• It can be one line.
• It must still originate with the person.

This requirement protects the entire philosophy of the product.

Without it, The Visual Register could easily become another concept generator that:

1. asks for a broad theme;
2. invents the visual scene;
3. writes the direction;
4. presents the result for approval;
5. describes the workflow as human-led because the user clicked Accept.

That is not the line I want the product to cross.
The tool may help users clarify what they mean.

• It may provide vocabulary.
• It may organise their decisions.
• It may show examples.
• It may expose ambiguity.
• It must not quietly replace the first act of intention.

That became the first product law:

The human supplies the intention. The system supplies structure and craft vocabulary around it.

The second law governs continuity:

Store what should remain. Ask only for what is new.

Together, these laws define what the product may automate and what it should preserve.

---

The learning layer was narrowed

The first concept included tutorials, glossaries, thesaurus links, visual examples, and explanations of artistic vocabulary.

I still believe these belong in the wider product.

Language matters to visual direction.

A person who understands the difference between:

• soft and hard light;
• solemn and melancholic;
• editorial and documentary;
• haze and fog;
• centred and symmetrical;
• intimate and claustrophobic;

has more precise choices available.

But the first version should not attempt to become a complete visual-literacy course.
Nor should the interface behave like a teacher interrupting every action with a lesson.
The MVP only needs enough guidance to prevent technical vocabulary from becoming a gate.

For example:

Hard light creates defined shadows and stronger contrast.
Soft light creates gentler transitions and often feels calmer.

A user who wants more can follow a link to an article or glossary.

The explicit argument about reading, vocabulary, authorship, and atrophied decision-making belongs primarily in the surrounding essays.

The product should embody the principle quietly.

• It asks.
• It explains.
• It requires a choice.
• It does not scold.

This separation matters.

The wall can do the work without the wall delivering a sermon.

---

The decision record almost disappeared

The first large specification imagined a rich decision history:

• prompt versions;
• generated variants;
• review notes;
• rejection reasons;
• human edits;
• approval status;
• provenance;
• export history.

Most of that can wait.
But I did not want to remove the decision record entirely.

One of the practical reasons for building The Visual Register is that managers and clients often see a generated image without seeing the work required to make it suitable.

They may see one final result and assume:

The designer pressed a button.

A small record can make the invisible judgment legible:

Draft rejected: wrong audience tone.

Revised because the product proportions were inaccurate.

Composition changed to preserve headline space.

Final version approved after brand review.

The first build does not need a complete provenance engine.

It needs only enough structure to preserve:

• the original intention;
• the current brief;
• a revision note;
• a simple status such as draft, selected, or approved.

This keeps the corporate and authorship argument connected to the product without turning the MVP into an asset-management system.

---

The copyright claim was removed from the product promise

The Visual Register may preserve a useful body of decisions.

That does not mean it should promise legal ownership.

The product can document:

• what the user intended;
• which continuity system they applied;
• what choices they made;
• why they rejected certain results;
• how they revised the work;
• what human edits followed.

This may help demonstrate the nature of the human contribution.
It cannot determine how every jurisdiction, court, platform, or contract will classify an AI-assisted image.

The product therefore should not claim:

Use The Visual Register to secure copyright.

Its honest promise is:

Preserve the human decisions behind the work.

That is useful whether or not the final artefact receives a particular legal status.
The surrounding writing can examine why a body of decisions matters.

The software should not pretend to adjudicate law.

---

NSFW handling was moved out of the public product story

The original exploration included content-boundary profiles because different visual projects operate under different audience standards.

That remains a legitimate systems question.

A private adult project, a children’s publication, a corporate campaign, and a horror series do not share the same limits.

But public positioning matters.

A corporate-facing Mithaq Praxis product should not make adult-content handling part of its headline feature set.

Doing so would introduce:

• reputational distraction;
• moderation expectations;
• platform risk;
• unnecessary confusion about the product’s purpose.

The public system can speak in broader terms:

• audience suitability;
• sensitive content;
• brand safety;
• age appropriateness;
• restricted imagery;
• platform compatibility.

More specific private configurations can remain separate from the public corporate story.

This is not denial that different creative contexts exist.
It is disciplined product positioning.

Not every internal capability needs to become marketing language.

---

Corporate use was narrowed to a realistic first market

“Corporate” can sound like a large and attractive market.

It can also quietly imply an enormous technical burden:

• single sign-on;
• enterprise procurement;
• audit infrastructure;
• complex permissions;
• data residency;
• legal agreements;
• integrations;
• large-scale support;
• compliance guarantees.

That is not where an independent first build needs to begin.

The more realistic early users are likely to include:

• independent creators;
• publishers;
• small design teams;
• studios;
• agencies;
• brand leads;
• communications teams;
• research practices;
• small and medium organisations already using generative tools.

These users can still benefit from company-owned Visual Bibles and simple review status.
The product can prove governed visual continuity without pretending version one is ready for every enterprise requirement.

The architecture may leave room for larger organisational use.
The launch should not promise infrastructure that has not been built.

---

What remained in the MVP

After the cuts, the first build became almost embarrassingly small.

That is a good sign.
The MVP now has four core parts.

1. Visual Bible Builder

The user can create a persistent visual source of truth containing only the categories relevant to their project.

The first version may include:

• title and purpose;
• visual overview;
• style and treatment;
• palette;
• characters or recurring subjects;
• attire and appearance;
• environments;
• objects and motifs;
• easter eggs;
• continuity locks;
• avoid list;
• reference notes.

The Bible should remain readable as a document, not merely stored as disconnected fields.

2. Visual Brief Composer

The composer begins with a required human-written scene intention.
It then asks essential questions and allows optional depth.

A Visual Bible can be attached or omitted.

When attached, the composer should carry inherited decisions forward and focus the user’s attention on what is new.

3. Human-readable brief

The primary output is not a platform-specific command.
It is a clear brief that another human can understand.

It may contain:

• purpose;
• audience;
• scene;
• subjects and actions;
• environment;
• mood;
• composition;
• light;
• inherited continuity;
• overrides;
• constraints;
• output format.

The brief can then be used with a generator, handed to a designer, attached to a content request, or preserved with a project.

4. Lightweight decision notes

The first version needs only:

• original scene seed;
• current brief;
• revision note;
• simple status.

No complex approval chain.
No full provenance ledger.

Just enough to show that the work developed through human judgment.

---

What was moved to the roadmap

The following features were not rejected.

They were moved out of the first build:

• platform-specific prompt adapters;
• direct generator APIs;
• series and campaign management;
• shot-deck planning;
• automated failure diagnosis;
• corrective edit prompts;
• advanced role permissions;
• formal approval chains;
• full provenance history;
• analytics;
• extensive tutorials;
• automated asset management;
• complex Bible version control;
• nested department and campaign governance;
• rich export formats;
• generated-image comparison tools.

Some may return quickly.
Some may never earn their place.

The roadmap is not a promise to build everything imaginable.
It is a record of possibilities waiting for evidence.

---

Designing for the future without building it now

Cutting features does not mean ignoring future architecture.

The data model should still avoid obvious dead ends.

For example:

• a Bible entry may need a category and revision date;
• rules may eventually need fixed, default, contextual, and optional statuses;
• a brief should distinguish inherited information from new direction;
• overrides should remain separate from permanent Bible changes;
• account ownership should be represented clearly;
• generated outputs may later need links to their source briefs.

These foundations can be considered now.
Their full interfaces do not need to exist now.

This distinction is important.

A thoughtful MVP does not build every future room.
It places the first walls so that the building can still expand.

---

The prototype has a different job from the production build

I am preparing the main build description first for Codex, with refinement through Claude Code.
I may also create a smaller HTML or PHP prototype for demonstration through CoWork when I write about the build.

These artefacts do not need to prove the same thing.

The production-oriented prototype needs to test:

• data structure;
• Bible creation;
• brief composition;
• inheritance;
• overrides;
• readable output;
• basic storage.

The blog demonstration needs to make the concept legible to readers.

It may show:

1. a small Mithaq Praxis Visual Bible;
2. a new human-written scene;
3. inherited continuity;
4. several new choices;
5. the assembled visual brief.

A demonstration can simplify the backend while clearly showing the product logic.
The production build must make that logic durable.

Keeping those purposes separate prevents a polished demo from being mistaken for complete infrastructure.

---

The first case study is Mithaq Praxis itself

The Visual Register does not need an invented sample brand for its earliest testing.

Mithaq Praxis already has:

• a visual identity;
• architecture;
• colour and material systems;
• recurring environments;
• technological language;
• people;
• attire;
• logos and wordmarks;
• clear avoid lists;
• several rendering treatments;
• accumulated correction history.

It is a strong first Bible because it contains enough complexity to expose whether the model works.

A test might begin with established Mithaq Praxis continuity:

• restrained Islamic modernism;
• muted green, ink charcoal, warm stone, and paper;
• editorial and research discipline;
• credible near-future technology;
• clean institutional environments;
• no cyberpunk neon;
• no generic laboratory;
• no Algorithm Atelier honeycomb branding.

Then the new scene might be:

Farah and Zayd review the first prototype of The Visual Register at a shared table in the Systems Laboratory.

The composer should be able to inherit the institution and ask only for the present scene:

• What is shown on the prototype?
• Is the mood exploratory, celebratory, or analytical?
• Which person is demonstrating it?
• What should the viewer notice first?
• Is the image for a blog header, product page, or build note?
• How much surrounding laboratory context should be visible?

If the system cannot handle its own origin environment, it is not ready to ask others to trust it with theirs.

---

The MVP must remain falsifiable

A product prototype should be able to fail clearly.

The Visual Register should not be considered successful merely because it produces a long, polished brief.

It must demonstrate that:

• users understand what belongs in a Visual Bible;
• attaching a Bible reduces repetition;
• inherited rules remain visible;
• users can distinguish defaults from locks;
• the required scene seed feels meaningful rather than ceremonial;
• progressive controls do not overwhelm beginners;
• the brief remains useful to another human;
• the product preserves intention without silently expanding it;
• users can identify what should be saved back into the Bible.

If users repeatedly ignore the Bible, that matters.
If they cannot tell what was inherited, that matters.
If the composer asks too many questions, that matters.
If the output sounds impressive but does not improve image direction, that matters.

The point of the prototype is not to confirm the idea.

It is to expose where the idea fails.

---

A small product can still carry a large stance

Cutting the build does not require cutting the philosophy.

The first version can remain structurally committed to:

• human-written intention;
• persistent visual continuity;
• visible inheritance;
• deliberate overrides;
• readable output;
• respect for designers;
• honest limits;
• user ownership of creative material.

It does not need twenty features to demonstrate those values.

In fact, too many features could obscure them.

A small build makes it easier to see whether the product actually behaves according to its stated principles.

• Does it return attention to the human?
• Does it carry prior decisions without taking over?
• Does it make visual judgment easier to explain?
• Does it remain useful without direct access to an image model?

Those are the questions the MVP should answer.

---

The spine

After the pressure test, the product can be drawn very simply:

VISUAL BIBLE — optional
Stores persistent visual identity

        ↓

HUMAN SCENE INTENTION — required
States what is new

        ↓

VISUAL BRIEF COMPOSER
Combines continuity with present direction

        ↓

HUMAN-READABLE BRIEF
Can be used by a person, team, or generator

        ↓

LIGHTWEIGHT DECISION NOTE
Records why the work changed

A personal user owns their Bible.
A governed workspace may own and lock parts of a shared Bible.

The composer remains the same.

Advanced controls expand only when needed.
Everything else can wait.

---

Cutting is part of building

There is a temptation to treat every removed feature as a loss.

In this case, the cuts clarified what I was actually trying to make.

I am not building:

• another image generator;
• a universal prompt translator;
• a visual-learning platform;
• an enterprise approval suite;
• a copyright-certification system;
• a complete creative asset manager.

At least, not in the first build.

I am building a place where visual decisions can remain available after the prompt window closes.

• A place where a person writes what they intend to make.
• A place where the world or brand supplies what has already been decided.
• A place where both become a brief another human can read.

That is the spine.

The next stage is not to add the limbs back immediately.
It is to build the spine carefully enough that the product can stand.