PHASE 0202BENEATH THE BRIEF
THE BRIEF IS THE SYMPTOM

You probably do not need a website.
You need the organization behind it to stop fighting itself.

“We need a new website” is often the first visible symptom of a much larger problem. Before designing pages, Unity 314 examines the message, people, processes, rights, data, external systems and AI-related risks those pages must represent.

PROOF ENGINE ONLINEHuman intention · machine production · governance · evidence · memory
Abstract glowing hazard marker wearing a neon construction hat
SOURCE REVIEW NOTE / U314

“Oh yes. This helps enormously. There is gold in that archive, plus several legal and privacy landmines we absolutely must not put on the homepage wearing a glowing neon hat.”

Generated during the Unity 314 source audit. Funny because it is true. Guardrails begin by knowing what must not become marketing copy.
PROJECT REQUEST

Please rebuild our website.

We would like it to look modern.

THE APPARENT REQUEST

A sentence can conceal an entire operating system.

Open the brief. Each fragment reveals a responsibility that the visible interface alone cannot solve.

0hidden systems exposed
SOURCE AUTHORITY

Not every useful thing is ready to become a public claim.

Select a state. The Source Map distinguishes fact, inference, uncertainty, sensitivity and material that should remain private.

CONFIRMEDSafe to use with current evidence and approved wording.
BENEATH THE BRIEF DIAGNOSTIC

Find the problem before funding the wrong solution.

Choose Yes, No, Unknown or Not Applicable. Unknown is useful evidence. It identifies where the Source Map must begin.

01
DIAGNOSTIC LENS

message

Can a first-time visitor explain what the organization does?

Is the primary audience obvious?

Are offers or programs clearly separated?

Does each important page have one meaningful next action?

Are important claims supported by evidence?

02
DIAGNOSTIC LENS

experience

Does the critical journey work properly on a phone?

Can visitors complete important tasks without assistance?

Is navigation understandable without guessing?

Can forms and controls be operated by keyboard?

Does the visual identity represent the actual organization?

03
DIAGNOSTIC LENS

operations

Is somebody responsible for content and updates?

Is there an established process after a form is submitted?

Can staff review, export and manage incoming information?

Can ordinary updates be made without a developer?

Is there a current operating guide?

04
DIAGNOSTIC LENS

integrations

Is the authoritative database known?

Are service accounts owned by the organization?

Are streaming, booking, payment and email providers documented?

Can each external connection be tested independently?

Is there a fallback when an external service is unavailable?

05
DIAGNOSTIC LENS

resilience

Are backups available and tested?

Can the system move to another host?

Are secrets kept outside public files?

Is there a staging environment and known-good release?

Does the site remain understandable when animation or JavaScript is unavailable?

06
DIAGNOSTIC LENS

Rights, Privacy & Safeguarding

Are words, images, recordings and source files owned or licensed for the intended use?

Does the system collect only the personal information the purpose actually requires?

Are vulnerable people, minors or safeguarding obligations involved?

Are retention, deletion and access responsibilities defined?

Could an AI-generated or historical claim be mistaken for current verified fact?

CREATE THE PROBLEM MAP
INFORMATION BOUNDARIES

The public gets the useful truth. The protected system keeps the machinery.

A premium digital system is not only good at revealing things. It is disciplined about what remains private.

01

Public

Approved explanations, verified proof, current offers and safe operating principles.

02

Internal

Working notes, detailed architectures, source maps, review findings and decision records.

03

Sensitive

Personal information, credentials, safeguarding material and restricted partner data.

04

Blocked

Unverified legal claims, proprietary prompts, security logic and material without rights.

PUBLIC CLAIMS LEDGER

Aspiration, policy, legal status and operating proof are not interchangeable.

Open each claim to see whether it is public, held for verification or blocked from publication.

CLAIMSOURCESTATUS
THE CCAN FIELD RECORD

What looked complete was not yet correctly connected.

The purpose of memory is not to pretend failure never occurred. It is to ensure the same failure becomes harder to repeat.

Failure becomes evidence. Evidence becomes a better system.
01
Visual-language mismatch

The operating engine worked, but the first CCAN direction inherited too much of Unity 314’s visual language.

Correction
CCAN received its own black, condensed, neon broadcast identity.
Lesson
A reusable engine must never erase the client’s identity.
02
Data-source mismatch

The visible chart experience was not initially attached to the authoritative CCAN Firebase structure.

Correction
The actual project, database path and song records became the source of truth.
Lesson
A convincing interface is not proof of a correct data connection.
03
Streaming mismatch

A player was created before the exact public Live365 integration was fully verified.

Correction
Streaming was separated conceptually and technically from Firebase.
Lesson
External systems require their own evidence and acceptance test.
04
Deployment mismatch

GoDaddy’s Airo environment and cPanel Node environment behaved differently.

Correction
Separate host-specific packages and compatibility layers were created.
Lesson
Deployment is part of the product.
05
Rights and ownership

Files and services can be technically accessible without being owned, licensed or approved for migration.

Correction
Ownership, permission and source authority are recorded before reuse.
Lesson
Access is not the same as the right to publish or move something.
06
Testing boundary

A local mock can pass while the live external service remains unreachable, blocked or configured differently.

Correction
Local, integration and live-environment proof are reported separately.
Lesson
A test result is only meaningful when its boundary is explicit.
07
Release packaging

A complete project can still fail at upload when the archive structure does not match the host.

Correction
The exact GoDaddy archive is clean-extracted, integrity-tested and validated from its root.
Lesson
The ZIP is part of the product.
THE REAL BRIEF

The brief tells us what you asked for. The system tells us what must actually be built.

Diagnosis is not a delay. It prevents money being spent on the wrong layer of the problem.

See the Unity 314 Method