After the Prototype

Published On: June 28th, 2026Last Updated: September 15th, 20266568 words32.8 min readDaily Views: 1Total Views: 13

A prototype can make an idea feel true before it has earned that confidence.

  • The interface exists.
  • The buttons work.

A user can create a Visual Bible, write a scene, attach continuity, and produce a readable brief.

Screenshots can be taken.
A demonstration can be placed inside an article.

The project now has something visible enough to describe as a product.

That moment is exciting.

It is also dangerous.

Before the prototype, the concept is protected by abstraction. Every workflow appears elegant because it has not yet encountered:

  • a confused user;
  • an incomplete Visual Bible;
  • contradictory rules;
  • an organisation that has not agreed on its own identity;
  • a creator who works intuitively rather than categorically;
  • a brief that becomes longer without becoming better;
  • an output that sounds polished while quietly changing what the user meant.

The prototype ends that protection.
It gives the idea somewhere to fail.

That is its real purpose.

The first working version of The Visual Register by Mithaq Praxis should not be treated as proof that the product thesis was correct.

It should be treated as an instrument for examining the thesis.

  • Can a Visual Bible genuinely carry continuity across new briefs?
  • Does requiring a human-written first line strengthen intention, or become a ceremonial field users complete without thought?
  • Does the composer help people make decisions, or merely turn visual work into a form?
  • Does inherited information reduce repetition?
  • Can users tell what came from them, what came from the Bible, and what came from the system?
  • Do designers receive better briefs?
  • Do managers understand more of the judgment involved?
  • Does the product remain useful without generating an image itself?

Those questions begin after the prototype exists.

The prototype is not the product’s victory

A prototype proves that something can be built.
It does not prove that it should become a full product.

This distinction matters especially in AI-assisted development, where interfaces can be produced quickly enough to create emotional commitment before practical value has been demonstrated.

Once the prototype looks real, the builder begins to imagine:

  • pricing;
  • user accounts;
  • subscription tiers;
  • launch campaigns;
  • corporate plans;
  • integrations;
  • feature roadmaps.

The visual existence of the software begins pulling the project forward.

  • But a working flow may still rest on incorrect assumptions.
  • Users may not understand the terminology.
  • The Bible may be too much work to establish.
  • The resulting brief may contain information that no designer or generator needs.
  • Corporate users may want a shared source of truth but reject the composer.
  • Creators may love the Bible but prefer to write their own prompts elsewhere.
  • The decision notes may feel valuable in theory and administrative in practice.
  • The product may solve only a smaller problem than the original vision suggested.

None of these outcomes would mean the prototype failed.
They would mean it performed its proper function.

A prototype should reduce uncertainty, not merely produce confidence.

The first user is the builder

I am the obvious first case study for The Visual Register because I already work with several developed visual systems:

  • Bayt al-ʿAhd;
  • Algorithm Atelier;
  • Mithaq Praxis.

I already maintain:

  • recurring characters;
  • architectural language;
  • palettes;
  • attire;
  • environments;
  • technology rules;
  • motifs;
  • personal easter eggs;
  • continuity locks;
  • long avoid lists built from previous failures.

If the prototype cannot improve my own workflow, it has a problem.

But my use alone cannot validate the wider product.

  • I already think in visual systems.
  • I know why the Bayt, the Atelier, and Mithaq Praxis must remain distinct.
  • I am willing to describe environments in detail.
  • I notice drift.
  • I have enough accumulated material to populate a substantial Bible.

An interface may feel natural to me precisely because it has been built around my habits.

That creates a risk:

I may mistake familiarity with my own method for universal usability.

My first tests should therefore ask two different questions.

Does the software accurately represent the way I already work?

And:

Can someone who does not work like me still understand and benefit from it?

The first tests fidelity to the original concept.
The second tests whether the concept can become a product.

The prototype must survive real material

A demonstration can be made to succeed by using clean, carefully selected examples.
A production test should use the messy material that already exists.

For Mithaq Praxis, this includes:

  • overlapping architectural descriptions;
  • several generations of environment prompts;
  • corrections about clutter;
  • corrections about missing futuristic technology;
  • actual logos and wordmarks;
  • distinctions among the Research Library, Systems Laboratory, Editorial Room, Continuity Lounge, and Threshold Gallery;
  • Farah and Zayd’s character continuity;
  • instructions inherited from the wider Bayt framework;
  • repeated prohibitions against generic cyberpunk and Algorithm Atelier branding.

The challenge is not merely to store all of it.
The system has to make it usable.

  • Can I tell which rules apply to every Mithaq Praxis image?
  • Which belong only to an environment render?
  • Which belong to Farah and Zayd?
  • Which are defaults?
  • Which are strict locks?
  • Which were corrections to one failed generation rather than permanent laws?
  • Which reasons need to be preserved so the rule remains understandable later?

If the first Bible becomes a dumping ground for every note I have ever written, the product has not created continuity.

It has created another archive that must be interpreted manually.

The prototype should force a useful question:

What information deserves to become active visual guidance, and what should remain reference material?

That distinction may require a simpler Bible than the total project archive.

A Visual Bible must earn the effort required to build it

The strongest objection to the product may be simple:

Why would someone spend time creating all of this when they can paste a short brand guide into ChatGPT?

The answer cannot merely be philosophical.

The Visual Bible must produce practical value.

It should make later work:

  • faster;
  • clearer;
  • more consistent;
  • easier to hand off;
  • easier to revise;
  • less dependent on one long conversation;
  • less vulnerable to model or platform changes.

A user may spend an hour establishing:

  • a character;
  • an environment;
  • a palette;
  • an avoid list.

If the next brief still requires them to restate most of that information, the Bible has not earned its cost.
If attaching it produces a longer and more confusing form, it has failed.
If the exported brief becomes filled with every stored detail regardless of relevance, it has failed.

The expected exchange should be visible:

More deliberate setup once, less unnecessary reconstruction later.

The prototype must test how soon that exchange becomes worthwhile.

  • For a company, the value may appear after many employees use the same Bible.
  • For a creator, it may appear after the second or third image.
  • For a one-off user, a Bible may never be worth creating.

The product should allow all three realities without pretending that persistent structure is always necessary.

The scene seed must be tested as behaviour, not doctrine

The human-written first line is one of the product’s central laws.

It must also survive usability testing.

Some users will arrive knowing exactly what they want:

Four friends try to keep one oversized pool float balanced while one of them slips into the water.

Others will arrive with only a communication problem:

I need an image for a report about staff retention.

Others may write:

Something innovative for our website.

The system should not invent the whole scene for them.
But it also cannot respond with philosophical rigidity.

It needs to help them begin.

For a user with a communication need rather than a scene, the composer might ask:

  • Who is the audience?
  • What should they understand?
  • What real activity could represent this?
  • Should the image focus on people, environment, product, or symbolic concept?

The eventual first line must still belong to the user.

The prototype should test whether this process feels like:

  • useful clarification;
  • an educational handrail;
  • unnecessary resistance;
  • an empty ritual users rush through.

If users repeatedly enter meaningless text merely to unlock the next screen, the requirement is not functioning as intended.

The answer may not be to remove it.
It may be to redesign the way the system helps people reach it.

The composer must not become a questionnaire about everything

The first working version will expose whether the composer understands relevance.

A product concerned with intention can easily ask too many questions.

For every image, it might request:

  • audience;
  • purpose;
  • subjects;
  • setting;
  • action;
  • mood;
  • shot size;
  • camera angle;
  • lens;
  • light;
  • palette;
  • materials;
  • atmosphere;
  • hierarchy;
  • symbolism;
  • accessibility;
  • output format;
  • exclusions.

These are all legitimate visual considerations.

They are not all necessary every time.

  • A small icon does not require an emotional relationship to architecture.
  • A character reference sheet may not require a narrative atmosphere.
  • A corporate diagram may need clarity, colour, and hierarchy but no cinematic camera language.
  • A one-off playful image may require little more than a clear scene and format.

The prototype should reveal whether progressive disclosure is real or merely cosmetic.

  • A collapsed section that users must eventually open to get a usable brief is not optional.
  • A truly adaptive composer should allow users to stop once the image is sufficiently defined.

One important test question is:

At what point does the user feel that the tool has enough information?

Another is:

At what point does the tool continue asking because the form has more fields rather than because the image needs more thought?

The product must learn the difference between deliberateness and interrogation.

A good output should be shorter than the process when possible

The composer may involve several decisions.

The final brief does not need to repeat them mechanically.

For example, the user may select:

  • an established character profile;
  • a known environment;
  • a quiet mood;
  • medium-wide framing;
  • soft side light;
  • landscape format.

The resulting brief should synthesise those decisions into clear language.

It should not produce:

Mood: quiet.
Framing: medium-wide.
Lighting: soft side light.
Format: landscape.

unless a structured production checklist is the appropriate output.

The system must balance two needs:

  • readability;
  • traceability.

A designer may want a coherent brief.
The user may also need to inspect where each decision came from.

The prototype may therefore need two views:

The assembled brief

A clean document intended for use.

The construction view

A visible breakdown of:

  • human seed;
  • inherited continuity;
  • selected decisions;
  • overrides;
  • system translation.

The product should not force every reader to examine the machinery.

It should keep the machinery available.

The brief must be useful to another human

One of the most important prototype tests is handoff.
A brief may feel clear to the person who created it because they remember the conversation behind it.

The stronger question is:

Can another person understand what to make from this document alone?

A designer reviewing the brief should be able to identify:

  • purpose;
  • audience;
  • scene;
  • required subjects;
  • key action;
  • visual hierarchy;
  • relevant continuity;
  • fixed constraints;
  • areas open to interpretation.

They should not have to reverse-engineer:

  • which details are essential;
  • which are aesthetic suggestions;
  • whether a motif is mandatory;
  • whether the user expects literal execution;
  • whether the generator-specific wording contains hidden assumptions.

A company manager should also be able to read the brief and recognise the request they approved.

If the output is useful only as a prompt pasted into another model, The Visual Register has become narrower than intended.

The brief is meant to be portable across:

  • designers;
  • generators;
  • collaborators;
  • future revisions;
  • organisational review.

Its human readability is one of the main claims the prototype must prove.

The prototype should be tested without an image generator

This may seem counterintuitive.
The entire project concerns visual work.

Surely the brief should be tested by generating images from it.
It should—but not immediately.

First, the brief should be examined on its own.

  • Does it make sense?
  • Does it preserve the user’s intention?
  • Does it contain contradictions?
  • Does it distinguish persistent continuity from present direction?
  • Does it include information the chosen execution method does not need?
  • Could a designer understand it?
  • Could the user return a month later and recognise what they meant?

Testing the brief without a generator prevents model quality from disguising weaknesses in the product.

  • A strong image model can rescue a poor brief.
  • A weaker model can mishandle a strong one.

If the first evaluation focuses only on output quality, it becomes difficult to know what was actually tested.
The prototype must prove that it creates a useful specification before another system interprets it.

Then the brief should be tested across methods

Once the brief is coherent, it should be handed to different execution methods.

The same brief might be:

  • used in ChatGPT Image;
  • adapted for another generator;
  • given to a human designer;
  • interpreted by an illustrator;
  • used as a basis for a photoshoot plan.

The outputs will differ.

The test is not whether they become identical.

The test is whether the persistent direction survives.

Do all interpreters understand:

  • the central action;
  • the intended emotional posture;
  • the project identity;
  • the hierarchy;
  • the critical exclusions?

If one platform requires more explicit information, that may justify an optional adaptation layer.
If every method interprets one section incorrectly, the canonical brief may be unclear.

The comparison should improve the source document rather than lead immediately to a growing library of hand-maintained platform rules.

The first test groups should not all want the same thing

A prototype tested only with people already sympathetic to its philosophy will produce weak evidence.

The early users should include several different relationships to visual work.

The deliberate creator

Someone who already thinks in scenes, references, camera positions, or visual systems.

They can test whether the product supports expertise without slowing it down.

Questions include:

  • Does the Bible reduce repetition?
  • Are the categories too rigid?
  • Does the composer respect complex direction?
  • Can the creator work quickly when they already know what they want?

The operationally scattered creative

Someone with strong taste and ideas whose material is distributed across notes, prompts, folders, and memory.

This is close to my own use.

Questions include:

  • Does the Bible genuinely consolidate the practice?
  • Does it help maintain identity across styles and platforms?
  • Does it become another archive to maintain?

The non-designer requester

Someone who needs visuals for writing, presentations, communications, or small projects.

Questions include:

  • Do the prompts help them make necessary decisions?
  • Can they complete a useful brief without professional vocabulary?
  • Do they understand when the work needs a designer?

The working designer

Someone who receives briefs and must turn them into usable assets.

Questions include:

  • Is the output actually better than an ordinary request form?
  • Which information is missing?
  • Which sections are unnecessary?
  • Does the system make their judgment more legible or create more cleanup?

The manager or brand lead

Someone responsible for consistency, approval, or workflow.

Questions include:

  • Does the Company Visual Bible solve a recognisable problem?
  • Does the decision record clarify why work changed?
  • Which governance features are genuinely needed?
  • Does the product create visibility without becoming surveillance?

The prototype should not attempt to satisfy every group equally in its first version.

It should reveal which group experiences the clearest value.
That may determine the first market more accurately than product reasoning alone.

The first company test should be small

The corporate argument does not require beginning with a large enterprise.

A smaller organisation is more appropriate for early testing because its visual problems are real while its infrastructure demands remain manageable.

A useful test organisation might have:

  • a recognised brand identity;
  • several staff members requesting visuals;
  • one designer or brand lead;
  • recurring communication needs;
  • some acceptance of generative tools;
  • inconsistent briefing practices.

The test may involve:

  1. translating part of the existing brand guide into a Company Visual Bible;
  2. creating several real briefs;
  3. comparing those briefs with prior requests;
  4. asking the designer whether the handoff improved;
  5. observing whether managers understood the revision notes;
  6. identifying which rules needed to be locked;
  7. noting where the company itself lacked a decision.

The first corporate prototype should not attempt:

  • single sign-on;
  • enterprise audit;
  • complex legal workflow;
  • multiple approval tiers.

The purpose is to test the shared visual source of truth.

Governance can remain light.

The prototype may expose that the Company Visual Bible is the harder product

An independent creator can often decide their own visual rules.
A company has to negotiate them.
One department may want a warm human tone.
Another may want technical authority.
Leadership may want innovation.
The existing brand guide may provide broad aesthetic guidance without operational answers.

Creating the Company Visual Bible may expose disagreement about:

  • how employees should be depicted;
  • whether fictional people are acceptable;
  • how closely generated offices must resemble real ones;
  • what level of aspiration becomes misleading;
  • which products may be shown;
  • whether public images require design review;
  • how much visual variation departments should have.

This process may be valuable even before the software produces a brief.

The difficulty is not necessarily a product flaw.
It may be organisational work becoming visible.

But the prototype needs to distinguish between:

  • difficulty caused by a confusing tool;
  • difficulty caused by decisions the company has never made.

The interface should help users recognise the difference.

Designers should be asked what the tool gets wrong

A designer may appreciate better briefs while strongly objecting to parts of the product.

That criticism is necessary.

They may say:

  • the form gives requesters false confidence;
  • the output over-specifies execution;
  • important strategic questions are still missing;
  • the visual vocabulary is too photography-centred;
  • managers may use the decision record to monitor labour;
  • Visual Bibles could become rigid brand policing;
  • a brief assembled by software may sound clearer than it actually is.

These are not peripheral concerns.

The product explicitly claims to respect design labour.
It must be tested by people who perform that labour.

The goal is not to obtain a designer’s endorsement as marketing material.
It is to discover whether the system supports designers or merely uses their language to legitimise automation.

A strong prototype must be able to absorb criticism without defending every original feature.

The learning layer should be tested for transfer

The product aims to encourage reading, vocabulary, and deliberate choice.

The best evidence would not be that users rely on its explanations forever.
It would be that they begin making stronger decisions without assistance.

  • After several uses, does a person naturally write clearer scene seeds?
  • Do they distinguish mood from style?
  • Do they give group members separate actions?
  • Do they remember to consider intended format?
  • Can they explain why an image failed?
  • Do they annotate references more precisely?

If the user becomes increasingly dependent on the system to formulate every visual thought, the learning layer has failed its own philosophy.

A useful test may compare:

  • a user’s first brief;
  • a later brief created with fewer prompts;
  • a brief they write outside the product.

The aim is not to certify visual literacy.
It is to see whether the product builds transferable capacity.

The prototype should measure confusion, not only completion

Software analytics often focus on whether users finish a workflow.
Completion alone may hide serious problems.

A user may complete the brief while misunderstanding:

  • what a Visual Bible is;
  • the difference between a lock and a default;
  • whether an override changes the parent;
  • where system-generated language came from;
  • what approved status means;
  • whether platform output is canonical.

The prototype should gather qualitative evidence.

Ask users:

What do you think this field does?

Which information do you believe will remain for future briefs?

What would happen if you changed this rule?

Which parts of the final brief came from you?

Which parts came from the Bible?

Would you hand this brief to another person?

A user who completes the workflow but cannot answer those questions has not understood the product.

The system may need clearer labels, fewer concepts, or better visual separation.

The terminology must earn its place

Terms such as:

  • Visual Bible;
  • continuity lock;
  • inherited rule;
  • contextual profile;
  • override;
  • treatment;
  • governed workspace;

may be clear to me.

They may not be clear to everyone else.
The prototype should test language ruthlessly.

  • Does Visual Bible feel intuitive, or religiously loaded in a way that distracts some users?
  • Would Visual Register be better for the stored object as well as the product?
  • Do companies prefer Brand Visual System, Visual Source of Truth, or Company Visual Standard?
  • Does override sound technical?
  • Would change for this brief only communicate more clearly?
  • Does locked feel understandable?
  • Could it be mistaken for a security state rather than a continuity rule?

The product should not preserve terminology merely because it sounds elegant in the design document.

Names are interface behaviour.
A user who misunderstands the word may misuse the feature.

The prototype needs a failure taxonomy

When the product does not help, the reason should be recorded carefully.

Possible failures include:

Concept failure

The Visual Bible and composer do not provide meaningful value over existing methods.

Scope failure

The idea is valuable, but the first build attempts too much.

Interface failure

The underlying model is sound, but the workflow is confusing.

Vocabulary failure

Users understand the need but not the terminology.

Inheritance failure

The Bible stores information but cannot apply it selectively.

Output failure

The final brief is too long, generic, or difficult to hand off.

Philosophy failure

The system quietly invents meaning while claiming to remain human-led.

Adoption failure

Users recognise the value but will not spend the time required.

Market failure

The people who benefit are not the people willing or able to pay.

These are different problems.
They should not all be treated as requests for more features.

A failure taxonomy helps prevent reflexive development.

If users find the Bible difficult, the answer may not be an automatic Bible generator.
That feature could solve adoption by violating the philosophy.

The correct response may be:

  • a smaller starting template;
  • guided extraction requiring confirmation;
  • an onboarding service;
  • a narrower audience;
  • acceptance that some users are not a fit.

The prototype should be allowed to disprove the three-context model

The current product structure assumes one composer can serve:

  • one-off users;
  • creators with Visual Bibles;
  • governed organisations.

That is a strong design hypothesis.

It is not sacred.

Testing may reveal:

  • the one-off composer is valuable but too far removed from the Bible workflow;
  • corporate users need a request-and-review experience distinct from creative composition;
  • creators want far more flexible free-form writing than companies permit;
  • the shared data model works, but the front-end experiences should diverge;
  • one audience creates complexity that harms another.

If so, the correct response is not to preserve one interface for philosophical neatness.

The shared spine may remain:

  • intention;
  • continuity;
  • brief;
  • review.

The surface may need different entry points.
The earlier critique warned against building three products prematurely.

That does not mean three experiences can never emerge from evidence.
The prototype determines whether convergence is real or only elegant in theory.

The decision record must prove it is useful, not merely principled

I have defended a lightweight decision record because it can make invisible judgment legible.

The prototype should test whether people use it.

  • Do designers record meaningful rejection reasons?
  • Do managers read them?
  • Do those notes reduce repeated disagreements?
  • Do they improve the Visual Bible?
  • Or do users leave the field empty?

Do they enter:

Did not like it.

Does the feature feel like reporting work rather than supporting it?

A useful decision note should have a clear moment of value.

For example:

  • when rejecting a selected direction;
  • when overriding a major continuity rule;
  • when changing the Visual Bible;
  • when seeking approval.

The system may not need a note for every draft.

Testing should identify where the record clarifies the work and where it becomes administrative residue.

The prototype should not collect more than it can protect

The Visual Register may eventually contain:

  • unpublished worlds;
  • character designs;
  • company brand information;
  • product references;
  • internal environments;
  • creative notes;
  • employee names;
  • project decisions.

This creates responsibility.

Even an early prototype should ask:

  • What data is stored?
  • Where is it stored?
  • Who can access it?
  • Can it be exported?
  • Can it be deleted?
  • Is it used for model training?
  • Which external services receive it?
  • Are company and personal work separated?
  • Are uploaded references protected?

A public demonstration can use sample data.
A production test involving real creative or corporate material needs a clear privacy posture.

The product cannot build trust around preserving people’s worlds while treating those worlds casually as application data.

User ownership is part of the product thesis.
It must exist after the prototype as behaviour, not sentiment.

A local or self-hosted path may become part of the value

Testing may reveal that some users care strongly about where their Visual Bible lives.

A writer may not want unpublished worldbuilding stored in a third-party service.
A company may not want internal product or environment information sent to public models.

An independent practice may prefer:

  • self-hosting;
  • WordPress-based storage;
  • local exports;
  • private model integration;
  • full data portability.

This may become a genuine differentiator for Mithaq Praxis.
It may also increase technical complexity significantly.

The prototype does not need to resolve every deployment model.
It should preserve the possibility by avoiding unnecessary dependence on one external platform.

The canonical Bible and brief should remain exportable in understandable formats.

A product centred on persistent identity should not make that identity hostage to its own service.

The first roadmap decision should come from observed behaviour

After testing, several features will appear tempting:

  • automatic Bible suggestions;
  • series planning;
  • platform adaptation;
  • output comparison;
  • visual review checks;
  • richer governance;
  • reference asset management;
  • collaboration;
  • version history.

The next feature should not be selected because it was already present in the original long specification.

It should be selected because repeated use exposed a specific bottleneck.

For example:

Users repeatedly struggle to decide which Bible entries apply

This may justify better context tagging or relevance suggestions.

Creators repeatedly produce several connected briefs manually

This may justify series support.

Designers repeatedly adapt the same brief for several platforms

This may justify a platform translation layer.

Companies repeatedly need sign-off from one brand lead

This may justify a simple review workflow.

Users cannot understand why a generated output drifted

This may justify a structured comparison or repair note.

The roadmap should grow from evidence.
The earlier specification remains a source of possibilities, not a command.

Some desired features should remain rejected even when requested

User demand matters.
It is not the only criterion.

People may repeatedly ask for:

Generate the entire scene for me.

Automatically build my Visual Bible from these images.

Give me an authorship score.

Tell me whether this will qualify for copyright.

Approve the image automatically.

Those requests arise from real desires:

  • convenience;
  • reduced effort;
  • certainty;
  • authority.

They may still violate the product’s centre or exceed what it can honestly provide.

The response may be:

  • a carefully limited version;
  • a recommendation system requiring confirmation;
  • an educational explanation;
  • refusal.

A human-led product does not remain human-led merely by doing whatever users ask.

The builder also has to govern the product’s boundaries.

The prototype helps distinguish between:

  • friction caused by poor design;
  • friction protecting an intentional limit.

Both may attract complaints.

They should not receive the same response.

The prototype may reveal a service before a product

A possible outcome is that companies and creators value the completed Visual Bible but struggle to construct one alone.

They may benefit from:

  • workshops;
  • guided audits;
  • brand translation;
  • creative-world structuring;
  • designer consultation;
  • assisted onboarding.

This could reveal that the first viable offering is partly a service:

Mithaq Praxis helps a creator or organisation build its Visual Register, then provides the software for continued use.

That would not invalidate the product.

It may clarify where the highest-value human work occurs.

The software organises and carries the identity.

The initial creation of that identity may require:

  • conversation;
  • interpretation;
  • visual expertise;
  • organisational agreement.

A fully automated onboarding flow might be cheaper to scale.

It may also produce shallow Bibles.

Testing should determine whether users can establish meaningful continuity independently or whether guided construction is part of the real solution.

The prototype may reveal a tool for designers rather than a replacement for them

The corporate story could be interpreted as:

Give every employee a system for producing branded images.

Testing may reveal a better role:

Give requesters a clearer way to formulate needs, and give designers a stronger system for maintaining and applying visual identity.

In that version:

  • non-designers create structured requests;
  • designers govern the Visual Bible;
  • the final execution may remain with designers or approved workflows;
  • managers see the decision trail;
  • the product improves the relationship rather than removing the specialist.

This may be a stronger and more responsible corporate position.

The prototype should observe who actually becomes the power user.

  • It may not be the person pressing Generate.
  • It may be the person responsible for making everyone’s visual work belong together.

The prototype should expose whether the Bible is alive

A Visual Bible is intended to evolve through use.
The prototype should test the feedback loop.

After an output fails, can the user decide:

This correction belongs only to this brief.

or:

This should become a persistent rule.

Can they promote the lesson easily without accidentally importing the entire scene?
Can they revise a rule while preserving its rationale?
Can they recognise when the Bible is becoming too restrictive?
Can they retire a motif?

Can they distinguish:

  • a new default;
  • a temporary campaign;
  • an updated canon;
  • an experimental treatment?

If the Bible is difficult to revise, users will stop trusting it.
If it changes too easily, continuity will become unstable.

The product needs a clear but lightweight way to preserve evolution.
The prototype may begin with change notes and dates.

A more sophisticated versioning system should wait until the actual pattern of change is understood.

The prototype should not pretend generated outputs are objective evidence

When testing the product, it will be tempting to compare:

  • a prompt created without The Visual Register;
  • a prompt created with it;
  • the resulting images.

The Register-assisted image may look better.

That demonstration is useful.
It is not conclusive.

The result may be influenced by:

  • model randomness;
  • different prompt length;
  • model familiarity with certain phrasing;
  • selection bias;
  • more generations;
  • stronger references.

A proper evaluation should examine more than visual appeal.

Did the assisted brief improve:

  • subject count;
  • continuity;
  • scene readability;
  • distinct actions;
  • format suitability;
  • brand coherence;
  • ease of revision;
  • handoff clarity?

The product’s value may not always appear as the most beautiful single output.

It may appear as:

  • fewer repeated corrections;
  • clearer rejection reasons;
  • better consistency across a set;
  • reduced designer repair;
  • easier migration between platforms.

The prototype should be judged according to the problem it claims to solve.

The build must be read as carefully as the images

After Codex and Claude Code produce the prototype, the implementation itself becomes an output that must be examined.

The code may work while introducing:

  • unnecessary dependencies;
  • weak access controls;
  • data leakage;
  • hidden automatic rewriting;
  • destructive updates;
  • unclear ownership;
  • poor export behaviour;
  • inaccessible interface patterns;
  • database assumptions that make future revisions difficult.

The application’s visible philosophy may be correct while the underlying system behaves differently.

For example:

  • the interface labels a rule as locked, but the server accepts unauthorised changes;
  • the original scene seed appears preserved, but the database overwrites it during revision;
  • platform adaptations are described as secondary, but only the adapted version is stored;
  • personal and company Bibles appear separate while sharing the same permissions.

Reading generated code is therefore part of the prototype stage, not a technical afterthought.

A human-led build requires the builder to understand enough of the system to take responsibility for deployment.

The prototype should have an exit condition

Many experimental products continue because they have already consumed time and attention.

A responsible prototype should define conditions under which the build pauses or stops.

Possible exit conditions include:

  • users do not experience enough value beyond existing notes or brand guides;
  • the Bible requires so much maintenance that continuity gains disappear;
  • the composer consistently adds bureaucracy without improving briefs;
  • the strongest use case requires a level of enterprise infrastructure Mithaq Praxis does not intend to provide;
  • the literacy mission conflicts irreconcilably with adoption;
  • the product cannot protect sensitive user material adequately;
  • another existing tool already solves the problem more effectively.

Stopping would not erase the thinking.

The essays, Visual Bible framework, and internal workflow could remain useful.

The prototype may still become:

  • an internal Mithaq Praxis tool;
  • a downloadable template;
  • a consulting framework;
  • an open specification;
  • a smaller WordPress utility.

A build does not have to become a subscription product to justify its existence.

The decision to stop can itself be evidence that the process remained human-led rather than momentum-led.

Success may be narrower than the original vision

The full idea touches:

  • creativity;
  • corporate governance;
  • visual literacy;
  • design labour;
  • authorship;
  • provenance;
  • platform independence.

The successful product may ultimately focus on only part of that landscape.

It may become primarily:

  • a Visual Bible manager for creators;
  • a structured brief tool for design teams;
  • a company visual-governance plugin;
  • an internal system used by Mithaq Praxis;
  • a portable standard for visual continuity.

A narrower successful product is better than a broad system whose promises exceed its behaviour.

The philosophy can remain larger than the software.
The essays may carry the wider cultural argument.

The product only needs to perform its chosen part honestly.

The blog series should continue to document changes

This series should not end with the prototype’s announcement.

The more useful continuation would include:

  • what was built;
  • what was cut during implementation;
  • screenshots of the first flow;
  • how the three initial Bibles behaved;
  • where users became confused;
  • which assumptions failed;
  • what designers said;
  • what company users needed;
  • which features were refused;
  • what changed in the roadmap;
  • whether the product remained worth continuing.

A build journal becomes untrustworthy when it records only confirmations.

The prototype should be allowed to contradict earlier articles.
If it does, the contradiction should be documented rather than hidden behind launch language.

The purpose of Mithaq Praxis is not to perform certainty.
It is to examine, build, test, and preserve the reasoning honestly.

The first public demonstration should show the mechanism

When I write about the prototype, the demonstration should not rely mainly on claims such as:

  • more intentional;
  • more human-led;
  • better prompts;
  • consistent visual identity.

It should show the structure.

For example:

Visual Bible

Mithaq Praxis

  • clean institutional environment;
  • muted green, charcoal, paper, warm stone;
  • restrained Islamic modernism;
  • credible near-future technology;
  • no cyberpunk neon;
  • no Algorithm Atelier honeycomb motifs.

Human scene seed

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

New decisions

  • Farah demonstrates the Bible interface;
  • Zayd reviews the inherited continuity panel;
  • analytical but quietly pleased mood;
  • horizontal blog-header composition;
  • prototype remains the focal point.

Temporary variation

  • stronger interface glow at the table than the room normally uses.

Assembled brief

A clear visual specification combining the stored world and the new scene.

The reader should be able to see the product law operating:

The world was carried.
The moment was decided.

That is more persuasive than a large list of features.

After the prototype comes restraint

The existence of a working build will create pressure to add:

  • image generation;
  • automatic scene suggestions;
  • templates;
  • platform buttons;
  • collaboration;
  • dashboards;
  • corporate permissions;
  • visual scoring;
  • AI review.

Some additions may be justified later.

The first discipline after the prototype is to wait long enough to understand what it already does.

  • Does the Bible get reused?
  • Does the brief travel?
  • Does the user return?
  • Does the designer trust it?
  • Does a company learn something about its own visual identity?
  • Does the system remain human-led under ordinary use, not only in carefully written examples?

The product should not outrun the evidence merely because coding agents make expansion technically easy.

Technical ease is not product necessity.

After the prototype comes reading

The prototype itself must be read in the same way this series argues that images should be read.

  • What does it emphasise?
  • What does it hide?
  • Who appears to hold authority?
  • Which actions are easy?
  • Which are discouraged?
  • Does the interface make the Visual Bible feel like the centre, or does the final prompt become the emotional reward?
  • Does it invite users to decide, or lead them toward accepting suggestions?
  • Does the governed workspace clarify responsibility, or make the organisation appear to own every creative decision?
  • Does the decision record support communication, or imply that creative labour must constantly prove itself?

The interface will communicate values beyond the written product laws.

Those values need to be examined.

After the prototype comes another decision

The prototype will not answer the future automatically.

It will produce evidence.

Then I will need to decide:

  • whether to continue;
  • whom to build for first;
  • what to remove;
  • what to rename;
  • which workflow deserves refinement;
  • which requested conveniences cross the product boundary;
  • whether the software remains one product;
  • whether parts should become services, templates, or essays instead;
  • what I am willing to maintain under the name of Mithaq Praxis.

That decision cannot be delegated to Codex, Claude Code, a user poll, or the momentum of a working interface.

They can contribute information.
The responsibility remains mine.

This is consistent with the product’s central argument.

  • A model can produce an output.
  • A prototype can produce evidence.

Neither decides what should happen next.

The prototype is where the philosophy becomes answerable

Before implementation, it is easy to say:

The human supplies the intention.

The prototype must show what happens when the user does not know how to express one.

It is easy to say:

Store what should remain.

The prototype must show what happens when the stored material becomes cluttered, contradictory, or outdated.

It is easy to say:

One composer, different contexts.

The prototype must show whether one workflow can genuinely serve those contexts.

It is easy to say:

Make design labour legible.

The prototype must show whether the record helps designers or burdens them.

It is easy to say:

Refuse to automate meaningful decisions.

The prototype must show whether users still find enough value in what remains.

The build turns philosophy into behaviour.
Behaviour can be tested.

That is why the prototype matters.

The first release is not the conclusion

The Visual Register will not become successful merely because it exists.
Nor will it become a failure because the first users struggle with it.

Its first working form is the beginning of a more difficult phase:

  • observing;
  • listening;
  • comparing;
  • removing;
  • revising;
  • refusing;
  • deciding what evidence means.

The first build gives the product a body.

Use will reveal whether that body can carry the spine we designed.

  • The Visual Bible.
  • The human-written intention.
  • The composer.
  • The readable brief.
  • The visible decision.

Everything else remains open.

After the prototype, the human still decides

The entire project can be summarised through the same sequence it asks of its users:

Intend. Construct. Generate. Read. Decide.

The prototype belongs to the construction stage.

It is not the final decision.

After it exists, I will need to read what was built:

  • what it preserved;
  • what it assumed;
  • what it made easier;
  • what it made harder;
  • what users understood;
  • what they ignored;
  • what should remain;
  • what must change.

Only then can the next version be directed deliberately.

That is the final test of whether The Visual Register is truly a Mithaq Praxis build.

  • Not that AI helped produce it.
  • Not that the interface looks finished.
  • Not that the argument sounds principled.

But that after the prototype appears—polished, functional, and persuasive enough to tempt momentum—the human builder still stops, reads the result, and decides what deserves to continue.

© 2026 • MITHAQ PRAXIS • CC BY-NC-ND 4.0 Unless Otherwise Stated.