Why This Chapter Matters

When the World Wide Web first became popular, websites were primarily designed to answer one simple question:

What does this page say?

Over the years, search engines became increasingly sophisticated. They began analysing page titles, headings, keywords, links, images and hundreds of other signals to understand the subject of a webpage.

Today, however, the digital world has entered another stage.

Modern AI systems are no longer satisfied with understanding only what a page says. They increasingly try to understand:

• Who created this information? 

• Why should this person be trusted? 

• What qualifies them to speak on this subject? 

• Is this organisation recognised in this field? 

• Has this person written consistently about this topic? 

• Has anyone reviewed or verified this information? 

• Does the website itself demonstrate expertise over time? 

In other words, information is now evaluated not only by its content but also by the credibility of the people and organisations behind it.

This represents a major change in how knowledge is presented on the internet.

Many websites still display nothing more than:

Written by Admin

or

Posted by Editor

Sometimes there is not even an author's name.

From a reader's perspective, this immediately raises questions.

Who is "Admin"?

Is this person a scientist?

A journalist?

A student?

A marketing executive?

An intern?

A software developer?

Nobody knows.

The article may be excellent, but the website provides almost no information that helps establish confidence.

The same problem applies to AI systems.

An AI system can analyse the language used in an article, but it also attempts to understand the identity and credibility of the person or organisation producing that knowledge.

This does not mean famous people should automatically be trusted.

Nor does it mean unknown people should be ignored.

Rather, it means that websites should honestly present whatever information is available about the creator of the knowledge so that readers can make informed judgments.

Authority should never be manufactured.

It should be demonstrated.

For programmers, this creates an entirely new responsibility.

The programmer is no longer building pages alone.

The programmer is helping build the organisation's Knowledge Trust Architecture.

Every article should connect to its author.

Every author should connect to their areas of expertise.

Every area of expertise should connect to related articles, reports, videos, research papers and projects.

Reviewers, contributors and organisations should also become part of this connected knowledge network.

Gradually, the website stops being a collection of isolated pages.

Instead, it becomes a living record of people, organisations, expertise and accumulated knowledge.

Visitors gain confidence because they understand who is speaking.

AI systems gain confidence because they understand how knowledge is connected.

Future employees inherit institutional knowledge because expertise remains attached to the people who created it.

This chapter explains how programmers can build websites that communicate not only information, but also credibility, responsibility and authority.

 ________________________________________

Rule 6.1; Identify the Real Author Behind Every Important Knowledge Asset

The Rule

Every significant piece of knowledge should clearly identify the person or organisation primarily responsible for creating it.

Why This Rule Exists

Knowledge does not appear automatically.

Someone researches.

Someone observes.

Someone analyses.

Someone writes.

Someone explains.

Someone shares years of professional experience.

The website should recognise that contribution.

Displaying only "Admin" or "Editor" hides the real source of knowledge.

Suppose two websites publish exactly the same article.

Website A displays:

Author: Admin

Website B displays:

Author: Dr. Meera Sharma

Plant Pathologist

28 years' experience in crop disease management

The words may be identical.

The reader's confidence is not.

Knowing who created the knowledge helps visitors judge its relevance and reliability.

It also encourages accountability.

When people proudly attach their names to their work, they generally take greater care in ensuring its quality.

What Most Programmers Do

Many content management systems automatically assign the logged-in user's account as the author.

The displayed name therefore becomes:

• Admin 

• Webmaster 

• Content Team 

• Office Staff 

• Marketing Department 

In some organisations, multiple employees share one login.

Consequently, hundreds of unrelated articles appear to have been written by the same anonymous "Admin."

Years later, nobody remembers who actually created the content.

The organisation loses an important part of its intellectual history.

Better Practice

Every important content type should include an Author field.

This applies not only to articles but also to:

• reports, 

• manuals, 

• white papers, 

• technical notes, 

• research summaries, 

• videos, 

• podcasts, 

• presentations, 

• downloadable documents, 

• case studies, 

• and major FAQs. 

Where an individual author genuinely exists, identify that person.

Where knowledge is created collectively, identify the responsible organisation while also listing the principal contributors where appropriate.

If anonymity is necessary for legal, security or organisational reasons, explain it honestly rather than simply writing "Admin."

For example:

Prepared by the Technical Advisory Team. Individual names are withheld because this document represents the official position of the organisation.

The reader now understands why no individual author is shown.

Programming Impact

This requires:

• dedicated author fields, 

• author identifiers, 

• relationships between authors and content, 

• support for multiple authors where required, 

• clear author display templates, 

• and structured author metadata. 

________________________________________ 

Rule 6.2; Build Complete Author Profile Pages

The Rule

An author's name should always connect to a comprehensive profile page that explains their background, expertise and contributions.

Why This Rule Exists

A name alone tells us very little.

Readers naturally ask:

Who is this person?

Why are they writing about this subject?

What experience do they have?

Have they worked in this field for five months or thirty years?

Have they written anything else?

Do they possess practical experience or only theoretical knowledge?

Without answers, the author's identity remains incomplete.

A profile page transforms a name into a professional identity.

More importantly, it allows the website to build credibility gradually.

Every new article strengthens the author's profile.

Every new project enriches their experience.

Every new publication expands their body of work.

Over time, the profile itself becomes an important knowledge asset.

Example

Instead of:

Mukesh Gupta

The profile may present:

Mukesh Gupta

Founder, Hello Kisan

Over three decades of experience in food processing, agricultural value chains and cost assessment.

Advisor to governments, development agencies and food businesses.

Special areas of interest:

• Food Cost Assessment 

• Organic Agriculture 

• Fruit and Vegetable Processing 

• Farm Management 

• Urban Farming 

• Entrepreneurship Development 

Publications:

• 145 Articles 

• 28 Technical Reports 

• 12 Frameworks 

• 46 Presentations 

Current Projects:

• Food Cost Assessment Engine 

• GreenJobs Digital 

• Hello Kisan Future of Food 

The profile immediately communicates context.

What Most Programmers Do

The author profile contains:

• one passport photograph, 

• one sentence of biography, 

• perhaps a social media link, 

• and nothing else. 

After several years the profile remains unchanged even though the author's work has expanded considerably.

In some cases there is no profile page at all.

The author's name is plain text without any link.

Better Practice

A proper author profile should evolve continuously.

It may include:

• full name, 

• photograph, 

• professional designation, 

• educational qualifications, 

• areas of expertise, 

• years of experience, 

• important projects, 

• publications, 

• books, 

• research, 

• patents, 

• awards, 

• memberships, 

• interviews, 

• media appearances, 

• languages, 

• contact information where appropriate, 

• and links to related work. 

Not every author requires every field.

The objective is not to create lengthy biographies.

The objective is to provide enough information for visitors to understand why the person's knowledge deserves attention.

Programming Impact

This affects:

• author database design, 

• profile templates, 

• reusable author components, 

• search functionality, 

• internal linking, 

• author archives, 

• and future knowledge management. 

 ________________________________________

Rule 6.3; Connect Every Knowledge Asset to Its Creator

The Rule

Every significant knowledge asset should be connected to the person or organisation responsible for creating it.

Why This Rule Exists

Knowledge does not exist in isolation.

An author may write:

• articles, 

• reports, 

• manuals, 

• presentations, 

• case studies, 

• newsletters, 

• books, 

• videos, 

• interviews, 

• research papers, 

• policy notes, 

• and training material. 

If each of these remains disconnected, visitors never appreciate the depth of the author's expertise.

Imagine a professor who has written fifty papers on irrigation engineering.

If every paper appears independently without linking back to the professor's profile, the website repeatedly loses the opportunity to demonstrate accumulated expertise.

The same applies to organisations.

Every publication contributes to institutional credibility.

Only if these contributions are connected can visitors appreciate the full body of work.

What Most Programmers Do

Articles remain connected only to categories.

Reports remain stored in download folders.

Videos remain inside media galleries.

Presentations remain hidden in separate libraries.

Nothing connects them through the common thread of authorship.

Consequently, years of accumulated knowledge appear fragmented.

Better Practice

Whenever an author profile is opened, the visitor should immediately discover everything that person has contributed.

For example:

Articles by this Author

Research Reports

Videos

Case Studies

Presentations

Downloads

Projects

Similarly, when reading an article, the reader should be able to navigate directly to the author's broader body of work.

Knowledge should become interconnected rather than isolated.

Over time, this creates a continuously expanding knowledge network rather than a simple content archive.

For AI systems, these relationships also help establish topical expertise.

Repeated contributions on a specialised subject demonstrate sustained competence far more effectively than a single impressive biography.

Programming Impact

This requires:

• many-to-many relationships between authors and content, 

• author archives, 

• dynamic content listings, 

• internal knowledge graphs, 

• efficient database indexing, 

• reusable relationship components, 

• and scalable linking structures. 

 ________________________________________

Chapter 6 – Part 1 Ends Here

The next part will continue with:

• Rule 6.4: Distinguish Between Authors, Contributors, Reviewers and Editors 

• Rule 6.5: Build Topic-Based Expertise Rather Than Generic Profiles 

• Rule 6.6: Connect Knowledge to the Organisation Behind It 

These three rules will extend the idea from individual credibility to institutional credibility, completing the next layer of the website's Knowledge Trust Architecture.

________________________________________

Rule 6.4; Clearly Distinguish Between Authors, Contributors, Reviewers and Editors

The Rule

A website should accurately identify the role each person played in creating a knowledge asset. The author, reviewer, editor, contributor and other participants should not all be treated as though they performed the same function.

Why This Rule Exists

Creating reliable knowledge is often a collaborative process.

The person who writes an article is not necessarily the person who verifies its technical accuracy.

Similarly, the person who edits the language may not possess subject expertise.

A photographer may provide valuable visual evidence without writing a single word.

A statistician may prepare the data that forms the basis of an entire report.

A translator may make the knowledge accessible to a completely different audience.

Each person's contribution deserves proper recognition.

Equally important, readers should understand how the knowledge has been developed.

Consider a medical advisory published by a hospital.

The article may have been written by a medical communication specialist.

Its scientific content may have been reviewed by three senior doctors.

Its illustrations may have been prepared by a medical illustrator.

Its language may have been simplified by an editor.

Each individual performed a different role.

Treating all of them simply as "Author" hides the quality assurance process that stands behind the publication.

The same principle applies to agriculture, engineering, food technology, education, finance and every other professional field.

Understanding who created, reviewed and approved the knowledge helps readers and AI systems understand how trustworthy the information is likely to be.

What Most Programmers Do

Most websites provide only one field called:

Author

Everyone else disappears.

Reviewers remain invisible.

Editors receive no acknowledgement.

Photographers are forgotten.

Researchers remain anonymous.

The result is that years of collaborative work become attributed to a single individual.

Sometimes the opposite also occurs.

Everything is attributed to "Editorial Team", making it impossible to know who actually contributed.

Neither approach serves the reader well.

Better Practice

The CMS should support different roles for different people.

For example:

Author

Prepared the original content.

Reviewer

Verified technical accuracy.

Editor

Improved language, readability and presentation.

Contributor

Provided research, data, interviews or specialised inputs.

Translator

Prepared versions in additional languages.

Illustrator or Photographer

Created visual material.

Approver

Authorised publication on behalf of the organisation where necessary.

Not every page requires every role.

However, the system should allow these relationships whenever they are appropriate.

Example

Author:

Dr. Meera Sharma

Reviewed by:

Food Safety Advisory Committee

Edited by:

Editorial Team

Photography:

Rajesh Singh

The reader immediately understands that several professionals contributed to the final publication.

Programming Impact

This requires:

• multiple contributor roles, 

• role-specific database relationships, 

• flexible content templates, 

• contributor profile links, 

• workflow integration, 

• approval records, 

• and structured metadata representing each contribution. 

 ________________________________________

Rule 6.5; Build Topic-Based Expertise Rather Than Generic Author Profiles

The Rule

Help visitors understand not only who the author is, but also what subjects the author genuinely specialises in.

Why This Rule Exists

Professional expertise is rarely universal.

An agricultural engineer may be highly knowledgeable about irrigation systems but not about dairy nutrition.

A chartered accountant may understand taxation exceptionally well but have limited expertise in food microbiology.

Readers naturally want to know whether the author's experience matches the subject they are reading.

General biographies often fail to answer this question.

Suppose two different authors both have impressive careers.

One has spent thirty years designing fruit processing plants.

The other has spent thirty years studying soil microbiology.

If both biographies simply state:

"Thirty years of professional experience"

the reader still cannot determine who is more suitable to discuss a particular topic.

Topic-based expertise solves this problem.

Instead of presenting experience as one large paragraph, the website presents expertise in clearly defined knowledge areas.

This helps readers discover relevant work.

It also helps AI systems recognise patterns of consistent contribution within specialised subjects.

Over time, repeated work on the same topic builds genuine authority.

What Most Programmers Do

The author profile contains one biography written years ago.

Every article links to exactly the same paragraph.

Whether the person writes about food safety, farm machinery or export marketing, nothing changes.

The biography remains static while the person's expertise continues to grow.

The website never demonstrates how knowledge has accumulated across different subjects.

Better Practice

Allow each author profile to identify one or more recognised areas of expertise.

For example:

Primary Expertise

Food Cost Assessment

Food Processing Technologies

Agricultural Value Chains

Organic Agriculture

Farm Business Planning

Urban Farming

Every article should automatically strengthen one or more of these areas.

When a visitor selects:

Food Cost Assessment

the website may display:

• Articles 

• Reports 

• Videos 

• Presentations 

• Case Studies 

• Frequently Asked Questions 

• Projects 

related specifically to that topic.

The profile gradually evolves into a map of professional knowledge rather than a simple résumé.

Visitors discover expertise.

Organisations showcase their intellectual capital.

AI systems recognise consistent subject authority.

Programming Impact

This requires:

• expertise taxonomy, 

• author-topic relationships, 

• dynamic topic pages, 

• automatic content aggregation, 

• filtering by expertise, 

• internal recommendation engines, 

• and scalable knowledge mapping. 

 ________________________________________

Rule 6.6; Connect Knowledge to the Organisation Behind It

The Rule

Knowledge should be connected not only to individuals but also to the organisations responsible for supporting, funding or publishing that knowledge.

Why This Rule Exists

Professional knowledge is often developed within organisations rather than by isolated individuals.

Research institutes.

Universities.

Government departments.

Consulting firms.

Non-government organisations.

Companies.

Professional societies.

Think tanks.

Each contributes experience, infrastructure, funding and institutional memory.

When this relationship is invisible, much of the knowledge loses important context.

Suppose a technical manual has been prepared by an engineer working for a food technology institute.

Knowing the institute immediately provides additional information.

The reader understands the organisational environment in which the work was developed.

Similarly, when a report originates from a government department or internationally recognised institution, readers naturally evaluate it differently from an anonymous webpage.

Organisational identity therefore strengthens transparency rather than replacing individual responsibility.

Both are important.

What Most Programmers Do

The organisation's name appears only in the website header or footer.

Individual articles contain no visible connection to departments, laboratories, projects or institutional programmes.

As a result, the organisation's accumulated expertise remains hidden.

Visitors cannot appreciate the scale or diversity of work being undertaken.

Better Practice

Each significant knowledge asset should be capable of displaying information such as:

Publishing Organisation

Department

Research Centre

Project

Funding Organisation

Partner Organisations

Programme Name

Example

Published by:

Hello Kisan – Future of Food

Knowledge Vertical:

Food Cost Assessment

Supported by:

SNG Memorial Fund

Project:

Open Food Cost Transparency Initiative

The article immediately becomes part of a broader organisational knowledge system.

Visitors understand not only who wrote the content but also the institutional framework supporting it.

Programming Impact

This requires:

• organisation profiles, 

• department records, 

• project relationships, 

• organisational hierarchies, 

• partner databases, 

• structured organisational metadata, 

• and reusable institutional components. 

 ________________________________________

Rule 6.7; Never Publish Important Knowledge Under Anonymous Identities

The Rule

Avoid publishing significant knowledge under vague identities such as "Admin", "Editor", "Staff" or "Team" unless there is a genuine and clearly explained reason.

Why This Rule Exists

Anonymity reduces accountability.

Readers naturally place greater confidence in information when they understand who created it and why.

The label "Admin" communicates almost nothing.

It does not describe qualifications.

It does not indicate experience.

It does not establish responsibility.

Most importantly, it prevents the organisation from building long-term intellectual credibility.

Every anonymous article is a lost opportunity to strengthen both individual and institutional authority.

There are occasions where anonymity is justified.

Legal investigations.

Whistleblower protection.

Sensitive security information.

Official organisational statements.

In such cases, the website should explain why individual names are not disclosed.

Transparency about anonymity is better than unexplained anonymity.

What Most Programmers Do

The CMS automatically inserts the login account.

Hundreds of pages eventually appear under "Admin."

No effort is made to identify actual contributors.

Years later, even the organisation itself may no longer know who prepared the original material.

Better Practice

Create proper author records.

Transfer ownership when staff members leave.

Maintain historical attribution.

Where anonymity is unavoidable, display a meaningful explanation instead of a generic label.

Programming Impact

This requires:

• author management, 

• historical attribution, 

• controlled identity changes, 

• administrative workflows, 

• migration tools, 

• and permanent author identifiers. 

 ________________________________________

Rule 6.8; Help Humans and AI Understand Knowledge Authority

The Rule

Design the website so that relationships between people, organisations, expertise and knowledge are understandable to both visitors and machines.

Why This Rule Exists

Humans naturally recognise relationships.

If a visitor sees that an agricultural scientist has written fifty articles on irrigation over twenty years, they immediately recognise expertise.

AI systems need these relationships to be explicitly represented.

The website should therefore communicate not merely isolated facts but connected knowledge.

Think of the website as a network.

A person belongs to an organisation.

The organisation undertakes projects.

Projects produce reports.

Reports reference datasets.

Datasets support articles.

Articles are reviewed by experts.

Videos explain the same concepts.

Case studies demonstrate practical application.

Together they form an interconnected knowledge ecosystem.

The richer these relationships become, the easier it becomes for both humans and AI to understand the depth of organisational expertise.

What Most Programmers Do

Every page functions independently.

Relationships exist only inside the minds of the content creators.

The website never exposes them.

Consequently, valuable organisational knowledge remains fragmented.

Better Practice

Create structured relationships throughout the website.

Author

↓

Expertise

↓

Organisation

↓

Project

↓

Article

↓

Video

↓

Report

↓

Case Study

↓

Related Knowledge

Each connection strengthens discoverability.

Each connection strengthens trust.

Each connection strengthens future reuse.

Programming Impact

This influences:

• structured data, 

• internal linking, 

• entity relationships, 

• recommendation systems, 

• search architecture, 

• knowledge graphs, 

• APIs, 

• and AI-ready metadata. 

 ________________________________________

Rule 6.9; Build Reputation That Grows with Every Contribution

The Rule

Design the website so that every meaningful contribution strengthens the long-term reputation of both the individual and the organisation.

Why This Rule Exists

Knowledge is cumulative.

Every article.

Every report.

Every presentation.

Every research paper.

Every case study.

Every video.

Every review.

Together they tell the story of an organisation's expertise.

Unfortunately, many websites treat each publication as an isolated event.

Once published, the page simply joins thousands of other disconnected pages.

The organisation misses the opportunity to demonstrate how knowledge has evolved over many years.

A well-designed knowledge ecosystem behaves differently.

Each new contribution enriches the author's profile.

Strengthens the organisation.

Expands topic expertise.

Improves internal discovery.

Builds AI confidence.

Preserves institutional memory.

The website gradually becomes a living archive of professional capability.

Its authority grows naturally through sustained contribution rather than promotional claims.

What Most Programmers Do

Content is published.

Forgotten.

Archived.

Repeated.

The website grows larger.

But not necessarily wiser.

Better Practice

Think beyond individual webpages.

Design systems that continuously accumulate evidence of expertise.

Allow every contribution to reinforce previous work.

Help visitors discover the journey rather than isolated destinations.

Authority should emerge from years of consistently connected knowledge.

Not from slogans.

Programming Impact

This requires:

• persistent knowledge relationships, 

• historical continuity, 

• scalable information architecture, 

• author evolution, 

• institutional knowledge preservation, 

• reputation-aware search, 

• and long-term content governance. 

 ________________________________________

Suggested CMS Structure for Knowledge Authority

A programmer designing a modern CMS should consider supporting the following information.

Not every website needs every field.

However, the CMS should be capable of supporting them whenever they become necessary.

 ________________________________________

Chapter Summary

A website does far more than publish information. 

It also communicates who created that information, why they are qualified to speak, who verified their work and which organisation stands behind it.

The replication of the content with author’s name, their organizations name on other platforms and places increases the credibility manifold. 

In the AI era, this distinction has become increasingly important. Readers, search engines and AI systems all attempt to evaluate not only the content itself but also the credibility of its source.

A well-designed website therefore connects every article, report, video, case study and knowledge asset to the people and organisations responsible for creating it. It distinguishes between authors, reviewers, editors and contributors, builds expertise around specific subjects, preserves institutional knowledge and allows professional reputation to grow naturally through consistent contributions over time.

The programmer cannot create expertise.

The programmer cannot manufacture authority.

Those responsibilities belong to the authors and organisations.

The programmer's responsibility is equally important—to build the digital framework that makes genuine expertise visible, understandable and discoverable.

When this is done well, the website becomes far more than a collection of webpages. 

It becomes a trusted knowledge ecosystem where information, people and organisations reinforce one another, creating lasting confidence for both humans and AI systems.