One Composer, Different Contexts

Published On: June 28th, 2026Last Updated: September 14th, 20264773 words23.9 min readDaily Views: 1Total Views: 12

When I first described The Visual Register by Mithaq Praxis, I divided its use into three modes:

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

The distinction seemed reasonable.

  • A person creating one image for the first time should not face the same density of controls as an experienced artist maintaining a complex visual world.
  • A creator working across books, websites, promotional material, and recurring characters needs access to deeper continuity and visual-direction tools.
  • A company needs shared brand rules, controlled assets, review requirements, and a way to prevent every employee from independently reinventing its visual identity.

Those are genuinely different situations.
But they do not necessarily require three separate creative interfaces.

The more I examined what each user was actually doing, the clearer the underlying structure became:

There is one act of composition occurring in different contexts.

  • Every user still needs to establish what the image is for.
  • Every user still needs to state what should appear.
  • Every user still needs to decide what is happening now.
  • Every user still needs some combination of setting, mood, format, visual hierarchy, continuity, and constraint.

What changes is not the fundamental act.

What changes is:

  • how much has already been decided;
  • how much control the user wants to expose;
  • who owns the persistent visual rules;
  • which decisions may be overridden;
  • whether review or approval is required.

That led to a simpler product structure:

One composer. A Visual Bible may be attached or omitted. Depth expands when needed. Governance sits around the workflow rather than becoming another creative mode.

This is not merely a tidier interface decision.

It reflects the central philosophy of The Visual Register: store what should remain, ask what is new, and do not make the user perform unnecessary work simply because the software has categories available.

The problem with “modes”

Modes can be useful when a product contains fundamentally different activities.

  • A photo editor may need a crop mode and a masking mode.
  • A database tool may distinguish between reading records and editing their schema.
  • A game may have a building mode and a combat mode.

But modes can also become an artificial way of separating users before the product understands what they actually need.

A label such as Basic Mode may imply:

This version is for people who do not know very much.

A label such as Studio Mode may imply:

Serious creators should begin here.

A label such as Corporate Mode may suggest:

Companies require an entirely different creative process.

Those assumptions can become self-fulfilling.

  • The beginner is given an oversimplified tool that cannot grow with them.
  • The experienced user is confronted with every possible field whether or not the current image requires it.
  • The company receives a duplicated interface filled with organisational language, even though its staff are still composing ordinary scenes.

The product begins maintaining three versions of the same logic.
That creates more code, more documentation, more testing, and more opportunities for the interfaces to drift apart.

Worse, it encourages the software to define people too early.

  • A user may be a professional designer creating a very simple icon.
  • A first-time user may have an unusually precise scene in mind and want access to advanced controls.
  • An independent writer may maintain a visual system more complex than that of a small company.
  • A corporate employee may need only a one-off internal image with no elaborate art direction.

The person’s identity does not determine the complexity of every image they make.

The image should determine how much structure is required.

The composer is the constant

At the centre of The Visual Register is one Visual Brief Composer.

It begins with the same required question for everyone:

What do you want to see?

The answer may be:

  • Four adult friends try to balance on one pool float.
  • A researcher presents a prototype to three colleagues.
  • A child returns a library book during a rainstorm.
  • A senior technician welcomes a group of apprentices into the workshop.
  • Farah and Zayd review a systems map in the Mithaq Praxis Research Library.

This line establishes the present intention.

From there, the composer needs to determine what information is already available and what still requires a decision.

It may ask:

  • What is the image for?
  • Who or what is present?
  • What is each subject doing?
  • Where does the scene occur?
  • What should the viewer notice first?
  • What should the image feel like?
  • What format must it serve?
  • What must be included?
  • What must not appear?

Those questions remain relevant whether the user is:

  • making one personal image;
  • maintaining a novel’s visual world;
  • creating material for a professional practice;
  • working inside a company brand;
  • briefing a human designer;
  • preparing instructions for an image generator.

The composer does not need to change its identity each time.
It needs to understand the context around the brief.

Context one: the one-off image

The simplest context contains no Visual Bible.

A person arrives with one image in mind.
They may not have a project name, established palette, recurring characters, or any intention to create related work later.

They write:

An elderly woman repairs a small radio at her kitchen table during a power cut.

The composer has no persistent visual identity to inherit.

It may therefore need to ask more foundational questions:

  • Is the image realistic or illustrated?
  • What time period does the kitchen belong to?
  • Should the scene feel anxious, resourceful, intimate, or nostalgic?
  • Is the radio the main subject, or is the woman?
  • Is the only light coming from a candle, a torch, or a window?
  • What format is required?
  • Is the image for an article, poster, presentation, or personal piece?
  • Are there details that should be avoided?

The user can answer only what matters.
They do not need to create a complete Visual Bible merely to make one image.

This context is important because it remains the widest door into the product.

The Visual Register should not require persistent identity where none exists.
That would turn continuity into a tax.

The product’s philosophy is not:

Every image must belong to a large system.

It is:

Every image should begin with a human intention, and established decisions should be carried forward when they exist.

For a one-off image, very little is inherited.
Most of the relevant decisions are new.

The same composer simply asks more of them.

Context two: the creator with a Visual Bible

A creator may arrive with an established world, body of work, series, or personal visual identity.

They select a Visual Bible before composing the scene.

The Bible may already know:

  • the recurring characters;
  • their faces, proportions, clothing, and accessories;
  • the environment;
  • the architecture;
  • the palette;
  • the preferred media;
  • the emotional register;
  • the recurring motifs;
  • the important exclusions;
  • the details that must not drift.

The creator then writes:

Farah sits alone beneath the fig tree after rain, reading a letter while Zayd watches from the covered walkway.

The composer does not need to ask what Farah and Zayd look like if their character entries are already established.

  • It does not need to ask whether the Bayt contains warm stone, arches, lanterns, or the fig tree.
  • It does not need to reconstruct the relationship between the courtyard and covered walkway.

Those decisions belong to the Bible.

The composer can focus on the present scene:

  • What is the emotional condition of the letter?
  • Is Zayd waiting, concerned, or simply giving her space?
  • Should the viewer see the letter clearly?
  • Is the rain still falling, or has it just stopped?
  • Is this a wide environmental image or an intimate character composition?
  • What is the image intended to accompany?
  • Does this scene use the standard Bayt palette, or a cooler post-rain variation?

The creator still directs the image.
The Bible does not decide what happens beneath the tree.

It prevents the world surrounding that event from being forgotten.

Context three: the governed workspace

A company, studio, publisher, or organisation may also create a Visual Bible.

The Bible may belong to the workspace rather than to one individual.

It may contain:

  • official logos and wordmarks;
  • approved palette;
  • product references;
  • workplace environments;
  • visual tone;
  • accessibility requirements;
  • audience restrictions;
  • representation principles;
  • prohibited imagery;
  • campaign-specific rules;
  • approval requirements.

A staff member writes:

A senior engineer welcomes three new apprentices during their first morning in the workshop.

The composer remains recognisable.

It may ask:

  • Is the image for recruitment, onboarding, an annual report, or internal communication?
  • What should the apprentices feel: confidence, belonging, curiosity, reassurance?
  • What action demonstrates the welcome?
  • Which workshop area should be shown?
  • Is the company product visible?
  • Where will text be placed?
  • Is the scene documentary, illustrative, or aspirational?

The company Bible may automatically supply:

  • the workshop’s approved appearance;
  • uniforms;
  • safety equipment;
  • equipment design;
  • colour palette;
  • logo use;
  • representation rules;
  • image style;
  • restrictions around confidential machinery.

The staff member does not manually paste the brand guide.
The designer does not need to ask which logo file is current.

The generator is not allowed to invent a blue-glass laboratory that bears no resemblance to the organisation.
But the company Bible still does not decide what today’s image is about.

The requester supplies the present communication need.

Governance controls the inherited identity.
The composer brings both together.

Corporate is a workspace condition, not a creative personality

This distinction prevents a great deal of unnecessary product complexity.

A company employee does not necessarily require a special “corporate creativity” interface.

They may be creating:

  • an illustration;
  • a staff portrait concept;
  • a product scene;
  • an event banner;
  • a report cover;
  • a training image;
  • an internal announcement.

These are still visual briefs.
The company’s difference lies in the environment around the work.

For example:

Ownership

The Company Visual Bible may be owned by the organisation.

Permissions

Some users may view and apply rules but not edit them.

Locked continuity

Official logos, product designs, and safety requirements may not be overridden.

Review

Certain outputs may require approval before publication.

Accountability

Revision notes may need to identify who changed or approved the brief.

Separation

An employee’s private Visual Bibles should not become company property merely because they use the same software account.

These are governance questions.
They belong to the workspace, account, and permission system.
They should not force the composer itself to become a separate product.

Basic and Studio are depths, not doors

The same reasoning applies to Basic and Studio use.

The difference is real, but it is fluid.

A guided user may need only:

  • scene;
  • purpose;
  • subjects;
  • action;
  • setting;
  • mood;
  • format;
  • constraints.

An advanced user may also want:

  • exact subject blocking;
  • visual hierarchy;
  • camera position;
  • shot size;
  • lens character;
  • depth of field;
  • lighting direction;
  • surface materials;
  • atmosphere;
  • foreground framing;
  • negative space;
  • palette overrides;
  • treatment-specific notes.

The user should be able to open those controls when needed.
They should not have to abandon one workflow and restart in another.

This is progressive disclosure.

The composer begins small.
Additional depth becomes available without becoming mandatory.

A scene may start as:

Four women are sharing breakfast in a shallow infinity pool.

The essential composer establishes:

  • four distinct adult subjects;
  • relaxed friendship;
  • floating breakfast tray;
  • infinity-pool environment;
  • soft morning atmosphere;
  • vertical editorial format.

The user may then decide they want more control and expand:

  • two women sit on the submerged ledge;
  • one floats on her back nearby;
  • one steals fruit from another;
  • low eye-level camera near the water;
  • sea horizon placed in the upper third;
  • sun glare across the water;
  • pale stone architecture kept secondary;
  • no title text;
  • no glamour posing.

Nothing about the underlying workflow changed.

The user simply decided the scene required more precision.

Simplicity is not the absence of thought

A smaller composer should not be mistaken for a thoughtless one.

The goal is not to reduce every request to:

Subject + style + Generate.

A guided interface can still require meaningful decisions.

It can ask plain-language questions rather than technical ones.

Instead of:

Select lens focal length.

it may ask:

Should the viewer feel close to the people, or see more of the surrounding place?

Instead of:

Select key-light hardness.

it may ask:

Should the light feel soft and calm, or bright and sharply defined?

Instead of:

Select compositional hierarchy.

it may ask:

What should the viewer notice first?

The system can translate answers into useful craft language.
The user does not need to know every professional term before making a decision.

But the decision should still be theirs.

Simplicity should remove jargon where it obstructs participation.
It should not remove the need to decide what the image means.

Advanced control is not automatically better

The opposite error is also possible.

A product may appear sophisticated because it exposes:

  • sliders;
  • numerical values;
  • lens settings;
  • lighting diagrams;
  • technical terminology;
  • long negative prompts;
  • dozens of style parameters.

That does not guarantee a stronger image.

A user can select many controls without understanding why they matter.

An over-specified brief may also become contradictory.

For example:

  • intimate close-up;
  • full-body composition;
  • expansive architecture;
  • shallow depth of field;
  • every background detail clearly visible.

The user has made more selections, but not necessarily a more coherent direction.

The composer should therefore help advanced users see relationships among decisions.

It might warn:

A tight close-up will reduce how much of the environment can be shown.

Or:

Strong background blur may conflict with your requirement that the architecture remain clearly readable.

The purpose of expanded controls is not to make the brief longer.
It is to make relevant visual decisions more precise.

The same user may need different depths on different days

I may use The Visual Register to create:

  • a small blog thumbnail;
  • a recurring character portrait;
  • a full environment render;
  • a software interface demonstration;
  • a book-series visual;
  • a corporate article header;
  • a multi-character action scene.

I should not be permanently classified as a Studio user and forced through every control for all of them.

For a small icon, I may need:

  • subject;
  • style;
  • palette;
  • transparent background;
  • square format.

For a complex Mithaq Praxis scene, I may need:

  • inherited architecture;
  • Farah and Zayd’s character canon;
  • workstation layout;
  • screen content;
  • interaction blocking;
  • camera angle;
  • practical lighting;
  • environmental hierarchy;
  • technology constraints;
  • blog-header composition.

The person has not changed.
The task has.

A good composer responds to the task.

Different contexts change what is inherited

The most important practical difference among contexts is inheritance.

One-off personal brief

Very little is inherited.

The user establishes most of the visual direction now.

Personal or creative Bible

Characters, worlds, motifs, environments, and stylistic defaults are inherited.

The user focuses on the present event and deliberate variations.

Governed organisational Bible

Brand identity, official assets, restrictions, and approved defaults are inherited.

Some fields may be locked.

Campaign or project child profile

Temporary rules may be inherited beneath a parent Bible.

For example:

Company Bible
Annual Report Campaign
Research Section
Present image brief

Or:

Bayt al-ʿAhd Bible
Summer Rituals Collection
Sunflower Desert Scene
Present composition

The composer remains one place.
Its input stack changes.

The composer must show its sources

When a brief combines several layers, the user should be able to see where the decisions came from.

A completed project might distinguish:

Human scene seed

Four adult women walk together along the shoreline after swimming. One splashes another while the other two turn back laughing.

Inherited from the Summer Chaos Bible

  • four established characters;
  • distinct faces and hair;
  • coordinated adult swimwear;
  • affectionate non-sexual friendship;
  • Mediterranean coastal environment;
  • realistic editorial photography;
  • no duplicated subjects;
  • natural body proportions.

Chosen for this brief

  • late-afternoon light;
  • towels carried loosely;
  • sea wind;
  • movement prioritised over posing;
  • vertical 2:3 composition.

Temporary override

  • cooler sea-blue palette instead of the collection’s usual sun-warmed terrace palette.

Technical translation

  • full-body shoreline framing;
  • moderate depth of field;
  • horizon placed high enough to preserve foreground movement.

This visibility prevents the final brief from becoming an opaque paragraph in which the user cannot tell what the tool decided.

It also supports correction.

If the result is wrong, the user can ask:

  • Was the Bible inaccurate?
  • Was the new scene unclear?
  • Was an override misapplied?
  • Was the technical translation unsuitable?
  • Did the generator ignore the brief?

Without visible layers, every failure looks like “the prompt did not work.”

One composer also improves learning

A unified composer allows the learning layer to remain consistent.

A beginner may first encounter:

What should the image feel like?

They might select:

calm and concentrated.

The system may then show an optional explanation:

Calm concentration is often supported by controlled posture, reduced background activity, soft directional light, and a clear focal task.

Later, the same user may open expanded controls and directly select:

  • soft side light;
  • limited background activity;
  • medium-wide framing;
  • restrained palette.

The tool has not moved them into a new product.
It has allowed their vocabulary and control to grow within the same workflow.

This supports a more honest educational philosophy.
The user does not “graduate” from Basic Mode into a professional identity.

They gradually gain access to, or confidence with, deeper choices.

A unified interface avoids performative complexity

Corporate software often becomes complicated because complexity signals seriousness.

A product may add:

  • dashboards;
  • role matrices;
  • multiple creation modes;
  • approval tabs;
  • policy pages;
  • separate campaign builders;
  • enterprise terminology.

Some of these may eventually be necessary.

They should not be built merely to make the product look suitable for organisations.

A small team may need only:

  • one shared Visual Bible;
  • several users;
  • locked brand assets;
  • a draft or approved status;
  • a revision note.

That can exist around the same composer used by an individual.
The product should earn complexity through real organisational need.

It should not perform enterprise readiness by making simple work harder.

The organisation should not own every decision

A governed workspace also needs clear boundaries.

The company may own:

  • its brand Bible;
  • official assets;
  • campaign profiles;
  • briefs commissioned as part of employment;
  • approval records.

It should not automatically absorb:

  • an employee’s unrelated personal Visual Bibles;
  • private fictional worlds;
  • personal characters;
  • independent creative projects;
  • saved preferences that do not belong to company work.

The context should be explicit.

A user should know whether they are composing inside:

  • a personal workspace;
  • a shared creative project;
  • an organisational workspace.

This is another reason Corporate should not be treated as a button inside the composer.

Governance begins before the brief.
It concerns whose context the brief belongs to.

A creator may also work inside governed contexts

The boundaries between “artist” and “corporate user” are not clean.

  • An illustrator may maintain a personal Visual Bible and also work from a client-owned brand Bible.
  • A writer may build a fictional world while using a publisher’s campaign profile for promotional material.

A designer may have:

  • personal projects;
  • studio projects;
  • client projects;
  • company workspaces.

The same person can move among several contexts.
They do not become a different kind of human each time.

The product should therefore allow them to change workspace and attached Bible without learning a different composer.

Their authorship, permissions, and inherited constraints change.
Their basic act of visual direction does not.

The composer can reveal where responsibility sits

A unified workflow can make responsibility clearer.

Consider a company image.

The organisation decides

  • brand identity;
  • approved palette;
  • logo use;
  • product accuracy;
  • audience standards;
  • prohibited imagery.

The requester decides

  • why the image is needed;
  • what it should communicate;
  • who or what should appear;
  • where it will be used.

The designer or creator decides

  • visual concept;
  • composition;
  • hierarchy;
  • framing;
  • lighting;
  • how the brief becomes a workable image.

The reviewer decides

  • whether the result meets its purpose;
  • whether brand and policy requirements were followed;
  • whether revision is needed.

The generator interprets

  • the written and visual instructions it receives.

These responsibilities may overlap in a small team.

One person may hold several roles.
But the composer can still preserve which decisions came from which layer.

This is useful because organisations often collapse every responsibility into:

Ask the AI to make something.

The Visual Register can make the missing decisions visible before the designer is blamed for not reading an unspoken intention.

A Bible should reduce the form

The strength of the Visual Bible can be measured partly by how much unnecessary work it removes from the composer.

A strong company Bible may already know:

  • brand palette;
  • photography treatment;
  • office environment;
  • employee attire;
  • logo policy;
  • product depiction;
  • standard aspect ratios;
  • common exclusions.

When a user creates a new brief, those fields should appear as inherited summaries.
They should not be presented as unanswered questions.

Similarly, a rich creative Bible may already know:

  • the characters;
  • the environment;
  • the motifs;
  • the default emotional register;
  • the medium.

The user should be asked only for the present event and any deliberate departures.

If attaching a Bible makes the form longer, the product has misunderstood its own purpose.
The Bible should make the composer quieter.

Context should affect defaults, not truth

A governed company workspace may preselect a company Bible.
A creator workspace may remember the last used world.

A one-off user may begin with no Bible.

These defaults can save time.
They should not become invisible assumptions.

The user should always be able to see:

  • which Bible is attached;
  • which version is active;
  • whether a campaign profile is applied;
  • which rules are locked;
  • whether the brief is personal or organisational.

This prevents context errors.

  • A creator should not accidentally apply the Bayt palette to Mithaq Praxis.
  • An employee should not accidentally create a company asset using a personal style profile.
  • A publisher should know whether a brief is attached to the parent imprint or one specific series.

One composer does not mean one undifferentiated context.
It means one consistent way of making the context visible and useful.

The first prototype does not need full governance

The early build should demonstrate the context model without attempting to solve every permission problem.

For the prototype, the contexts may be as simple as:

Personal brief

No Bible required.

Personal Bible brief

The user selects one of their Visual Bibles.

Shared or governed brief

The user selects a workspace Bible containing several locked fields.

The interface can show:

  • inherited;
  • editable;
  • locked;
  • overridden.

That is enough to test the logic.

The first build does not need:

  • enterprise identity providers;
  • complex departmental roles;
  • multi-stage legal approval;
  • global policy engines;
  • exhaustive audit trails.

Those belong later, if real users demonstrate that they need them.

The prototype must prove that the same composer can behave coherently under different amounts of inheritance and control.

A practical example: the same request in three contexts

Consider the scene:

A group gathers around a table to review a new prototype.

One-off brief

The composer may need to ask:

  • What kind of group?
  • What is the prototype?
  • Where are they?
  • Is the tone excited, analytical, tense, or formal?
  • What does the room look like?
  • What visual style is intended?
  • Who is the main subject?
  • What format is needed?

Almost everything is new.

Mithaq Praxis brief

The Bible already knows:

  • the institution;
  • the Systems Laboratory;
  • the palette;
  • Farah and Zayd;
  • the technology language;
  • the architectural materials;
  • the avoid list.

The composer asks:

  • Which prototype?
  • Who else is present?
  • Who is demonstrating it?
  • Is the mood exploratory or conclusive?
  • What should appear on the interface?
  • Is the image for a build note or product page?
  • How much of the laboratory should be visible?

Most identity is inherited.

Company brief

The Company Bible already knows:

  • official workplace;
  • staff attire;
  • product design;
  • brand palette;
  • safety requirements;
  • confidential elements that cannot be shown.

The composer asks:

  • Which department?
  • Who is the audience?
  • What should the image communicate?
  • Is the prototype approved for public depiction?
  • Does the final asset require headline space?
  • Who must review it?

The scene remains similar.

The context changes what the composer knows, what it may ask, and what it must protect.
That is one product behaving intelligently—not three products pretending the scene itself has changed.

A practical example: different depths in one context

Now consider a creator making two images within the same Visual Bible.

Image one: a simple character card

The creator writes:

Farah standing against a plain warm-paper background.

The Bible supplies her character canon and attire.

The composer may need only:

  • expression;
  • pose;
  • crop;
  • intended format;
  • whether accessories are visible.

Expanded cinematography controls remain closed.

Image two: a complex environment scene

The creator writes:

Farah and Zayd cross the Mithaq Praxis Threshold Gallery while a delivery drone arrives through the upper courtyard opening.

The same Bible is attached.

This time the user may open:

  • architecture;
  • character blocking;
  • camera height;
  • drone placement;
  • depth layers;
  • light direction;
  • movement;
  • visual hierarchy;
  • material reflections;
  • technology behaviour.

The same user, same Bible, same composer.
Different image complexity.

That is why depth should be fluid.

The composer should not make every choice equally important

A common problem with forms is that every field appears to carry the same weight.

But visual decisions have hierarchy.

For a particular image, the essential decisions may be:

  • the action;
  • the relationship between subjects;
  • the intended audience;
  • the required product detail.

The exact lens character may be secondary.

For another image, the camera perspective may be the entire concept.
The composer should therefore help the user identify what matters most.

It may ask:

Which three details would make the image wrong if they were missing?

Or:

What must the viewer understand immediately?

This is especially useful in group scenes, corporate communication, and small-format imagery where not every detail can receive equal emphasis.

A unified composer can keep this hierarchy visible across contexts.

The output remains a brief, not a confession of settings

Whether the user works alone or inside a company, the primary output should be readable.

It should not look like a raw database dump.

A strong brief may contain:

Purpose

What the image must accomplish and where it will be used.

Scene

The human-written intention, clarified without losing its meaning.

Subjects and action

Who appears and what each person is doing.

Environment

Where the scene occurs and which relevant details are inherited.

Visual direction

Mood, composition, hierarchy, light, and treatment.

Continuity

Rules drawn from the attached Bible.

Overrides

Intentional departures for this scene.

Constraints

What must not appear or change.

Output

Aspect ratio, placement, text space, and technical needs.

  • A designer should be able to read it.
  • A manager should understand it.
  • A generator may be instructed from it.

The brief remains useful outside The Visual Register.
That portability is important because the product should organise the work, not imprison it.

One composer reinforces the product laws

The unified structure allows the two central laws to remain visible.

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

The first field remains human-written in every context.

  • A company Bible does not invent the campaign scene.
  • A creative Bible does not invent the emotional event.
  • An advanced interface does not replace the user’s purpose with technical settings.

And:

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

  • A one-off image has little stored continuity, so the composer asks more.
  • A rich creative Bible carries more, so the composer asks less.
  • A governed workspace inherits organisational rules and restricts who can change them.

The logic remains stable because the composer is not organised around user stereotypes.
It is organised around what is already known.

Different contexts, one act of direction

A creator preserving an inner world, a designer working for a client, a communications officer inside a company, and a person making one image for a presentation may appear to be using very different tools.

At the level of infrastructure, they may need different ownership, permissions, continuity, and review.
At the level of visual direction, they are still confronting the same essential questions:

  • What am I trying to show?
  • Why does it need to exist?
  • What has already been decided?
  • What is new here?
  • What must remain consistent?
  • What may change?
  • What should another person understand from the brief?

The Visual Register does not need three competing creative identities to answer those questions.

It needs one composer capable of listening to context.

The product should expand around the work, not before it

This became the final architectural principle for this part of the build:

Do not make the user choose the complexity of the product before they understand the complexity of the image.

  • Let them begin with the scene.
  • Let the selected Visual Bible reveal what is already known.
  • Let the workspace reveal what is governed.
  • Let optional controls appear when the image requires them.
  • Let the brief grow only as far as the work needs.

That is how The Visual Register can serve a person making one image, a creator maintaining a world, and an organisation protecting a visual identity without becoming three disconnected products.

One composer.
Different contexts.

The same human responsibility at the centre.

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