Co-author

Co-author is your AI-powered assistant for accelerating knowledge graph development. Using unstructured data, Co-author helps transform Consult reports and business documentation into structured knowledge models for you to test and refine.

All features delivered by Rainbird Labs are beta. They may contain bugs, are subject to change and are not covered by our platform SLAs. Your feedback can help shape development.

Getting Started

Co-author is in closed beta. Please speak with your Rainbird contact or email us at [e-mail] to request access.

Within the Rainbird Studio, open a new map, save it and open the Co-author chat agent.

You can either explain what you would like to be generated, or you can paste document content into the chat to trigger generation (document upload coming soon).

Co-author supports multiple modes, many of which are experimental.

For optimal results we recommend leaving it on the default mode.

Best Practice

Documentation Best Practice

To optimise the performance of Co-author, please consider some of these tips:

1. Ensure the document is outcome-focused: Make sure your document is strictly focused on achieving a desired outcome. Remove any unnecessary introductions or preamble, and avoid including descriptive or scene-setting content that doesn't contribute to decision-making.

2. Simplify the formatting: Minimise complex formatting. Remove paragraph and chapter numbering, convert multi-column text into a single, well-structured and fluid document.

3. Break the document into smaller parts: If needed, dissect your document into smaller, manageable segments. Each part should describe a specific piece of expertise. This approach often leads to better results when applied iteratively.

The following type of documents should work well:

1. Standard Operating Procedures (SOPs) with clear process flows ✅

2. Regulatory compliance documents with explicit requirements ✅

3. Technical specifications with clear dependencies and constraints ✅

4. Policy manuals with well-defined rules and conditions ✅

5. Service Level Agreements (SLAs) with specific criteria and thresholds ✅

6. Decision trees and decision matrices in documented form ✅

Documents that are less likely to perform well include:

1. Documents that are highly visual, with meaning held in graphs, charts or complex tables ❌

2. Academic-style papers with multiple column layouts, complex mathematical calculations or references and citations that break-up the main text flow ❌

3. Scanned documents with poor OCR quality ❌

4. Documents with implicit knowledge assumptions ❌

5. Highly contextual or situational guidelines ❌

6. Documentation with undefined jargon or acronyms ❌

Versioning

It is recommended to version your knowledge map between Co-author requests, including a comment of the changes introduced.

This provides an opportunity to easily restore an older version if you want to undo a Co-author change. Information on versioning can be found in the Academy.

Versions can only be created when there are no errors in the knowledge map. There may be some known errors introduced by Co-author, which are mentioned below.

Important Information

Data Security

Co-author operates using third-party AI services (Anthropic and OpenAI). Please ensure shared information is suitable for external processing.

Any request made via Co-author shares the Knowledge Map with the LLM provider.

Limitations

• Token limits apply. For large content and/or large knowledge maps, limits may be reached and incomplete RBLang returned resulting in error.

• The chat history is not currently shared with each Co-author request (to reduce token usage), therefore prompts such as "No I didn't mean that, can you change it to blue" will not have context of the messages before it.

• Service may be interrupted during peak periods.

• Varying behaviour: LLMs are not deterministic so you will likely see different responses when testing the same content.

• Map layout: A new map will auto-layout, but if updates are being made to an existing map the concepts will be placed in the centre and require manually rearranging.

• RBLang errors: whilst we continue to make improvements, there are some of the common errors created by Co-author. You can ask Co-author to fix some of these (copy and paste the error to Co-author), but some may need to be fixed manually. Some of these can be fixed in the Editor UI, whilst others will require fixing directly in RBlang (accessed via the </> code panel).

Common Co-author errors

1. Rules that reference instances that don’t exist

   1. Identify the relationship of this rule, identify the concept it’s attached to then add the instance to this concept.

2. Incorrect use of variables in the rule header

   1. You may see Subject=”%S” or Subject=”%PERSON” in the rule header (the start of the rule). This is invalid, as variables can only be used in conditions. Remove any subject and/or object from the rule header that contains a variable. If it used a custom variable (e.g. %PERSON) it may also have used this in the conditions below, when it should use the specially designated variables of %S for the subject or %O for the object. These will need to be updated.

3. Relationships referencing concepts that don’t exist

   1. Often these tend to be called something generic like String, Date, Number or Truth. You will need to review the graph, determine what the concept should be called, create one with this name then update the relationship to refer to your new concept.

4. Invalid expressions

   1. Unsupported expressions can sometimes be generated, which can be manually fixed in the UI. Use our documentation to help create a valid expression. Where an expression contains multiple OR conditions, this can sometimes indicate the rule needs to be split into multiple rules. You can duplicate the rule and modify them, or prompt Co-author to separate these rules into distinctive rules.

Once fixed and you can save successfully, create a version of this so you can return to it if required.