AI Accelerator, Pipeline component
Describe the component you need in the Accelerator chat and it writes the C#. What decides whether the result is right is how much of the component’s behaviour the prompt pins down.
Pipeline components are the most fact-dependent thing the Accelerator builds: the inbound message shape, the boundary that splits one message from the next, the promotions the downstream message types define, each of these has to be exact, and getting any of them wrong produces a component that compiles but does the wrong thing at runtime. None of it is inferable from a request as thin as “write me a disassembler”. Nothing stops you asking exactly that, the chat will answer; it is the component you get back that pays for the missing facts.
The Accelerator knows the rules a pipeline component follows, so it can write any component you need, whatever that component has to do: split a batch apart, assemble many messages into one, validate, enrich, re-encode, anything else. The example used below is a disassembler because it puts the facts that matter on display, but it is one illustration rather than a category. The shape of a good prompt is the same whatever the component does: say what comes in, say what goes out, and say how each emitted message is typed.
None of the following is required. Ask for a component in one line and you get a component. These are simply the facts the Accelerator cannot infer, so each one you include is one it does not have to guess:
- The inbound message shape (sample, schema, or description).
- Where one message ends and the next begins, if the component breaks a batch into separate messages.
- The Message Type to stamp on each emitted message, and, when the split produces more than one kind of record, how to tell which item gets which type. A component types every message it emits.
- The promotions the downstream message types define, and where on each split message the values they evaluate come from.
- Configurable component properties, values you want exposed in the Art2link ESB UI rather than hardcoded.
- Any edge-case behaviour the component needs to handle (e.g., empty batches, malformed records, encoding quirks).
What you can leave out is everything the Accelerator already knows: the format rulebooks (the next section lists them), the component interface, the C# idioms. Spend the prompt on your integration, not on the specification.
The specification side of the prompt is already covered. The Accelerator knows the structure, the delimiters, and the envelope rules of the formats integration work actually runs on, so naming the format is enough; describing it is wasted prompt:
- Flat file and delimited: CSV, TSV, pipe-delimited, fixed-width/positional, and multi-record hierarchical flat files (header/detail/trailer), the staple of batch interfaces and legacy system exports.
- Structured text and markup: XML, JSON, JSON Lines (NDJSON), YAML, HTML, SGML, what most modern APIs and file drops exchange.
- EDI standards: ANSI X12 (North America), EDIFACT (UN/international), EANCOM (retail EDIFACT subset), TRADACOMS (UK retail, legacy), VDA and ODETTE (European automotive), RosettaNet PIPs, and the procurement XML family (cXML, xCBL, UBL), the trading-partner traffic of orders, invoices, and shipping notices.
- Healthcare: HL7 v2.x (pipe/hat delimited), HL7 v3 (XML), FHIR (JSON/XML/RDF), CDA/C-CDA, DICOM (imaging), NCPDP (pharmacy), and the X12 HIPAA transaction sets (270/271 eligibility, 834 enrollment, 835 remittance, 837 claims).
- Financial: SWIFT MT (FIN block format) and SWIFT MX on ISO 20022 (XML), FIX (trading, tag=value), NACHA ACH (fixed-width), BAI2 (bank reporting), ISO 8583 (card transactions), FpML, XBRL, OFX/QFX.
- Binary serialization: Protocol Buffers, Apache Avro, Apache Thrift, MessagePack, BSON, CBOR, ASN.1 (BER/DER/PER), the compact wire formats of event streams and telecom.
- Analytics and columnar: Parquet, ORC, Arrow, Feather, the file formats data platforms exchange.
- Vertical standards: EPCIS (supply-chain events), CIDX (chemical), PIDX (oil and gas), IATA PADIS and Cargo-IMP (air travel).
- Config and document: INI, TOML, .properties; PDF, DOCX and XLSX (OOXML), RTF, EPUB.
Proprietary trading-partner flat files are the one thing no rulebook covers. Those it cannot know in advance; paste a sample and the layout rules into the prompt and it treats them like any other format.
A request like this states all of it and gets the component back in one pass. Note the Message Type called out explicitly, and the split boundary described in terms of the standard rather than left to inference:
Build a disassembler pipeline component for an inbound EDI 810 invoice batch. Each ST/SE envelope is one invoice, so split the interchange into one message per ST segment and stamp the message type Invoice810 on every message you emit. On each split invoice, promote the invoice number from BIG02, the invoice date from BIG01, and the vendor id from the N1*VN REF. Add a configurable property StrictValidation (bool, default true) that rejects any segment set failing X12 structure. Skip an empty batch without raising an error.