Conversational CodingA Backstory project Install the harness →
Menu

Documentation / Adoption

For EWAI 0.2.8 · Install or update EWAI

Non-technical team guide

Use this guide when you are contributing product, operations, risk, research, policy, or subject-matter knowledge without operating the EWAI command line yourself.

What EWAI needs from you

You are not being asked to design the software. You are being asked to help make the intended outcome, real-world context, evidence, constraints, and acceptance decision explicit.

Bring:

  • the problem as people experience it;
  • the outcome that would make the work worthwhile;
  • real users, stakeholders, and decision owners;
  • examples of the current process and its difficult cases;
  • known constraints and things that must not change;
  • evidence for important statements;
  • open questions and disagreements;
  • how you would recognise a useful and safe result.

Where to contribute

Work with the project owner in the dashboard running on their computer, either together or in a screen-sharing session. Its local link won’t open their project from another computer. The owner can also bring your written answers into the reviewed workflow; check the resulting draft before accepting it. Use Guided Setup to help describe a project, Intent Studio to shape one feature, or Contributions to add evidence to work already under way. Contributions is optional: enable it in Configuration first. You can also work through these questions in the EWAI conversation.

Before approving a draft

Check that you can:

  • understand the topic being discussed;
  • ask for unfamiliar terms to be explained;
  • preserve a draft while the conversation develops;
  • see the active personas and why they’re involved;
  • distinguish assumptions from evidence;
  • see what files or rules will be created;
  • read the complete Review before approving it;
  • see conflicts with existing project records before anything is written.

If you cannot tell what a button will commit, do not approve it.

Understand personas

Personas are prompts that bring different professional or user perspectives into the discussion. You may see a Product Owner, operator, accessibility, finance, architecture, or other lens become active as the topic changes.

For each active persona, you should be able to see:

  • its name;
  • whether it is project, premium, personal, or core;
  • why it is relevant now;
  • which concerns it matched.

Personas are advisory. They do not represent actual user research, stakeholder consent, legal advice, security certification, or approval. Correct them when their question does not fit the evidence.

Describe evidence, not only conclusions

Instead of:

Users need a dashboard.

Try:

Three operations managers currently combine two reports each morning to identify delayed cases. They need to see exceptions before the 9:30 review. The dashboard is one proposed solution.

This preserves the human need if the implementation changes.

Mark the status of statements

Use clear language:

  • Observed: supported by direct evidence.
  • Proposed: an option for consideration.
  • Agreed: participants align, but formal authority may still be needed.
  • Decided: an authorised person made the choice.
  • Implemented: observable in the current system.
  • Unknown: evidence is missing.
  • Contradicted: sources disagree.
  • Superseded: a later decision replaced it.

Do not let a polished summary turn a proposal into a decision.

Review an organisation baseline

An Organisation Blueprint Pack may propose standards and personas that your organisation normally uses. During Review, ask:

  • Does this baseline actually apply to this project?
  • Which parts are mandatory and which are optional?
  • What will be written into the project?
  • What evidence and approval will be retained?
  • Is any project-specific exception needed?

The Blueprint publisher provides the baseline. The project owner remains accountable for adopting it.

Give approval carefully

Approval should show:

  • the complete proposed outcome;
  • exact consequences and destinations;
  • evidence, assumptions, exclusions, and conflicts;
  • the version or digest of reusable content;
  • the named person approving;
  • what future changes would require another review.

Selection, preview, and approval are different actions.

Participate in Manual QA

You may be the best person to test whether a delivered workflow is useful. Ask for a walkthrough that states the environment, starting point, actions, expected results, and known limitations.

Record what actually happened. A failed step is valuable evidence; do not smooth it into a pass. Manual QA acceptance does not itself deploy the change.

Questions you should always be able to ask

  • Why are we doing this?
  • Who supplied this information?
  • Which persona is active, and why?
  • Is this a fact, proposal, decision, or inference?
  • What changes if I approve?
  • What remains unknown or untested?
  • Who owns the risk or follow-up?
  • Can we reverse this safely?